C0favicon

Efail:BreakingS/MIMEandOpenPGPEmailEncryptionusingExfiltrationChannelsDamianPoddebniakandChristianDresen,MünsterUniversityofAppliedSciences;JensMüller,RuhrUniversityBochum;FabianIsingandSebastianSchinzel,MünsterUniversityofAppliedSciences;SimonFriedberger,NXPSemiconductors,Belgium;JurajSomorovskyandJrgSchwenk,RuhrUniversityBochumhttps://www.
usenix.
org/conference/usenixsecurity18/presentation/poddebniakThispaperisincludedintheProceedingsofthe27thUSENIXSecuritySymposium.
August15–17,2018Baltimore,MD,USAISBN978-1-939133-04-5Efail:BreakingS/MIMEandOpenPGPEmailEncryptionusingExltrationChannelsDamianPoddebniak1,ChristianDresen1,JensM¨uller2,FabianIsing1,SebastianSchinzel1,SimonFriedberger3,JurajSomorovsky2,andJ¨orgSchwenk21M¨unsterUniversityofAppliedSciences2RuhrUniversityBochum3NXPSemiconductors,BelgiumAbstractOpenPGPandS/MIMEarethetwoprimestandardsforprovidingend-to-endsecurityforemails.
Wede-scribenovelattacksbuiltuponatechniquewecallmal-leabilitygadgetstorevealtheplaintextofencryptedemails.
WeuseCBC/CFBgadgetstoinjectmaliciousplaintextsnippetsintoencryptedemails.
Thesesnippetsabuseexistingandstandardconformingbackchannelstoexltratethefullplaintextafterdecryption.
WedescribemalleabilitygadgetsforemailsusingHTML,CSS,andX.
509functionality.
Theattackworksforemailseveniftheywerecollectedlongago,anditistriggeredassoonastherecipientdecryptsasinglemaliciouslycraftedemailfromtheattacker.
WedeviseworkingattacksforbothOpenPGPandS/MIMEencryption,andshowthatexltrationchannelsexistfor23ofthe35testedS/MIMEemailclientsand10ofthe28testedOpenPGPemailclients.
Whileitisad-visabletoupdatetheOpenPGPandS/MIMEstandardstoxthesevulnerabilities,someclientshadevenmorese-vereimplementationawsallowingstraightforwardex-ltrationoftheplaintext.
1IntroductionDespitetheemergenceofmanysecuremessagingtech-nologies,emailisstilloneofthemostcommonmethodstoexchangeinformationanddata,reaching269billionmessagesperdayin2017[1].
Whiletransportsecuritybetweenmailserversisusefulagainstsomeattackerscenarios,itdoesnotofferreliablesecurityguaranteesregardingcondentialityandauthen-ticityofemails.
Reportsofpervasivedatacollectionef-fortsbynationstateactors,large-scalebreachesofemailservers,revealingmillionsofemailmessages[2–5],orattackerscompromisingemailaccountstosearchtheemailsforvaluabledata[6,7]underlinethattransportsecurityaloneisnotsufcient.
End-to-endencryptionisdesignedtoprotectuserdatainsuchscenarios.
Withend-to-endencryption,theemailinfrastructurebecomesmerelyatransportationserviceforopaqueemaildataandnocompromise–asidefromtheendpointsofsenderorreceiver–shouldaffectthesecurityofanend-to-enden-cryptedemail.
S/MIMEandOpenPGP.
Thetwomostprominentstan-dardsofferingend-to-endencryptionforemail,S/MIME(Secure/MultipurposeInternetMailExtensions)andOpenPGP(PrettyGoodPrivacy),co-existformorethantwodecadesnow.
Althoughthecryptographicsecu-rityofthemwassubjecttocriticism[8–10],littlewaspublishedaboutpracticalattacks.
Instead,S/MIMEiscommonlyusedincorporateandgovernmentenviron-ments.
1ItbenetsfromitsabilitytointegrateintoPKIsandthatmostwidely-usedemailclientssupportitbydefault.
OpenPGPoftenrequirestheinstallationofad-ditionalsoftwareand,besidesasteadyuserbasewithinthetechnicalcommunity,isrecommendedforpeopleinhigh-riskenvironments.
Infact,humanrightsorganiza-tionssuchasAmnestyInternational[11],EFF[12],orReporterswithoutBorders[13]recommendusingPGP.
Weshowthatthistrustisnotjustied,neitherinS/MIMEnorinOpenPGP.
Basedonthecomplexityofthesetwospecicationsandusageofobsoletecrypto-graphicprimitives,weintroducetwonovelattacks.
Backchannelsandexltrationchannels.
Oneofthebasicbuildingblocksforourattacksarebackchan-nels.
Abackchannelisanyfunctionalitythatinter-actswiththenetwork,forexample,amethodforforcingtheemailclienttoinvokeanexternalURL.
AsimpleexampleusesanHTMLimagetagwhichforcestheemailclienttodownloadanimagefromefail.
de.
Thesebackchannelsarewidelyknownfortheirprivacyim-1AcomprehensivelistofEuropeancompaniesandagenciessup-portingS/MIMEisavailableathttps://gist.
github.
com/rmoriz/5945400.
USENIXAssociation27thUSENIXSecuritySymposium549plicationsastheycanleakwhetherandwhentheuseropenedanemailandwhichsoftwareandIPheused.
Untilnow,thefetchingofexternalURLsinemailwasonlyconsideredtobeaprivacythreat.
Inthispa-per,weabusebackchannelstocreateplaintextexltra-tionchannelsthatallowsendingplaintextdirectlytotheattacker.
Weanalyzehowanattackercanturnbackchan-nelsinemailclientstoexltrationchannels,andthusob-tainvictimplaintextmessages.
Weshowtheexistenceofbackchannelsfornearlyeveryemailclient,rangingfromclassicalHTMLresourcestoOCSPrequestsandCerti-cateRevocationlists.
Malleabilitygadgetattacks.
Ourrstattackexploitstheconstructionofobsoletecryptographicprimitives,whilethesecondabusesthewayhowsomeemailclientshandledifferentMIMEparts.
AnimportantobservationfortherstattackisthatOpenPGPsolelyusestheCipherFeedbackMode(CFB)andS/MIMEsolelyusestheCi-pherBlockChaining(CBC)modeofoperation.
Bothmodesprovidemalleabilityofplaintexts.
Thispropertyallowsanattackertoreorder,removeorinsertciphertextblocks,ortoperformmeaningfulplaintextmodicationswithoutknowingtheencryptionkey.
Moreconcretely,hecanipspecicbitsintheplaintextorevencreatear-bitraryplaintextblocksifheknowspartsoftheplaintext.
WeusethemalleabilityofCBCandCFBtocon-structsocalledmalleabilitygadgetsthatallowustocre-atechosenplaintextsofanylengthundertheassumptionthattheattackerknowsoneplaintextblock.
Thesemal-leabilitygadgetsarethenusedtoinjectmaliciousplain-textsnippetswithintheactualplaintext.
Anidealmal-leabilitygadgetattackispossibleiftheattackerknowsonecompleteplaintextblockfromtheciphertext,whichis16bytesforAES.
However,fewerknownplaintextbytesmayalsobesufcient,dependingontheexltra-tionchannelthattheattackeraimsfor.
Guessingsmallpartsofplaintextistypicallyfeasiblesincetherearehun-dredsofbytesofstaticmetadata.
Withthistechnique,wewereabletodefeattheen-cryptionmodesusedinbothS/MIMEandPGP.
WhileattackingS/MIMEisstraightforward,forOpenPGP,weneededtodevelopmorecomplexexploittechniquesuponmalleabilitygadgetsbecausethedataistypicallycompressedbeforeencryption.
Directexltrationattacks.
OursecondattackexploitshowdifferentemailclientshandleemailscontainingmultipleMIMEparts.
WediscoveredseveralattacksvariationsthatsolelyexploitthecomplexinteractionofHTMLtogetherwithMIME,S/MIMEandOpenPGPinemailclients.
Thesecasesarestraightforwardtoexploitanddonotrequireanychangesoftheciphertext.
Inthemoststraightforwardexampleofourattacks,theadver-sarypreparesaplaintextemailstructurethatcontainsanelement,whoseURLisnotclosedwithquotes.
Contributions.
Wemakethefollowingcontributions:Weintroducetheconceptofmalleabilitygadgets,whichallowanattackertoinjectmaliciouschosenplaintextsnippetsintotheemailciphertext.
Wede-scribeandapplymalleabilitygadgetsfortheCBCandCFBmodesusedinemailencryption.
Weanalyzeallmajoremailclientsforbackchannelsthatcanbeusedforthecreationofexltrationchan-nels.
OpenPGP'splaintextcompressionsignicantlycomplicatesourattack.
Wedescribetechniquestocreatearbitraryplaintextsfromspecicchangesinthecompressedplaintextusingadvancedmalleabil-itygadgets.
Wedescribepracticalattacksagainstmajoremailclientsallowingtoexltratedecryptedemailsdi-rectly,withoutciphertextmodications.
Wediscussmediumandlong-termcountermeasuresforemailclientsandtheS/MIMEandPGPstan-dards.
Responsibledisclosure.
Wedisclosedthevulnerabili-tiestoallaffectedemailvendorsandtonationalCERTsandourndingswereconrmedbythesebodies.
2BackgroundInitssimplestform,anemailisatextmessagecon-formingtotheInternetMessageFormat(IMF)[14].
AstheIMFlacksfeaturesthatarerequiredinthemodernInternet,suchasthetransmissionofbinarydata,itisaugmentedwithMultipurposeInternetMailExtension(MIME)[15]tosupporttransmissionofmultimediames-sagesor–incaseofOpenPGPandS/MIME–toallowend-to-endencryptionofemails.
2.
1End-to-endencryptedemailS/MIMEandCMS.
TheSecure/MultipurposeInter-netMailExtension(S/MIME)isanextensiontoMIMEdescribinghowtosendandreceivesecuredMIMEdata[16].
S/MIMEfocusesontheMIME-relatedpartsofanemailandreliesontheCryptographicMessageSyn-tax(CMS)todigitallysign,authenticate,orencryptar-bitrarymessages[17].
CMSisasetofbinaryencodingrulesandmethodstocreatesecuredmessages.
AsitisderivedfromPKCS#7,theterm"PKCS"isfoundinvar-iousheadersofsecuredemails.
55027thUSENIXSecuritySymposiumUSENIXAssociationPrettyGoodPrivacy.
PhilZimmermandevelopedtherstversionofPrettyGoodPrivacy(PGP)in1991asameanstoenablepoliticalactiviststocommunicatese-curelyonBBSs,UsenetgroupsandtheearlyInternet.
Inthelate'90s,theIETFpublishedRFC2440describ-ingtheOpenPGPformat,whichhasbeenupdatedsev-eraltimes.
ThelateststandardisRFC4880,publishedin2007,whichdescribesavarietyofmethodstoencryptandsigndigitaldata[18].
2.
2CryptographicbasicsIntheemailcontext,bothS/MIMEandPGPusehybridencryption,inwhichthesendergeneratesarandomses-sionkeysthatisusedtosymmetricallyencryptthemes-sagemintoaciphertextc.
Thesessionkeysisencryptedwithatleasttwopublickeysusingapublickeyencryp-tionscheme.
Therstencryptionofshappenswiththepublickeyofthesender.
Additionalencryptionsaredoneusingallthepublickeysoftheintendedreceivers.
Thus,swillbeencryptedundern+1differentpublickeysfornrecipientsoftheemail.
Throughoutthispaper,wefocusonthesymmetricencryption.
EncryptionmodesinOpenPGPandS/MIME.
Forsymmetricencryptionofthemessagem,thestandardsspecifyseveralblockciphers,themostrelevantbeing3DESandAES.
Asencryptionmodes,S/MIMEusesCipherBlockChaining(CBC)andOpenPGPusestheCipherFeedbackMode(CFB).
Duringdecryption,bothmodesproduceintermediatevalueswhichareXORed()withanadjacentciphertextblocktoproducethe-nalplaintextblock.
ForCBC,thedecryptionofCiintoitsrespectiveplaintextblockisPi=decs(Ci)Ci1.
ForCFB,itisPi=encs(Ci)Ci+1.
Malleabilityinencryptionmodes.
XORisamal-leableoperation,whichmeansthatippingasinglebitinoneofthetwooperandsofXORresultsinabitipofthenalplaintextatthesameposition.
BecauseXORingwithadjacentciphertextblocksisthenaloperationinCBCandCFB,preciseplaintextmanipulationsarepos-siblebychangingtheciphertextonly.
AuthenticatedencryptionNewerencryptionschemeswilldetectmodicationoftheciphertextanddonotout-puttheplaintextinthiscase.
Typically,thisisarchivedbyusingMessageAuthenticationCodes(MACs)oranAuthenticatedEncryption(AE)scheme.
However,bothS/MIMEandPGPpredatethesedevelopmentsandusenoauthenticationatall(S/MIME)ordonotstrictlycom-mittotherequirementsofanAE,whichmakesthemeas-iertomisuse(PGP).
Figure1:ReplacingtheURLintheciphertextblocks(Cw1,Cw)with(Ci1,Ci)toexltratesensitivedata.
3TowardsexltrationattacksModernemailclientsareabletoassembleandrendervarioustypesofcontent,mostnotablyHTMLdocu-ments,andHTMLprovidesmethodstofetchresourceslikeimagesandstylesheetsfromtheInternet.
Emailclientsmayadditionallyrequestotherinformation,forexample,tovalidatethestatusofacryptographiccerti-cate.
Wewillrefertoallthesechannelsasbackchan-nelsbecausetheycaninteractwithpossiblyattacker-controlledservers.
Backchannelsintheemailcontextarewell-knowntobeaprivacyissuebecausetheyallowdetectingif,whenandwhereamessagehasbeenreadandmayleakfurtherinformationsuchastheuser'smailclientandoperatingsystem.
Buttheyaremorethanthat.
Inthefollowingsectionsweshowthatbackchannelscanbeusedtoexltratetheplaintextofanemailafterithasbeendecrypted.
Theshowedmethodsaredirectlyap-plicabletoS/MIME.
ForPGP,furtherrequirementsmustbemet,whicharediscussedinSection5.
3.
1BlockreorderingattackCBCandCFBallownotonlyprecisemodicationsoftheplaintext,butalsotoreorderciphertextblocks.
Withsomelimitations,changingtheorderoftheciphertextblockswilleffectivelyalsoreordertherespectiveplain-textblocks.
AssumeanAES-CBCencryptedHTMLemailcon-taininganHTMLimagetagataknownciphertextpair(Cw1,Cw).
Duetothereorderingproperty,anat-tackercanreplace(Cw1,Cw)withanotherciphertextpair(Ci1,Ci).
Ineffect,therespectiveplaintextPiwillbereectedintheURLpathandtheresultingHTTPrequestwillexltratesensitivedataapassiveMitMat-tackercanobserve(seeFigure1).
3.
2MalleabilitygadgetsInthepreviousexample,aMitMattackercouldexltratethoseemailsthatalreadycontainedanexternalHTMLimageusingblockreordering.
Wenowrelaxthiscon-straintandintroducetheconceptofmalleabilitygadgetsUSENIXAssociation27thUSENIXSecuritySymposium551Figure2:TransformingaknownplaintextPitoachosenplaintextPcinCBCandCFB.
thatallowtoinjectarbitraryplaintextsintoencryptedemailsgivenonlyasingleblockofknownplaintext.
Denition.
Let(Ci1,Ci)beapairoftwociphertextblocksandPithecorrespondingplaintextblockofanCBCencryptedciphertext.
Wecall((Ci1,Ci),Pi)aCBCgadgetifPiisknowntoanattacker.
Accordingly,wecall((Ci,Ci+1),Pi)ofanCFBencryptedciphertextaCFBgadget.
UsingCBCgadgets.
GivenaCBCgadget(seeFig-ure2(a)),itispossibletotransformPiintoanyplaintextPcbyreplacingCi1withX=Ci1PiPc(seeFigure2(b)).
ThiscomesatacostasXwillbedecryptedwithanunknownkey,resultinginuncontrollableandunknownrandombytesinPi1.
UsingCFBgadgets.
CFBgadgetworksimilartoCBCgadgetswiththedifference,thattheblockafterthecho-senplaintextblockbecomesarandomblock(seeFig-ure2(c,d)).
Chosenplaintextandrandomblocks.
Asingleblockofknownplaintextissufcienttoinjectanyamountofchosenplaintextblocksatanyblockboundary.
How-ever,theconcatenationofmultiplegadgetsproducesanalternatingsequenceofchosenplaintextblocksandran-domblocks.
Thus,tocreateworkingexltrationchan-nels,anattackermustdealwiththeserandomblocksinawaythattheyareignored.
Onecanthinkofseveralwaystoachievethat.
Whencommentsareavailablewithinacontext,forexampleviaC-stylecomments/*and*/,exltrationchannelscaneasilybeconstructedbysim-plycommentingouttherandomblocks.
Incasenocom-mentsareavailable,characteristicsoftheunderlyingdataformatcanbeused,forexample,thatunnamedattributesinHTMLareignored.
4AttackingS/MIMEInthissectionweshowthatS/MIMEisvulnerabletoCBCgadgetattacks,anddemonstratehowexltrationchannelscanbeinjectedintoS/MIMEemails.
4.
1S/MIMEpacketstructureMostclientscaneithersign,encryptorsign-then-encryptmessages.
Sign-then-encryptisthepreferredwrappingtechniquewhenbothcondentialityandauthenticityareneeded.
Thebodyofasigned-then-encryptedemailcon-sistsoftwoMIMEentities,oneforsigningandoneforencryption.
Theoutermostentity–alsospeciedintheemailheader–istypicallyEnvelopedData.
TheEn-velopedDatadatastructureholdstheRecipientInfoswithmultipleencryptedsessionkeysandtheEncryptedCon-tentInfo.
EncryptedContentInfodeneswhichsymmet-ricencryptionalgorithmwasusedandnallyholdstheciphertext.
Decryptionoftheciphertextrevealsthein-nerMIMEentityholdingtheplaintextmessageanditssignature.
Notethatthereisnointegrityprotection.
4.
2AttackdescriptionS/MIMEusestheCBCencryptionmodetoencryptdata,sotheCBCgadgetfromFigure2canbeusedforS/MIMEemails.
Whendecrypted,theciphertextofasigned-then-encryptedemailtypicallystartswithContent-type:multipart/signed,whichrevealsenoughknown-plaintextbytestofullyutilizeAES-basedCBCgadgets.
Therefore,inthecaseofS/MIME,anattackercanusethersttwocipherblocks(IV,C0)andmodifytheIVtoturnP0intoanychosenplaintextblockPci.
Injectionofexltrationchannels.
Aslightlysimpli-edversionoftheattackisshowninFigure3.
Therstblocksofaciphertextwhoseplaintextwewanttoexl-trateareshowninFigure3(a).
Weuse(IV,C0)tocon-structourCBCgadgetsbecauseweknowthecompleteassociatedplaintextP0.
Figure3(b)showsthecanonicalCBCgadgetasitusesX=IVP0tosetallitsplaintextbytestozero.
WethenmodifyandappendmultipleCBCgadgetstoprependachosenciphertexttotheunknowncipher-textblocks(Figure3(c)).
Asaresult,wecontroltheplaintextintherstandthirdblock,butthesecondandfourthblockcontainrandomdata.
TherstCBCgadgetblockPc0opensanHTMLimagetagandameaninglessattributenamedignore.
Thisattributeisusedtoconsumetherandomdatainthesecondblocksuchthattherandomdataisnotfurtherinterpreted.
ThethirdblockPc1thenstartswiththeclosingquoteoftheignoredattributeand55227thUSENIXSecuritySymposiumUSENIXAssociationFigure3:DetaileddescriptionoftheattackonS/MIME.
Theoriginalciphertextisshownin(a).
(b)isthecanonicalCBCgadgetresultinginanallzeroplaintextblock.
(c)isthemodiedciphertextthatissenttothevictim.
addsthesrcattributethatcontainsthedomainnamefromwhichtheemailclientissupposedtoloadtheimage.
Thefourthplaintextblockagaincontainsrandomdata,whichistherstpartofthepathoftheimageURL.
Allsubse-quentblockscontainunknownplaintexts,whichnowarepartoftheURL.
Finally,whenanemailclientparsesthisemail,theplaintextissenttotheHTTPserverdenedinPc1.
Meaninglesssignatures.
Onecouldassumethatthedecryptionofmodiedciphertextswouldfailbecauseofthedigitalsignatureincludedinthesigned-then-encryptedemail,butthisisnotthecase,becausesigna-tureinS/MIMEcaneasilyberemovedfromthemulti-part/signedmailbody[19].
Thistransformsthesigned-then-encryptedemailintoanencryptedmessagethathasnosignature.
Ofcourse,acautioususercoulddetectthatthisisnotanauthenticemail,buteventhen,bythetimetheuserdetectsthat,theplaintextwouldalreadyhavebeenexltrated.
Signaturescanalsonotbecomemanda-tory,becausethiswouldhinderanonymouscommuni-cation.
Furthermore,aninvalidsignaturetypicallydoesnotpreventthedisplay/renderingofamessageinemailclienteither.
Thishashistoricreasons,asmailgatewayscouldinvalidatesignaturesbychangingline-endingsintheplaintext,etc.
4.
3PracticalexploitationExltrationcodesmustbedesignedsuchthattheyareignoranttointerleavedrandomblocks.
Althoughthisre-strictioncanbecircumventedbycarefuldesignoftheexltrationcode–recaptheusageoftheignoreattribute–someexltrationcodesmayrequireadditionaltrickstoworkinpractice.
Forexample,HTML'ssrcattribute,requirestheex-plicitnamingoftheprotocol,e.
g.
http://.
Unfortu-nately,src="http://hasalready12bytes,leavingmerelyenoughroomfora4bytedomain.
AworkaroundistoscattertheexltrationcodeintomultipleHTMLelementswithoutbreakingitsfunctionality.
Incaseofthesrcattribute,anadditionalelementcanbeusedtogloballyde-nethebaseprotocolrst.
Emailssentastext/plainposeanotherdif-culty.
AlthoughthereisnothingspecialaboutthoseemailsinthecontextofCBCgadgets,injectionofContent-type:text/htmlturnedouttobedif-cultduetorestrictionsintheMIMEheaders.
Anat-tackerhastoapplyfurthertrickssuchthatheaderparsingwillnotbreakwhenrandomdataisintroducedintotheheader.
5AttackingOpenPGPOurexltrationattacksarenotonlypossibleinS/MIME,butalsoworkagainstOpenPGP.
However,therearetwoadditionalobstacles:(1)OpenPGPusescompressionbydefaultand(2)ModicationDetectionCodes(MDC)areusedforintegrityprotection.
Compression.
Inthecontextofmalleabilitygadgets,compressionmakesexploitationmoredifcult,becausethecompressedplaintextishardertoguess.
SimilartoS/MIME,PGPemailsalsocontainknownheadersandplaintextblocks,forexample,Content-Type:multipart/mixed,butaftercompressionisapplied,theresultingplaintextmayvastlydifferpermail.
ThedifcultyhereistoguessacertainamountofcompressedplaintextbytesinordertofullyutilizetheCFBgadgettechnique.
Notknowingenoughcompressedplaintextbytesishardlyacountermeasure,butmakespracticalexploitationalotharder.
USENIXAssociation27thUSENIXSecuritySymposium553Weshowhowthecompressionstructurecanbeex-ploitedtocreateexltrationchannels.
Interestingly,withthecompressioninplace,wecancreateexltrationchan-nelsevenmorepreciselyandremovetherandomdatablocksfromtheresultingplaintext.
Integrityprotection.
TheOpenPGPstandardstatesthatdetectedmodicationstotheciphertextshouldbe"treatedasasecurityproblem",butdoesnotdenewhattodoincaseofsecurityproblems.
Thecorrectwayofhandlingthiswouldbetodropthemessageandnotifytheuser.
However,ifclientstrytodisplaywhateverisleftofthemessageasa"besteffort",exltrationchan-nelsmaybetriggered.
Inordertounderstandhowtheintegrityprotectioncanbedisabledandhowcompressioncanbedefeated,wehavetogointomoredetailofOpenPGP.
5.
1OpenPGPpacketstructureInOpenPGP,packetsareoftheformtag/length/body.
ThetagdenotesthepackettypeaslistedinTable1.
Thebodycontainseitheranothernestedpacketorarbitraryuserdata.
Thesizeofthebodyisencodedinthelengtheld.
Tagno.
TypeofPGPpacket8CD:CompressedDataPacket9SE:SymmetricallyEncryptedPacket11LD:LiteralDataPacket18SEIP:SymmetricallyEncryptedandIntegrityProtectedPacket19MDC:ModicationDetectionCodePacket60–63Experimentalpackets(ignoredbyclients)Table1:PGPpackettypesusedthroughoutthispaper.
Messageencryption.
Amessageisencryptedinfoursteps:(1)themessagemisencapsulatedinaLiteralData(LD)packet.
(2)theLDpacketiscompressedviadeateandencapsulatedinaCompressedData(CD)packet.
(3)theModicationDetectionCode(MDC)overtheCDpacketiscalculated(SHA-1)andappendedtotheCDpacketasanMDCpacket.
(4)nally,theconcatenatedCDandMDpacketsareencryptedandtheciphertextisencapsulatedinanSymmetricallyEncryptedandIn-tegrityProtected(SEIP)packet(seeFigure4).
5.
2DefeatingintegrityprotectionTheOpenPGPstandardmandatesthatclientsshouldpre-fertheSEIPpackettypeovertheSEpackettype,becauseforSEIPpackets,modicationoftheplaintextwillbedetectedduetoamismatchoftheSHA-1hashofthemessageandtheattachedMDCpacket.
GeneratingSEpackets.
Clientsmayignorethestan-dardsrecommendationandstillgenerateSEciphertexts.
Thesemessageshavenointegrityprotectionandhavenomeansofpreventingourattacks.
OlderciphertextsthatweregeneratedbeforetheintroductionoftheMDCwillremainvulnerable.
IgnoringtheMDC.
TheMDCisonlyeffectiveifitischecked.
ThiscaneasilybeveriedbyintroducingchangestotheciphertextandleavingtheMDCasitis.
IftheMDCwillnotmatchthemodiedciphertextandiftheclientcontinuesprocessing,theclientmaybevulner-able.
StrippingtheMDC.
Similartothepreviousattempt,theMDCcanalsoberemoved,suchthattheclientcannotchecktheMDCatall.
Thisiseasilypossiblebyre-movingthelast22bytesfromtheciphertext.
DowngradeSEIPpacketstoSEpackets.
AmoreelaboratemethodistodisabletheintegrityprotectionbychanginganSEIPpackettoanSymmetricallyEncrypted(SE)packet,whichhasnointegrityprotection.
Thisisstraightforward,becausethepackettypeisnotencrypted(seeFigure4).
Thisdowngradeattackhasbeenknownsince2002[20],butneverusedinanactualattack.
However,thereisacaveat:inanSEpacket,thelasttwobytesoftheIVareaddedjustaftertherstblock.
Thiswasoriginallyusedtoperformanintegrityquickcheckonthesessionkey.
WhiletheSEtyperesynchronizestheblockbound-ariesafterencryptingthesetwoadditionalbytes,theSEIPdoesnotperformthisresynchronization.
TorepairthedecryptionafterchangingtheSEIPtoanSEpacket,twobytesmustbeinsertedatthestartoftherstblocktocompensateforthemissingbytes.
Thiswasalsode-scribedbyPerrinandMagazinius[20,21].
Figure4:NestingofaSymmetricallyEncryptedandIn-tegrityProtectedDataPacketinOpenPGP.
55427thUSENIXSecuritySymposiumUSENIXAssociationSinceanattackwaspublishedagainstthisintegrityprotectionmechanism[22],itsinterpretationisdiscour-aged[18],andthetwobytesareignored.
TheydepictthebeginningoftherstrealplaintextblockandtheSEandSEIPpackettypestreatthemdifferently.
5.
3DefeatingdeateOpenPGPutilizesthedeatealgorithm[23]tocompressLDpacketsbeforeencryptingthem.
ItisbasedonLZ77(specicallyLZSS)andHuffmanCoding.
Althoughtheexactdetailsarenotimportantforthispaper,itisim-portanttonotethatasinglemessagemaybepartitioned,suchthatdifferentmodesofcompressioncanbeusedfordifferentsegmentsofthemessage.
Modesofcompression.
Thestandarddenesthreemodesofcompression:uncompressed,compressedwithxedHuffmantrees,andcompressedwithdynamicHuffmantrees.
Itisspeciedbyaheaderprependedtoeachsegment.
AsingleOpenPGPCDpacketcancontainmultiplecompressedoruncompressedsegments.
2Backreferences.
Typically,afullmessageiswrappedinsideasinglecompressedsegment.
Then,thealgorithmappliesasearchfortextfragmentrepetitionsofcertainlengthwithintheboundariesofaslidingwindow.
Ifarepetitionisfound,itisreplacedwithashorterpointertoitspreviousoccurrence.
Forexample,thetextHowmuchwoodcouldawoodchuckchuckisshortenedtoHowmuchwoodcouldachuck.
Inreality,thedeatealgorithmencodesbackreferencesassmallbitstringstoachieveahighercompressionlevel.
ThebackreferencestringsareinsertedintoaHuffmantreethatisplacedbeforethecompressedtext.
Duringthedecompressionprocess,thealgorithmusestheHuffmantreetorestorethesepatterns.
Uncompressedsegments.
Inadditiontocompressedsegments,thedeatedataformatalsospeciesuncom-pressedsegments.
Thesesegmentsarealsousedduringthesearchforrepetitions,but,incontrasttocompressedsegments,maycontainarbitrarydata.
Thisisanimpor-tantobservation,becauseitallowsustoworkaroundthelimitedamountofknownplaintext.
DynamicandxedHuffmantrees.
Startingfromaround90to100bytesofplaintext,deateusesady-namicHuffmantreethatisserializedtobytesandformsthestartofthedeatedata.
DynamicHuffmantrees2RFC1951speaksof"blocks".
Wechangetheterminologyto"seg-ments"forbetterreadability.
changesubstantiallyandaredifculttopredictforpartlyunknownplaintexts.
Forshortertexts,xedHuffmantreesareused.
Theyarestaticallydenedin[23]andnotlocatedinthedata.
Inthefollowingsections,weassumexedHuffmantreestooutlinetheattack.
5.
3.
1CreatingaCFBgadgetTherstencryptedblockseemsmostpromising,becauseitconsistsofOpenPGPpacketmetadataandcompres-sionheaders.
Byexploitingbackreferencesinthecompressionalgo-rithmweareabletouseonly11byteslongmalleabilitygadgets.
Thesebackreferencesallowustoreferenceandconcatenatearbitraryblocksofdataandthuscreateex-ltrationchannelsmoreprecisely.
Therefore,insteadoftryingtoworkaroundthecompression,weuseittopre-ciselyinjectourexltrationcodesincompressedform.
5.
3.
2ExltratingcompressedplaintextsAssumeweareinpossessionofanOpenPGPSEIPpacketwhichdecryptstoacompressedplaintext.
Weknowonedecryptedblockwhichallowsustoconstructamalleabilitygadgetandthusarbitrarynumberofchosenplaintexts.
Ourgoalistoconstructaciphertextwhichde-cryptstoacompressedpacket.
Itsdecompressionleadstoanexltrationofthetargetplaintext.
AsimpliedattackisshowninFigure5andcanbeperformedasfollows.
Usingourmalleabilitygadgetwerstcreatethreeciphertextblockpairs(Ci,Ci+1)whichdecryptintousefultextfragments(Pc0,Pc1,Pc2).
ThersttextfragmentrepresentsanOpenPGPpacketstruc-turewhichencodesaCDpacket(whichisencodedas0xafinOpenPGP)containingaLDpacket(encodedas0xa3).
Thelattertwotextfragmentscontainanexltra-tionchannel,forexample,HTMLtagisshowninFigure6(a).
IftheemailclientrstdecryptstheencryptedpartandthenputsallbodypartsintooneHTMLdocumentasshowninFigure6(b),theHTMLrenderingengineleaksthedecryptedmessagetotheattacker-controlledwebserverwithintheURLpathofaGETrequestasshowninFig-ure6(c).
Becausetheplaintextmessageisleakedafterdecryp-tion,thisattackisindependentoftheemailencryptionschemeandmaybeusedevenagainstauthenticateden-cryptionschemes.
Directexltrationchannelsarisefromfaultyisolationbetweensecureandinsecuremessageparts.
Althoughitseemsthatthesearesolelyimple-mentationbugs,theirmitigationcanbechallenging.
Forexample,iftheemaildecryptionandemailpresentationstepsareprovidedbydifferentinstances,theemailclientisnotawareoftheencryptedemailmessagestructure.
Thisscenarioisquitecommonwhenemailsecuritygate-waysareused.
Outof48testedmailclients17hadmissingisola-tionwhichwouldallowleakingsecretmessagestoanattacker-controlledwebserverincaseamailgatewaywoulddecryptandsimplyreplacetheencryptedpartwiththeplaintext.
Evenworse,inveemailclients,thecon-ceptshowninFigure6canbeexploiteddirectly:Ap-pleMail(macOS),MailApp(iOS),Thunderbird(Win-dows,macOS,Linux),Postbox(Windows)andMail-Mate(macOS).
Thersttwoclientsbydefaultloadex-ternalimageswithoutaskingandthereforeleaktheplain-textofS/MIMEorOpenPGPencryptedmessages.
ForFigure6:Maliciousemailstructureandmissingcontextboundariesforcetheclienttodecrypttheciphertextandleaktheplaintextusingtheelement.
otherclientsourattacksrequireuserinteraction.
Forex-ample,inThunderbirdandPostboxwecancompletelyredresstheUIwithCSSandtricktheuserintosubmittingtheplaintextwithanHTMLformifheclickssomewhereintothemessage.
NotethatthankstotheMIMEstruc-turetheattackercanincludeseveralciphertextsintooneemailandexltratetheirplaintextsatonce.
ForThun-derbirdthissecurityissueispresentsincev0.
1(2003).
7ExltrationchannelsinemailclientsBackchannelsinemailclientsareknownasprivacyrisks,butthereisnocomprehensiveoverviewyet.
Weper-formedananalysisofexistingbackchannelsbysystem-aticallytesting48clientsandgivethecompleteresultsinAppendixB.
Notethat13ofthetestedclientsdoeithernotsupportencryptionatallorwecouldnotgettheOpenPGPorS/MIMEmodulestoworkandthere-forecouldnottestwhetherbackchannelscanbeusedforexltration.
Thisdistinctionisimportantbecausesomeemailclientsbehavedifferentlyforencryptedandunen-cryptedmessages.
Forexample,HTMLcontentthatcanbeusedtoloadexternalimagesinunencryptedmailsisusuallynotinterpretedfordeprecatedPGP/INLINEmes-sages.
Ontheotherhand,forthreeclientswewereabletobypassremotecontentblockingsimplybyen-cryptingtheHTMLemailcontainingasimpletag.
USENIXAssociation27thUSENIXSecuritySymposium557PGPOSClientS/MIME-MDC+MDCSEWindowsOutlook2007∠∠∠√Outlook2010∠√√√Outlook2013⊥√√√Outlook2016⊥√√√Win.
10Mail∠–––Win.
LiveMail∠–––TheBat!
Postbox∠∠∠∠eMClient∠√∠√IBMNotes∠–––LinuxThunderbird∠∠∠∠Evolution∠√√√Trojita∠√√√KMail⊥√√√Claws√√√√Mutt√√√√macOSAppleMail∠∠∠∠MailMate∠√√√Airmail∠∠∠∠iOSMailApp∠–––CanaryMail–√√√AndroidK-9Mail–√√√R2Mail2∠√∠√MailDroid∠√∠√Nine∠–––WebmailUnitedInternet–√√√Mailbox.
org–√√√ProtonMail–√√√Mailfence–√√√GMail∠–––WebappRoundcube–√√∠HordeIMP⊥√∠∠AfterLogic–√√√Rainloop–√√√Mailpile–√√√∠Exltration(nouserinteraction)√Noexltrationchannel⊥Exltration(withuserinteraction)–EncryptionnotsupportedTable4:ExltrationchannelsforvariousemailclientsforS/MIME,PGPSEIPwithstrippedMDC(-MDC),PGPSEIPwithwrongMDC(+MDC),andPGPSEpackets.
Table4showsthe35remainingclients.
Anattackercanexploit23S/MIMEemailclientsoutofwhicheightrequireeitheraMitMattackeroruserinteractionlikeclickingonalinkorexplicitlyallowingexternalimages.
17S/MIMEclientsallowoff-pathexltrationchannelswithnouserinteraction.
Fromthe35emailclients,28supportOpenPGPand10allowoff-pathexltrationchannelswithnouserinteraction.
FiveclientsallowSEIPciphertextswithstrippedMDCandignorewrongMDCsiftheyexist.
SixclientssupportSEciphertexts.
Threeclients–whichshowOpenPGPmessagesasplaintextonly–aresecureagainstautomatedbackchannels,butarestillvulnerabletobackchannelsthatrequiremorecomplexuserinterac-tion.
7.
1WebcontentinemailclientsHTML.
ThemostprominentformofHTMLcontentareimages.
Ofthetested48emailclients,13loadex-ternalimagesbydefault.
For10ofthem,thiscanbeturnedoffwhereasthreeclientshavenooptiontoblockremotecontent.
Allotherclientsblockexternalimagesbydefaultorexplicitlyasktheuserbeforedownloading.
WeanalyzedallHTMLelementsthatcouldpoten-tiallybypasstheblockinglterandtriggerabackchan-nelusingacomprehensivelistofHTML4,HTML5andnon-standardHTMLelementsthatallowincludingURIs.
Foreachelement-attributecombination,linkswerebuiltusingavarietyofwell-known4andunofcial5URIschemesbasedontheassumptionthathttp://linksmaybeblacklistedbyamailclientwhileothersmightbeallowed.
Weaddedspeciclink/metatagsintheHTMLheader.
Inaddition,wetestedagainstthevectorsfromtheEmailPrivacyTester6projectandtheCure53HTTPLeaks7repository.
Thisextensivelistoftest-casesallowedustobypassexternalcontentblockingin22emailclients.
CascadingStyleSheets(CSS).
MostmailclientsallowCSSdeclarationstobeincludedinHTMLemails.
BasedontheCSS2andCSS3standardsweassembledanextensivelistofpropertiesthatallowincludedURIs,likebackground-image:url("http://efail.
de").
Theseallowedby-passingremotecontentblockingon11clients.
JavaScript.
Weusedwell-knownCrossSiteScriptingtestvectors8,9andplacedtheminvariousheadereldslikeSubject:aswellasinthemailbody.
Weidenti-edvemailclientswhicharepronetoJavaScriptexe-cution,allowingtheconstructionofparticularlyexiblebackchannels.
7.
2S/MIMEspecicbackchannelsOCSPrequests.
MailclientscanusetheOnlineCer-ticateStatusProtocol(OCSP)tocheckthevalidityofX.
509certicatesthatareincludedinS/MIMEsigna-tures.
OCSPworksasfollows:theclientdecryptstheemail,parsesthecerticateandobtainstheURLoftheOCSP-responder.
Theclientthensendstheserialnum-berofthecerticateviaHTTPPOSTtotheresponder4https://www.
w3.
org/wiki/UriSchemes5https://github.
com/Munter/schemes6https://www.
emailprivacytester.
com/7https://github.
com/cure53/HTTPLeaks8https://www.
owasp.
org/index.
php/XSS_Filter_Evasion_Cheat_Sheet9http://html5sec.
org55827thUSENIXSecuritySymposiumUSENIXAssociationandobtainsadatastructurewithstatusinformationaboutthecerticate.
Usingthischannelfordataexltrationrequiresre-placingtheURLciphertextblockswithothercipher-textblocks.
Intypicalscenariosthisiscomplicatedbytwofactors:One,theOCSP-responder'sURLispartofalargerbase64encodeddatastructure.
Therefore,anattackermustbecarefulnottodestroythebase64-decodingprocessbycarefullyselectingormaskingtheplaintext.
Two,ifavalidcerticatechainisused,theOCSP-responder'sURLiscryptographicallysignedwhichmakesthisbackchannelunusableaslongasthesignatureisproperlychecked.
ElevenclientsperformedOCSPrequestsforvalidcerticatesfromatrustedCA.
CRLrequests.
SimilartoOCSP,CerticateRevoca-tionLists(CRLs)areusedtoobtainrecentstatusinfor-mationaboutacerticate.
UnlikeOCSP,aCRLispe-riodicallyrequestedandcontainsalistofmultipleserialnumbersofrevokedcerticates.
Requestingthelistin-volvesanHTTPrequesttotheserverholdingtheCRLandtheCRLbackchannelisverysimilartotheOCSPbackchannel.
TenclientsperformedCRLrequestsforvalidcerticatesfromatrustedCA,oneclientevencon-nectedtoanuntrusted,attacker-controlledwebserver.
Intermediatecerticates.
S/MIMEisbuiltaroundtheconceptofhierarchicaltrustandrequiresfollowingacer-ticatechainbacktoatrustedroot.
Ifthecerticateisincompleteandintermediatecerticatesaremissing,thechaincannotbeveried.
Toremedythis,aCAmayaugmentcerticateswithanURLtothenextlinkinthechain.
AclientcanquerythisURLtoobtainthemissingcerticates.
Theserequestsforintermedi-atecerticatescanbeusedasabackchannel.
LikethebackchannelsviaOCSPandCRLrequests,thisismadedifcultbythebase64encoding.
However,thesignaturecanonlybeveriedaftertheintermediatecerticatewasobtained.
Thismakesexploitationofthischannelmucheasier.
Sevenclientsrequestedintermediatecerticatesfromanattacker-controlledLDAPand/orwebserver.
7.
3OpenPGPspecicbackchannelsAnemailclientreceivingaPGP-signedmessagemaytrytoautomaticallydownloadthecorrespondingpublickey.
Therearevariousprotocolstoachievethis,forex-ampleDANE[24],HKP[25]orLDAP[26][27].
WeobservedoneclienttryingtoobtainthepublickeyforagivenkeyID.
Thiscanpotentiallybeabusedbymal-leabilitygadgetstoleakfourbytesofplaintext.
Wealsoapplied33PGP-relatedemailheadersthatrefertopublickeys(e.
g.
X-PGP-Key:URI),butnoneofthetestedclientsperformedarequesttothegivenURL,thereforetheissueisonlyrelevanttoaMitMattacker.
7.
4ExternalattachmentsThemessage/external-bodycontenttypeallowsreferencestoexternalresourcesasMIMEpartsinsteadofdirectlyincludingwithinthemail.
Thisisaknowntech-niquetobypassvirusscannersrunningonamailgate-way.
However,therearevariousproprietaryvariantsofthisheader,forwhichoneemailclientautomaticallyper-formedaDNSrequestfortheexternalattachment'shost-name.
Itisnoteworthythatthiswasdoneautomatically,theemaildidnothavetobeexplicitlyopened.
7.
5EmailsecuritygatewaysEmailsecuritygatewaysaretypicallyusedinlargeen-terprisestosecuretheoutgoingcommunicationwithS/MIMEorOpenPGP.
Thisensuresthatemployeesdonothavetoinstallanyextensionsorgeneratekeys,andthattheiremailsareautomaticallyencryptedandde-crypted.
Ourattacksareapplicabletoemailsecuritygatewaysaswell.
Infact,preventingtheshowedattacksinthesescenarioscouldbeevenmorechallenging,especiallyfortheMIME-relatedissues.
Thereasonisthatagatewayisonlyusedtodecrypttheincomingemailsandhasnoknowledgeoftheemailprocessingclients.
Wewerenotabletosystematicallyanalyzesecuritygatewaysastheyarenoteasilyaccessible.
Nevertheless,wehadachancetotesttwoappliances.
Thecongu-rationoftherstonewasinsecureandwecouldndadirectexltrationexploit.
Thesecondgatewaywascon-guredcorrectlyandwewerenotabletondanydirectexploitsinthelimitedtimewehadfortheevaluation.
8MitigationsBackchannelsarecritical,becausetheyprovideawaytoinstantlyobtaintheplaintextofanemail.
Reliablyblockingallbackchannels,includingthosenotbasedonHTML,wouldpreventalltheattacksaspresented.
How-ever,itdoesnotxtheunderlyingvulnerabilityintheS/MIMEandOpenPGPstandards.
Inabroadersce-nario,anattackercouldalsoinjectbinaryattachmentsormodifyalreadyattachedones,suchthatexltrationisdonelaterevenifnoemailclientisinvolved.
Therefore,blockingnetworkrequestsisonlyashort-termsolution.
Inthefollowingsectionwepresentlong-termmitigationswhichrequireupdatingthestandards.
USENIXAssociation27thUSENIXSecuritySymposium5598.
1CounteringdirectexltrationattacksSameoriginpolicyforemail.
ThecomplexityofHTML,CSSandMIMEmakesitpossibletomixen-cryptedandplaintextcontents.
Ifanexltrationchan-nelisavailable,thiscanleadtodirectleaksofdecryptedplaintexts,independentlyofwhethertheciphertextisau-thenticatedornot.
Inwebscenarios,atypicalprotec-tionagainstthesekindsofattacksisthesameoriginpol-icy[28].
Similarprotectionmechanismscouldbeap-pliedinemailscenariosaswell.
Theseshouldenforcethatemailpartswithdifferentsecuritypropertiesarenotcombined.
However,thismitigationishardtoenforceineveryscenario.
Forexample,emailgatewaystypicallyusedincompaniesprocessencryptedemailsandforwardtheplaindatatoemailclientsusedbytheemployees.
Emailclientshavenoknowledgewhethertheoriginalmessagewasencryptedornot.
Insuchscenariosthiscountermea-suremustbecombinedwithdifferenttechniques.
Anef-fectivemitigationforanemailgatewaywouldbetodis-playonlytherstemailbodypartandconvertfurtherbodypartsintoattachments.
8.
2CounteringmalleabilitygadgetattacksTheS/MIMEstandarddoesnotprovideanyeffectivese-curitymeasurescounteringourattacks.
OpenPGPpro-videsMessageModicationCodesandwecouldobserveseveralOpenPGPimplementationsthatwerenotvulner-abletoourattacksbecausetheydroppedciphertextswithinvalidMDCs.
Unfortunately,theOpenPGPstandardisnotclearabouthandlingMDCfailures.
ThestandardonlyvaguelystatesthatanyfailuresintheMDCcheck"MUSTbetreatedasasecurityproblem"and"SHOULDbereportedtotheuser"[18]butlacksadenitiononhowtodealwithsecurityproblems.
Furthermore,thestan-dardstillsupportsSEpacketswhichoffernointegrityprotection.
Fromthisperspective,thesecurityvulnera-bilitiesobservedinGnuPGandEnigmailarestandard-conforming,asGnuPGreturnsanerrorcodeandprintsoutaspecicerrormessage.
OurexperimentsshowedthatdifferentclientsdealdifferentlywithMDCfailures(seeTable4).
Inthelong-term,updatingtheS/MIMEandOpenPGPstandardsisinevitabletomeetmoderncryptographicbestpracticesandintroduceauthenticatedencryptional-gorithms.
Authenticatedencryption(AE).
Ourattackwouldbepreventediftheemailclientdetectschangesintheci-phertextduringdecryptionandpreventsitfrombeingdisplayed.
Onarstthought,makinganAEblockci-phersuchasAES-GCMthedefault,wouldpreventtheattack.
AlthoughCMSdenesanAuthenticatedDatatype[29],S/MIME'scurrentspecicationdoesnot.
TherewereeffortstointroduceauthenticatedencryptioninOpenPGPwhichis,however,expired[30].
Byintroducingthesealgorithms,thestandardwouldneedtoaddressbackwardscompatibilityattacksandhandlingofstreaming-baseddecryption.
Solvingbackwardscompatibilityproblems.
Inabackwardscompatibilityattackanattackertakesasecureauthenticatedciphertext(e.
g.
,AES-GCM)andforcesthereceivertouseaweakencryptionmethod(e.
g.
,AES-CBC)[31].
Topreventtheseattacks,usageofdifferentkeysfordifferentcryptographicprimitiveshastobeen-forced.
Forexample,thedecryptedkeycanbeusedasaninputintoakeyderivationfunctionKDFtogetherwithanalgorithmidentier.
Thiswouldenforcedifferentkeysfordifferentalgorithms:kAES-CBC=KDF(k,"AES-CBC")(1)kAES-GCM=KDF(k,"AES-GCM")(2)AlthoughanemailclientcoulduseS/MIME'scapabili-tieslisttopromotemoresecureciphersineverysigna-ture,anattackercanstillforwardemailssheobtainedinthepast.
Theemailclientmaythen(a)processtheoldemailandstaysusceptibletoexltrationattacksor(2)donotprocesstheemailandbreakinteroperability.
Streaming-baseddecryption.
OpenPGPusesstream-ing,i.
e.
itpassesonplaintextpartsduringdecryptioniftheciphertextislarge.
Thisfeaturecollideswithourre-questforAEciphersbecausemostAEciphersalsosup-portstreaming.
Intheeventthattheciphertextwasmod-ied,itwillpassonalreadydecryptedplaintext,alongwithanerrorcodeattheend.
Iftheseplaintextpartsareinterpreted,exltrationchannelsmayarisedespiteusinganAEcipher.
Wethinkitissafetoturnoffstreamingintheemailcontextbecausethesizeofemailciphertextsislimitedandcanbehandledbymoderncomputers.
Other-wise,iftheciphertextsizeisaconcern,theemailshouldbesplitintochunkswhichareencryptedandauthenti-catedsothatnostreamingisneeded.
Acryptographicapproachtosolvethisproblemwouldbetouseamodeofoperationwhichdoesnotallowfordecryptingtheci-phertextbeforeitsauthenticityisvalidated.
Forexample,AES-SIVcouldbeused[32].
NotethatAES-SIVworksintwophasesandthusitdoesnotoffersuchperformancease.
g.
,AES-GCM.
56027thUSENIXSecuritySymposiumUSENIXAssociation9RelatedworkIn2000KatzandSchneierdescribedachosen-ciphertextattack[33]thatblindsanuncompressedciphertext,whichtheysendinaspoofedemailtothevictim.
Theythenhopethatthevictimrepliestotheemailwiththeblindedciphertext,thattheycanthenunblind.
Thisat-tackrequiresacooperatingvictimanddoesnotworkagainstcompressedplaintexts.
In2001Davisdescribed"surreptitiousforwarding"attacksandtheirapplicabilitytoS/MIME,PKCS#7,MOSS,PEM,PGP,andXML[34]inwhichanattackercanre-signorre-encrypttheoriginalemailandforwarditontoathirdperson.
In2002Perrinpresentedadowngradeattack,whichremovestheintegrityprotectionturningaSEIPintoaSEdatapacket[20].
In2015,Magaziniusshowedthatthisdowngradeattackisapplicableinpractice[21].
In2005MisterandZuccheratodescribedanadaptive-chosen-ciphertextattack[22]exploitingOpenPGP'sin-tegrityquickcheck.
Theattackerneed215queriestode-crypttwoplaintextbytesperblock.
Theattackrequiresahighnumberofqueries,whichmakestheattackunprac-ticalforemailencryption.
Strenzke[19]improvedoneofDavis'attacksandnotedthatanattackercanstripasignatureandre-signtheencryptedemailwithhisprivatekey.
Hesendstheemailtothevictimwhohopefullyrespondswithanemailin-cludingthedecryptedciphertext.
ManyattacksabuseCBCmalleabilitypropertytocre-atechosen-ciphertextattacks[35–38].
PracticalattackshavebeenshownagainstIPSec[39,40],SSH[41,42],TLS[43–46],orXMLEncryption[47].
Overall,theat-tackerusestheserverasanoracle.
ThisisnotpossibleintypicalOpenPGPandS/MIMEscenarios,sinceusersareunlikelytoopenmanyemailswithoutgettingsus-picious.
SomeoftheseattacksexploitthatwithCBCitisalsopossibletoencryptarbitraryplaintextblocksorbytes[38,40,47].
Forexample,RizzoandDuongdescribedhowtoturnadecryptionoracleintoanen-cryptionoracle.
TheyusedtheirCBC-RtechniquetocomputecorrectheadersandissuemaliciousJSFviewstates[38].
In2005,Fruwirth,theauthoroftheLinuxUniedKeySetup(luks),wroteacompendiumofattacksandinse-curepropertiesofCBC[48]intheharddiskencryptioncontext.
Laterin2013,LellpresentedapracticalexploitforCBCmalleabilityagainstaUbuntu12.
04installationthatisencryptedusingluks[49]withCBC.
AnattackverysimilartoLell'swasdescribedin2016intheOwn-cloudserversideencryptionmodule[50].
In2017Cure53analyzedthesecurityofEnig-mail[51].
ThereportshowsthatsurreptitiousforwardingisstillpossibleandthatitispossibletospoofOpenPGPsignatures.
AcknowledgementsTheauthorsthankMarcusBrinkmannandKaiMichaelisforinsightfuldiscussionsaboutGnuPG,LennartGrahl,Yves-NoelWewelerandMarcDangschatfortheirearlyworkaroundX.
509backchannels,HannoB¨ockforhiscommentsonAES-SIVandourattackingeneral,TobiasKappertforcountlessremarksregardingthedeatealgo-rithm,andouranonymousreviewersformanyinsightfulcomments.
SimonFriedbergerwassupportedbytheCommis-sionoftheEuropeanCommunitiesthroughtheHorizon2020programunderprojectnumber643161(ECRYPT-NET).
JurajSomorovskywassupportedthroughtheHorizon2020programunderprojectnumber700542(FutureTrust).
ChristianDresenandJensM¨ullerhavebeensupportedbytheresearchtraininggroup'HumanCenteredSystemSecurity'sponsoredbythestateofNorth-RhineWestfalia.
References[1]TheRadicatiGroup,Inc.
,"Emailstatisticsreport,2017-2021,"Feb.
2017.
[2]Wikileaks,"Vpcontendersarahpalinhacked,"Sept.
2008.
https://wikileaks.
org/wiki/VP_contender_Sarah_Palin_hacked.
[3]Wikileaks,"Sonyemailarchive,"Apr.
2015.
https://wikileaks.
org/sony/emails/.
[4]Wikileaks,"Hillaryclintonemailarchive,"Mar.
2016.
https://wikileaks.
org/clinton-emails/.
[5]Wikileaks,"Thepodestaemails,"Mar.
2016.
https://wikileaks.
org/podesta-emails/.
[6]K.
Thomas,F.
Li,A.
Zand,J.
Barrett,J.
Ranieri,L.
Invernizzi,Y.
Markov,O.
Comanescu,V.
Er-anti,A.
Moscicki,D.
Margolis,V.
Paxson,andE.
Bursztein,eds.
,Databreaches,phishing,ormal-wareUnderstandingtherisksofstolencreden-tials,2017.
[7]E.
Bursztein,B.
Benko,D.
Margolis,T.
Pietraszek,A.
Archer,A.
Aquino,A.
Pitsillidis,andS.
Sav-age,"Handcraftedfraudandextortion:Manualac-counthijackinginthewild,"inIMC'14Proceed-USENIXAssociation27thUSENIXSecuritySymposium561ingsofthe2014ConferenceonInternetMeasure-mentConference,(1600AmphitheatreParkway),pp.
347–358,2014.
[8]M.
Green,"What'sthematterwithpgp,"Aug.
2014.
https://blog.
cryptographyengineering.
com/2014/08/13/whats-matter-with-pgp/.
[9]M.
Marlinspike,"Gpgandme,"Feb.
2015.
https://moxie.
org/blog/gpg-and-me/.
[10]F.
Valsorda,"I'mthrowinginthetowelonPGP,andIworkinsecurity,"Dec.
2016.
https://arstechnica.
com/information-technology/2016/12/op-ed-im-giving-up-on-pgp/.
[11]AmnestyInternational,"Verschl¨usselteKom-munikationviaPGPoderS/MIME.
"https://www.
amnesty.
de/keepitsecret.
Ac-cessed:2018-02-22.
[12]ElectronicFrontierFoundation,"Howto:UsePGPforWindows.
"https://ssd.
eff.
org/en/module/how-use-pgp-windows.
Accessed:2018-02-22.
[13]UnitedNationsEducationalScienticandCul-turalOrganizationandReportersWithoutBorders,SafetyGuideforJournalists–aHandbookforRe-portersinHigh-RiskEnvironments.
CreateSpaceIndependentPublishingPlatform,2016.
[14]P.
Resnick,"Internetmessageformat,"October2008.
RFC5322.
[15]N.
FreedandN.
Borenstein,"Multipurposeinternetmailextensions(mime)partone:Formatofinternetmessagebodies,"November1996.
RFC2045.
[16]B.
RamsdellandS.
Turner,"Secure/multipurposeinternetmailextensions(s/mime)version3.
2mes-sagespecication,"January2010.
RFC5751.
[17]R.
Housley,"Cryptographicmessagesyntax(cms),"September2009.
RFC5652.
[18]J.
Callas,L.
Donnerhacke,H.
Finney,D.
Shaw,andR.
Thayer,"Openpgpmessageformat,"November2007.
RFC4880.
[19]F.
Strenzke,"Improvedmessagetakeoverat-tacksagainsts/mime,"Feb.
2016.
https://cryptosource.
de/posts/smime_mta_improved_en.
html.
[20]"Openpgpsecurityanalysis,"Sept.
2002.
https://www.
ietf.
org/mail-archive/web/openpgp/current/msg02909.
html.
[21]J.
Magazinius,"Openpgpseipdowngradeat-tack,"Oct.
2015.
http://www.
metzdowd.
com/pipermail/cryptography/2015-October/026685.
html.
[22]S.
MisterandR.
Zuccherato,"Anattackoncfbmodeencryptionasusedbyopenpgp.
"CryptologyePrintArchive,Report2005/033,2005.
https://eprint.
iacr.
org/2005/033.
[23]P.
Deutsch,"Deatecompresseddataformatspeci-cationversion1.
3,"May1996.
RFC1951.
[24]P.
Wouters,"Dns-basedauthenticationofnamedentities(dane)bindingsforopenpgp,"August2016.
RFC7929.
[25]D.
Shaw,"TheOpenPGPHTTPKeyserverPro-tocol(HKP),"Internet-Draftdraft-shaw-openpgp-hkp-00,InternetEngineeringTaskForce,Mar.
2003.
WorkinProgress.
[26]G.
Good,"Theldapdatainterchangeformat(ldif)-technicalspecication,"June2000.
RFC2849.
[27]"Howtosetupanopenldap-basedpgpkey-server.
"https://wiki.
gnupg.
org/LDAPKeyserver.
[28]"Sameoriginpolicy,"Jan.
2010.
https://www.
w3.
org/Security/wiki/Same_Origin_Policy.
[29]R.
Housley,"Cryptographicmessagesyntax(cms)authenticated-enveloped-datacontenttype,"November2007.
RFC5083.
[30]"Modernizingtheopenpgpmessageformat,"2015.
https://tools.
ietf.
org/html/draft-ford-openpgp-format-00.
[31]T.
Jager,K.
G.
Paterson,andJ.
Somorovsky,"OneBadApple:BackwardsCompatibilityAttacksonState-of-the-ArtCryptography,"inNetworkandDistributedSystemSecuritySymposium(NDSS),February2013.
[32]D.
Harkins,"Syntheticinitializationvector(siv)au-thenticatedencryptionusingtheadvancedencryp-tionstandard(aes),"October2008.
RFC5297.
[33]J.
KatzandB.
Schneier,"Achosenciphertextat-tackagainstseverale-mailencryptionprotocols,"in56227thUSENIXSecuritySymposiumUSENIXAssociationProceedingsofthe9thConferenceonUSENIXSe-curitySymposium-Volume9,SSYM'00,(Berke-ley,CA,USA),pp.
18–18,USENIXAssociation,2000.
[34]D.
Davis,"Defectivesign&encryptins/mime,pkcs#7,moss,pem,pgp,andxml,"inProceedingsoftheGeneralTrack:2001USENIXAnnualTech-nicalConference,(Berkeley,CA,USA),pp.
65–78,USENIXAssociation,2001.
[35]S.
Vaudenay,"Securityawsinducedbycbcpadding-applicationstossl,ipsec,wtls.
.
,"inEUROCRYPT(L.
R.
Knudsen,ed.
),vol.
2332ofLectureNotesinComputerScience,pp.
534–546,Springer,2002.
[36]K.
PatersonandA.
Yau,"PaddingOracleAttacksontheISOCBCModeEncryptionStandard,"inTopicsinCryptology–CT-RSA2004,vol.
2964ofLectureNotesinComputerScience,SpringerBerlin/Heidelberg,Feb.
2004.
[37]C.
J.
Mitchell,"Errororacleattacksoncbcmode:Isthereafutureforcbcmodeencryption,"inIn-formationSecurity(J.
Zhou,J.
Lopez,R.
H.
Deng,andF.
Bao,eds.
),(Berlin,Heidelberg),pp.
244–258,SpringerBerlinHeidelberg,2005.
[38]J.
RizzoandT.
Duong,"Practicalpaddingora-cleattacks,"inProceedingsofthe4thUSENIXconferenceonOffensivetechnologies,WOOT'10,(Berkeley,CA,USA),pp.
1–8,USENIXAssocia-tion,2010.
[39]J.
P.
DegabrieleandK.
G.
Paterson,"AttackingtheIPsecstandardsinencryption-onlycongura-tions,"inIEEESymposiumonSecurityandPri-vacy,pp.
335–349,IEEEComputerSociety,2007.
[40]J.
P.
DegabrieleandK.
G.
Paterson,"Onthe(in)securityofIPsecinMAC-then-encryptcon-gurations,"inACMConferenceonComputerandCommunicationsSecurity(E.
Al-Shaer,A.
D.
Keromytis,andV.
Shmatikov,eds.
),pp.
493–504,ACM,2010.
[41]M.
R.
Albrecht,K.
G.
Paterson,andG.
J.
Wat-son,"Plaintextrecoveryattacksagainstssh,"inProceedingsofthe200930thIEEESymposiumonSecurityandPrivacy,SP'09,(Washington,DC,USA),pp.
16–26,IEEEComputerSociety,2009.
[42]M.
R.
Albrecht,J.
P.
Degabriele,T.
B.
Hansen,andK.
G.
Paterson,"Asurfeitofsshciphersuites,"inProceedingsofthe2016ACMSIGSACConferenceonComputerandCommunicationsSecurity,CCS'16,(NewYork,NY,USA),pp.
1480–1491,ACM,2016.
[43]N.
J.
A.
FardanandK.
G.
Paterson,"Luckythir-teen:Breakingthetlsanddtlsrecordprotocols,"in2013IEEESymposiumonSecurityandPrivacy,pp.
526–540,May2013.
[44]M.
R.
AlbrechtandK.
G.
Paterson,"Luckymi-croseconds:Atimingattackonamazon'ss2nim-plementationoftls,"inAdvancesinCryptology–EUROCRYPT2016(M.
FischlinandJ.
-S.
Coron,eds.
),(Berlin,Heidelberg),pp.
622–643,SpringerBerlinHeidelberg,2016.
[45]G.
Irazoqui,M.
S.
Inci,T.
Eisenbarth,andB.
Sunar,"Lucky13strikesback,"inProceedingsofthe10thACMSymposiumonInformation,ComputerandCommunicationsSecurity,ASIACCS'15,(NewYork,NY,USA),pp.
85–96,ACM,2015.
[46]J.
Somorovsky,"Systematicfuzzingandtestingoftlslibraries,"inProceedingsofthe2016ACMSIGSACConferenceonComputerandCommuni-cationsSecurity,CCS'16,(NewYork,NY,USA),pp.
1492–1504,ACM,2016.
[47]T.
JagerandJ.
Somorovsky,"HowToBreakXMLEncryption,"inThe18thACMConferenceonCom-puterandCommunicationsSecurity(CCS),Oct.
2011.
[48]C.
Fruhwirth,"Newmethodsinharddisken-cryption,"July2005.
http://clemens.
endorphin.
org/nmihde/nmihde-A4-ds.
pdf.
[49]J.
Lell,"Practicalmalleabilityattackagainstcbc-encryptedlukspartitions,"2013.
[50]H.
B¨ock,"Pwncloud–badcryptointheowncloudencryptionmodule,"Apr.
2016.
https://blog.
hboeck.
de/archives/880-Pwncloud-bad-crypto-in-the-Owncloud-encryption-module.
html.
[51]"Pentest-reportenigmail,"Dec.
2017.
https://enigmail.
net/download/other/Enigmail%20Pentest%20Report%20by%20Cure53%20-%20Excerpt.
pdf.
AUnsuccessfulbackchanneltestsWepursuedfurthertestswhichwerenotsuccessfulbutaredocumentedhereforthesakeofcompleteness.
USENIXAssociation27thUSENIXSecuritySymposium563Spamdatasets.
Wecheckedwhetherspammersmayalreadybeawareofbypassesforremotecontentblock-inginemailclientsandanalyzedtwolargespamdatasets10,11containingovertenmillionsofspamemailsaltogetherrangingfrom1997to2018.
However,wefoundthatspammersdonotuseorarenotawareofby-passesforcontentblockingastheyonlyincludedwell-knowntechniquetotraceifanemailisactuallyread.
Genericemailheaders.
Therearevariousstandard-izedandproprietaryemailheaders12whichallowtoin-cludeURIs.
Furthermore,weusedvariouspublicemaildatasetstocompilealistof9,400mailheaderswhichcontainURLs.
Wetestedthoseheadersagainstallemailclients,butnonetriggeredwiththeexceptionofexternalattachmentsmentionedinSection7.
4Anti-spoongheaders.
Weincludedemailheaderstoghtspam(SPF,DKIM),howeverthetriggeredDNSre-questsattheMTAlevel,notwhenmailwasopenedintheMUA.
ItishowevernoteworthythattwoemailclientsperformedaDNSlookupsforthehostnamepartofthesenderemailaddressatthetimethemailwasopened.
althoughthisisaprivacyissue,wecannotuseittoforexltrationbecausetheDNSrequestwasnolongertrig-geredforFrom:headerwithintheencryptedpartofthemessage.
Messagedispositionnotication.
Weidentiedsevenstandardizedandproprietaryemailheaderswhichre-questaconrmationmailattestingthatthemessagehasbeenread.
Twomailclientsautomaticallysendconr-mationemailswhichhasaprivacyimpactbutcannotbeusedasanexltrationchannelbecausethemailwasnottriggeredifthemessagedispositionnoticationheaderwaswithintheencryptedpart.
Allotherclientsdonotsupportthefeatureorexplicitlyasktheuserbeforesend-ingamessagedispositionnotications.
Filepreview.
Someemailclientstrytogenerateapre-viewforattachedles.
Wepreparedspecially-craftedPDF,SVG,vCardandvCalendarleswhichcontainhy-perlinks,triggeraconnectionorexecuteJavaScriptwhenopened.
Howeverinthepreviewedversionnoneoftheseactionswastakenforanyofthetestedclients.
10http://untroubled.
org/spam/11http://artinvoice.
hu/spams/12https://www.
iana.
org/assignments/message-headers/message-headers.
xhtmlBBackchannelanalysisThissectionpresentsthetablesummarizingourresultsonbackchannelsinemailclients.
56427thUSENIXSecuritySymposiumUSENIXAssociationSupportBackchannelsS/MIMEPGPEmailHTML/CSS/JSPKIWindowsOutlook2007(12.
0.
4518.
1014)nativeGPG4winH15P1I1I2I3Outlook2010(14.
0.
7190.
5000)nativeGPG4winP1I2I3Outlook2013(15.
0.
4989.
1000)nativeGPG4winI2I3Outlook2016(16.
0.
4266.
1001)nativeGPG4WinI2I3Win.
8Mail(17.
4.
9600.
16384)n/an/a+H1H6Win.
10Mail(17.
8730.
21865.
0)nativen/a+Win.
LiveMail(16.
4.
3528.
0331)nativen/aH17I1I2TheBat!
(8.
2.
0)nativeGnuPGE1Postbox(5.
0.
20)nativeEnigmailP3I2eMClient(7.
1.
31849.
0)nativenativeE3J3I1I2IBMNotes(9.
0.
1)nativen/aH13H16P2J1Foxmail(7.
2.
8)n/an/a*PegasusMail(4.
72.
572)n/aPMPGPE1H14P2P4LinuxThunderbird(52.
5.
2)nativeEnigmailH2I2Evolution(3.
22.
6)nativeGnuPGH3Trojita(0.
7-278)nativeGnuPGH3I3KMail(5.
2.
3)nativeGnuPGI3Claws(3.
14.
1)pluginGPGpluginI3Mutt(1.
7.
2)nativeGnuPGI3macOSAppleMail(11.
2)nativeGPGToolsE2+I1I2I3MailMate(1.
10)nativeGPGToolsH3I1I2I3Airmail(3.
5.
3)pluginGPG-PGP+H10H11H14iOSMailApp(11.
2.
2)nativen/a+I1CanaryMail(1.
17)n/anativeE4+Outlook(2.
56.
0)n/an/a*AndroidK-9Mail(5.
403)n/aOpenKeychainR2Mail2(2.
30)nativenativeH10J2MailDroid(4.
81)FlipdogFlipdogH4H5H14H15J2Nine(4.
1.
3a)nativen/aK2H4H5H14H15J1WebmailGMX,Web.
de,.
.
.
n/aMailvelope+K1C7C8C9Mailbox.
orgn/aMailvelopeK1C9Hushmailn/anativeProtonMailn/aOpenPGP.
jsH3H4H12H14H15C1MailfencenativeOpenPGP.
jsH8C5C12C15I3GMailnativen/a+Outlook.
comnativen/a+iCloudMailn/an/a+YahooMailn/an/aC5C11FastMailn/an/a+Mail.
Run/an/a*ZohoMailn/an/aH9C12P1WebappRoundcube(1.
3.
4)nativeEnigmaH7C3AfterLogic(7.
7.
9)pluginOpenPGP.
jsH4C2C10C13C14C16Rainloop(1.
11.
3)n/aOpenPGP.
jsC4C13C14Mailpile(1.
0.
0rc2)n/aGnuPG#GroupwareExchangeOWA(15.
1.
1034.
32)nativen/aI1I2GroupWise(14.
2.
2)nativen/aH9C2C5C11C12Horde(5.
2.
22/IMP6.
2.
21)nativeGnuPGI4BackchanneltoarbitraryURIBackchanneltoxedURITable5:Backchannelsforvariousemailclients.
(Legendonnextpage.
)USENIXAssociation27thUSENIXSecuritySymposium565Legend+Remoteimagesareloadedbydefaultbutthiscanbedeactivated*Remoteimagesareloadedbydefaultanditcannotbedeactivated#RemoteimagesareloadedthroughprefetchinginmodernbrowsersPKIrequestsI1RequestforintermediateS/MIMEcerticateareperformedtoanattacker-controlledURII2OCSPrequeststoaxedCAURLareperformedforvalid/trustedS/MIMEsignedemailsI3CRLrequeststoaxedCAURLareperformedforvalid/trustedS/MIMEsignedemailsI4HKPrequeststokeyserverareperformedtoretrievepublickeysforPGPsignedemailsEncryptedemailsK1RemoteimagesareloadedautomaticallyifthemailisPGP/MIMEencryptedK2RemoteimagesareloadedautomaticallyifthemailisS/MIMEencryptedHTMLattributes(bypassesforremotecontentblocking)H1H2H3H4H5H6H7H8H9H10H11H12H13H14H15H16H17CSSproperties(bypassesforremotecontentblocking)C1@importurl('http://efail.
de');C2body{background-image:url('http://efail.
de');}C3body{background-image:\75\72\6C('http://efail.
de');}C4body{shape-outside:url(http://efail.
de);}C5C6C7body{background:#aaaurl('http://efail.
de');}C8C9ul{list-style:url('http://efail.
de');}itemC10C11ul{list-style-image:url('http://efail.
de');}itemC12C13C14C15C16URIschemes(bypassesforremotecontentblocking)P1P2P3P4JavaScript(bypassesforremotecontentblocking)J1.
.
.
J2J2'EmailheadersE1X-Confirm-Reading-To:user@efail.
deE2Remote-Attachment-Url:http://efail.
deE3From:user@efail.
de(HTTPrequestforfavicon)E4From:user@efail.
de(DNSrequesttohostname)56627thUSENIXSecuritySymposiumUSENIXAssociation