HTTP Digest Integrity

Another look, in light of recent attacks

Version 1.0 Timothy D. Morgan January 5, 2010

Contents
Introduction.....................................................................................................................................................1 Overview of HTTP Digest Authentication..................................................................................................1 RFC 2069 Mode.................................................................................................................................................................................1 auth Mode...........................................................................................................................................................................................2 auth-int Mode.....................................................................................................................................................................................2 Related Attacks...............................................................................................................................................3 SSL/TLS Renegotiation.....................................................................................................................................................................3 HTTP Request Smuggling................................................................................................................................................................4 Mitigation with Digest Authentication.........................................................................................................6 Limitations.......................................................................................................................................................6 Conclusion........................................................................................................................................................7 Acknowledgements........................................................................................................................................7 References........................................................................................................................................................8

H T T P D I G E S T I N T E G R I T Y : A N O T H E R L O O K , I N L I G H T O F R E C E N T AT TA C K S

VERSION 1.0

J A N U A RY 5 , 2 0 1 0

Introduction
Recenthistoryhasproventhatwebcommunicationssecurityishighlylackinginredundancy.Thatis,simplebreaks incommonprotocols,suchasSSL/TLSortheauthenticationmechanismswhichsupportit, oftenleadtocata strophic gaps in security. Recent examples of this fragile architecture abound [0Prfx,DebKeys,MD5CA,OCSP3,ReTLS], and even when protocols and implementations themselves are sound, researchindicatesbrowseruserinterfacescontinuetoleaveroomforseriousattacks[SSLWarn]. ThispaperexploreshowtheseldomusedHTTPdigestauthenticationprotocolcanbeusedtomitigatecertainrecent formsofattack,includingSSL/TLSrenegotiationandsometypesofHTTPrequestsmuggling.

Overview of HTTP Digest Authentication

HTTPdigestauthentication[RFC2617]isdesignedasanincrementalimprovementtoHTTPbasicauthentication, whereusercredentialsaresimplysentincleartextasabase64encodedvalue. HTTPdigestauthenticationisnot intended asa generally secure cryptographic protocol. In fact, if one assumes an attacker can fully control the communications channel between a client and server, digest authentication is vulnerable to maninthemiddle attacks,downgradeattacks,andlikelyotherweaknesses. Digestauthenticationalsodoesnotprovidesecrecyof HTTPheadersorpayloads,whichisaprimaryrequirementformanysecureapplications. Whatdigestauthenticationdoesprovideisrelativesecrecyofusercredentials. Insteadofsendingcleartextpass words,cryptographichashes(digests)aresentwhicharegeneratedbasedontheuserpasswordalongwithseveral othervalues.Inthisway,passiveandactiveattackerscannoteasilytakethecredentialsofanaveuser(whoreuses passwords on multiplesites) and attack other systems. In fact, digest authentication also incorporates web site specificinformationintothehash,preventingtrivialreuseofhashesondifferentwebsites.Withsomeoptionalreplay preventionmechanisms,reuseofhashesonthesamewebsitecanevenbelimitedoravoided. TwoperhapslesserknownfeaturesofHTTPdigestauthenticationareitsintegrityprotectionandserverauthentica tion. Theleveloftheseprotectionsvariesdependingupontheoptionalfeaturessupportedbyclientsandservers. Theseoptionalfeaturesareusedinthreeprimary"qualityofprotection"modes:legacyorRFC2069mode,"auth" mode,and"auth-int"mode.

RFC 2069 Mode

This mode is compatible with [RFC2069] and is used when a server does not advertise a quality of protection (qop=...)flagintheinitialchallenge.Inthismode,thefollowingprimaryvaluesareusedtocomputeaoneway hashsentbacktoaserver: Usernameofauthenticatinguser Passwordoftheauthenticatinguser HTTPauthenticationrealm Serverprovidednoncevaluefromthechallengeresponse URIofthisrequest Methodofthisrequest(GET,POST,etc) Digestoftherequestbody(optional)

Notethatsomeadditionalitemsmaybeincludedinthesehashes,butarenotdeemedparticularlyrelevantforthisdiscussion. Clearly,eveninthisearlyrevisionoftheprotocol,certainelementsareintegrityprotected(HTTPmethodandURI) andthebodyofarequestcanbeprotected,optionally.

C O P Y R I G H T 2 0 1 0 V I RT U A L S E C U R I T Y R E S E A R C H , L L C A L L R I G H T S R E S E RV E D .

1 / 8

H T T P D I G E S T I N T E G R I T Y : A N O T H E R L O O K , I N L I G H T O F R E C E N T AT TA C K S

VERSION 1.0

J A N U A RY 5 , 2 0 1 0

auth Mode
RFC2617introducedrevisionstodigestauthenticationwhichallowforimprovedefficiencyandauthenticationof servers. Whenserversadvertisethe auth or auth-int qualityofprotectionmodes,clientsshouldselectoneof these(asopposedtotheRFC2069mode)andsomeadditionalinformationissentalongtotheserver(andprotected bycryptographichashes): Noncecount Clientnonce

Thenoncecountvalueisintendedtoprovideanefficientwaytomitigatereplayattacksagainstthesameserver withouthavingtorefreshtheservernonce.Theclientnonceisdesignedtoallowclientstoauthenticateserveriden titybyensuringthatserversknowtheuser'spassworddigest(proveninalaterresponseheader).

auth-int Mode
Theauth-intmodeisverysimilartotheauthmode,exceptthatitrequirestherequest'sbodyhashbeincluded. ThisissimplyamoreexplicitversionoftheoptionalrequestbodydigestmodedescribedinRFC2069.

C O P Y R I G H T 2 0 1 0 V I RT U A L S E C U R I T Y R E S E A R C H , L L C A L L R I G H T S R E S E RV E D .

2 / 8

H T T P D I G E S T I N T E G R I T Y : A N O T H E R L O O K , I N L I G H T O F R E C E N T AT TA C K S

VERSION 1.0

J A N U A RY 5 , 2 0 1 0

Related Attacks
SSL/TLS Renegotiation
A seriousflawwasrecentlydiscoveredin SSLandTLSwhichallowsanattacker,positionedon thenetworkin betweenaclientandserver,toinitiateaprotocolrenegotiationandinjectasinglebufferofdataintotheencrypted stream. InthecontextofHTTP,thiscouldtaketheformofaforgedHTTPrequestwhichcanbeveryseriousin certainsituations.However,notethatthisvulnerabilitydoesnotpermitanattackertodecryptinformationsubmitted byeithertheclientorserver,unlesssomeadditionalattacksareconductedwhichrelyonsecondarybehaviorsof eithertheclientorserverapplications. Intheoriginalpaper[ReTLS],twoprimaryattackscenariosweredescribed,onewhereaclientisauthenticatedusing a certificate and the other whereclients areauthenticatedusingHTTP session cookies. In theformer case, the injectedrequestautomaticallyhijackstheclient'sidentity,sincetheconnectionitselfisconsideredtrustedbythe serverandnoauthenticationinformationneedbecarriedinHTTPheaders.However,exploitationofthelattercaseis moretricky,sinceablindlyinjectedrequestwouldnotcarrythenecessaryHTTPheaderstohijackauthentication.In thiscase,anattackercaninsteadinjectanincompleterequestwhichfailstoterminateanHTTPheader.Forexample, ifanattackerweretoinjectapartialrequestwhichlookslike: GET /private/importantAction.cgi?do=evil HTTP/1.1 Host: vulnerable.example.com X-ignore: Here,theattacker'sfinallinewouldnotbeterminatedwithanewline.Thefinalcharacteroftheinjecteddatawouldbeaspace. Next,thevictim'sclientsubmitsabenignrequest,perhapslookinglike: GET /private/boringPage.html HTTP/1.1 Host: vulnerable.example.com Cookie: SessionIdentifier=43218730492374928347923847293

Uponreceivingthesetwopacketsandinterpretingthemasacontinuousstream,thewebserverwouldseeasingle requestwhichlookslike: GET /private/importantAction.cgi?do=evil HTTP/1.1 Host: vulnerable.example.com X-ignore: GET /private/boringPage.html HTTP/1.1 Host: vulnerable.example.com Cookie: SessionIdentifier=43218730492374928347923847293

Here,thewebserverwouldignoretheX-ignoreheader(simplybecauseitwouldn'tknowhowtointerpretit)and theremainingheaderssentbythevictimareeffectivelyhijackedforusebytheattackerinwhateverwebapplication actionhechosetoperform.NotethatmosttypicalsessioncookiesandHTTPbasicauthenticationheaderswouldbe primecandidatesforhijacking. Inavariantofthisattack,AnlKurmulaterdemonstratedhowanattackercouldembedavictim'srequestinthe POSTparametersofanevilrequesttogainaccesstothem[TwTLS].Inthisattack,theinjecteddatawouldlooksome thinglike: POST /sendmessage.cgi HTTP/1.0 recipient=attacker@evil.example.com&message=

C O P Y R I G H T 2 0 1 0 V I RT U A L S E C U R I T Y R E S E A R C H , L L C A L L R I G H T S R E S E RV E D .

3 / 8

H T T P D I G E S T I N T E G R I T Y : A N O T H E R L O O K , I N L I G H T O F R E C E N T AT TA C K S

VERSION 1.0

J A N U A RY 5 , 2 0 1 0

Here,thevictim'srequestwouldbeappendedandtreatedasformdatatobeprocessedbyaserver'sscript.InAnl's example,thepopularTwitterwebsitemadejustsuchascriptavailablewhichcouldprovideanattackeraccesstothe POSTedinformation. In [ExpTLS], Thierry Zoller provides detailed explanations of several attack variants. In oneattack, an injected requestwouldbedesignedtoillicitaredirectcodefromtheservertoanunencrypted(nonSSL)webpage.Iftheuser doesnotnoticethattheyarecontinuingtousetheapplicationoveranunecryptedlink,thenthiscouldbeaneffective attackscenariobyforcingallremainingcommunicationstobeunprotectedusingtoolssuchassslstrip[SS]. Inthefinalvariant,anattackerinjectsafullorpartialTRACErequestwhichcontainsaheaderwithJavaScript.Since TRACEresponsesincludesubmittedheadersintheresponsebody,itmaybepossibletoconvincesomebrowsersto executethisclientsidescriptafteritisreturnedbytheserver.Inthiscase,theuser'ssessioncouldbefullyhijacked usingtechniquesakintocrosssitescriptingexploits.

HTTP Request Smuggling

HTTPrequestsmuggling,asintroducedbyC.Linhart,etal.in[HRS],isageneralclassofattackswhichistypically usedtoeitherpoisonwebcachesorhijackusercredentialsthroughsharedproxies. Intheearlyattackexamples, differencesininterpretationofHTTPrequestsareexploitedtocausewebproxiestointerpretreceiveddataasoneset ofrequestswhilewebserversbehindtheminterpretthesamedataasaseparatesetofrequests.Thedifferencesof interpretationcomeaboutthroughtheuseofmultipleconflictingContent-Lengthheadersaswellasexploitation ofHTTPparsingbugsinproxiesandwebservers. Inonerelevantexample(#5from[HRS]),anattackerisabletohijackavictim'sHTTPbasicauthenticationcredentials, providedthevictimsharesawebproxywiththeattacker,byfirstseedingapartialrequestwithabackendweb server. Forexample,anattackerwouldsendtworequestsbacktobackwhichlooksomethinglike: POST /seed.html HTTP/1.0 Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded Content-Length: {length of "key=value"} Content-Length: {length of all data below} key=valueGET /evil-request.cgi?do-evil=action HTTP/1.0 Content-Length: 0 X-ignore: Here,theattacker'sfinallinewouldnotbeterminatedwithanewline. Inthisexample,thewebproxyacceptsthesecond Content-Length headerasthevalidoneandbelievesitis sendingasinglerequestontothewebserver.However,thewebserverbelievesthefirstContent-Lengthheaderis thevalidoneandrespondstothefirstPOSTrequestwhichisforwardedbacktotheattacker.Theadditionaldatain thestreamistheninterpretedasapartialsecondrequest,butthewebproxyisnotawareofthis.Later,whenavictim comestousetheproxytoaccessthewebserver,hemightsendarequestwhichlookslike: GET /harmless.html HTTP/1.1 Host: example.com Authorization: Basic {victim's credentials}

Butwhenthewebserverreceivesthisrequest(whichcomesacrossthesameTCPconnectionusedbytheproxy)the previouslysubmittedpartialrequestoftheattackeristakentobeaprefixofthevictim'srequest.Theresultinginter pretedrequestis:

C O P Y R I G H T 2 0 1 0 V I RT U A L S E C U R I T Y R E S E A R C H , L L C A L L R I G H T S R E S E RV E D .

4 / 8

H T T P D I G E S T I N T E G R I T Y : A N O T H E R L O O K , I N L I G H T O F R E C E N T AT TA C K S

VERSION 1.0

J A N U A RY 5 , 2 0 1 0

GET /evil-request.cgi?do-evil=action HTTP/1.0 Content-Length: 0 X-ignore: GET /harmless.html HTTP/1.1 Host: example.com Authorization: Basic {victim's credentials}

WhichofcoursehijackstheusercredentialsinmuchthesamewayassomeTLSrenegotiationattacksdo. Overthelastseveralyears,VSRhasidentifiedcustomproxiesandapplicationswhichsufferfromsimilarvulnerabili tieswhereusersupplieddataisusedinbackendHTTPrequests.Inthesesituations,thesimpleinjectionofnewlines oftenleadstoasimilarresultwithouttheneedforContent-Lengthmanipulation. For example, supposea website helplibrary isdesignedaround a frontendscript which accepts parametersas follows: /FetchHelp.cgi?Topic=Login&lang=es-es Fromthere,thisscriptlooksupthetextforthehelptopic"Login",whichisstoredinEnglishtext.Next,iftheuser doesnotdesireEnglish,itsendsthetextontoathirdpartytranslationservicetoobtainthedesiredversion: POST /translate.cgi?from=en-us&to=es-es HTTP/1.1 Host: translator.example.com Authorization: Basic {credentials for translation service} Content-Length: {length of content below} text={text to be translated} However,sincemostwebframeworksautomaticallydecodeURLparameterspriortopassingthemtocustomscripts, theFetchHelp.cgiscriptmustbeverycarefulabouthowusersuppliedvaluesareforwardedoninthebackend request.Forinstance,ifanattackersendsa"lang"parameterof:

lang=es-es%20HTTP/1.1%0d%0aArbitrary-headers-or:%20request%20splitting%0d%0aXignore: Thentheresultingbackendrequestmightlooklikethefollowingifthescriptfailedtovalidateorreencodethe parameter: POST /translate.cgi?from=en-us&to=es-es HTTP/1.1 Arbitrary-headers-or: request splitting X-ignore: HTTP/1.1 Host: translator.example.com Authorization: Basic {credentials for translation service} Content-Length: {length of content below} text={text to be translated} Whilethisparticularexampleisadmittedlycontrived,severalinstancesofthisstyleofheaderinjectionhavebeen identified in the past, even though these do not appear to be well documented in publicly available security resources.Theresultofthesevulnerabilitiescanvarywidely,dependingonthepurposeofthebackendrequestand theamountofinformationattackerscanobtainonthefrontend. Inpractice,ithasbeenpossibleincustomproxy scenariostosplitHTTPrequestsandfollowupwithasecondfrontendrequesttoobtainresultsfromprevious injectedrequests,providedHTTPsessionsaremaintainedonthebackend.

C O P Y R I G H T 2 0 1 0 V I RT U A L S E C U R I T Y R E S E A R C H , L L C A L L R I G H T S R E S E RV E D .

5 / 8

H T T P D I G E S T I N T E G R I T Y : A N O T H E R L O O K , I N L I G H T O F R E C E N T AT TA C K S

VERSION 1.0

J A N U A RY 5 , 2 0 1 0

Mitigation with Digest Authentication

Itappearsthattheattacksdescribedabovecouldbelargelyaddressedthroughtheuseofdigestauthentication. Recallthatdigestauthenticationdoesnotpermittrivialaccesstousercredentialsanditalsoprovidessomeintegrity checkingofURIsandtheHTTPmethod. Ifasiteuseddigestauthentication,anattackercouldcertainlyforgevariousHTTPheaders(ifsheknewwhatURIthe victimwasaccessing),butusefulattackswouldlikelybelimitedtoveryspecificapplicationsandcornercases.For example,considertheX-ignoreinjectioninitiallydescribedinrelationtobothTLSrenegotiationandHTTPrequest smuggling. Here,anattackerreusesavictim'scookieorbasicauthenticationheadertosubmitherownrequests. However,withdigestauthenticationtheURImustmatchtheonepresentedbythevictim,whichwouldgreatly reducethekindsofmaliciousactionsanattackercouldperform. InthecaseofthePOSTrequest(Twitterstyle)attack,credentialsarenotreused,butinsteaddivulgedthroughappli cationspecificbehaviors. Thereforeanattackercouldsurelyobtainthevictim's Authorization header,butthis wouldthenneedtobecrackedwithbruteforceordictionaryattacks.Eventhoughdigestauthenticationutilizesa common cryptographic hash (MD5), using precomputation methods (such as Rainbow Tables[RT])is likelynot feasiblegiventhenumberofsitespecificitemsandnonceswhicharehashedtogether. Therefore,onlyweakuser passwordscouldbetargeted. ProvidedanHTTPSapplicationcontainssomepagewhichredirectsuserstoHTTPpages,injectionattackswhich involve redirecting users to insecure versions of an application would likely work, with some limitations. For instance,aproperlyconfigureddigestauthenticationservershouldnotaddtheinsecureversionofthesitetothelist ofacceptabledomains(originallysentintheWWW-Authenticateheader),whichmeansauser'sbrowserwouldnot sendAuthorizationheadersovertheHTTPprotocolaftertheredirect.However,withsufficienttrickeryavictim mightbeconvincedthattheirsessionhadexpiredanditistimetoreauthenticate. Fromthere,anattackercould conductBasicauthenticationdowngradeattacksoverHTTP,whichmostuserswouldnotnotice. AttacksusinginjectedTRACErequestscouldbeserious,butonlyifawebserverhadthisfeatureenabled(whichis notadvisableforotherreasons[XST])andauser'sbrowsercouldbeconvincedtoexecutethereturnedmalicious script.Ifthisweresuccessful,thenanattackerwouldbeabletosubmitrequestsfromwithintheuser'sownbrowser toperformactionsontheirbehalf. Insummary,useofHTTPdigestauthenticationshouldmitigatethemajorityofcurrentlyknownexploitsforHTTP basedTLSrenegotiationandsomesubsetofHTTPrequestsmugglingattacks.However,thisshouldnotbeconsid eredalongtermfixforTLSrenegotiationproblems,butinsteadasastopgapmeasureuntilpermanentcorrectionsto SSL/TLSsoftwareiswidelydeployed.

Limitations
OnemightbeconvincedatthispointthatHTTPdigestauthenticationishandsdownabettersolutionthanHTTP basicauthentication,andattimes,evencookiebasedsessionmanagement.However,thedevilisinthedetailsand manycommonimplementationsaresimplynotmatureenoughforseamlesseverydayuse. Forexample,accordingto[AMAD],InternetExplorerversions5and6failtoincludetheURI'squerystringinthe digest hash, which creates incompatibilities and limits the efficacy of URI integrity protection. Apache's mod_auth_digest,foritspart,hasstillnotimplementedseveralimportantsecurityfeaturesincludingthe MD5sess algorithm,noncecountchecking,and auth-int support. Mozilla'sFirefoxalsodoesnotappeartosupport auth-int(asofthiswriting)[FFDA],andneitherdoesGoogleChrome[HAHD]. Anotherseriousweakness,commoninmodernbrowsers,isthatnoindicationispresentedtotheuserwhichHTTP authenticationmethod(basicordigest)isbeingused.AsisnotedinRFC2617,maninthemiddledowngradeattacks aretriviallypossible(withoutSSLorotherprotections)byconvincinguserstoauthenticateviabasicauthentication whilesendingthesecredentialstotheserverviadigestauthentication.EvenwiththiswarningpresentintheRFC, manybrowsers(Firefox3.5.6,Opera9.62,GoogleChrome3.0.195.38)simplypresentuserswithagenericprompt,not indicatingwhichmethodisinuse.(Duringlimitedtesting,InternetExplorer8,Opera10.10,andSafari4.0.4atleast

C O P Y R I G H T 2 0 1 0 V I RT U A L S E C U R I T Y R E S E A R C H , L L C A L L R I G H T S R E S E RV E D .

6 / 8

H T T P D I G E S T I N T E G R I T Y : A N O T H E R L O O K , I N L I G H T O F R E C E N T AT TA C K S

VERSION 1.0

J A N U A RY 5 , 2 0 1 0

addedawarningtothepromptwhenbasicauthenticationovernonSSLconnectionswereused.) OveradecadehaspassedsinceRFC2617wasreleased,yetthelackofcompleteand/orcorrectsupportinmain stream browsers and web servers remains a major hinderance for implementors and surely is not encouraging adoption.

Conclusion
HTTP digest authentication should be considered by web application administrators as a temporary mitigation againstSSL/TLSrenegotiationattacks.However,duetopotentialincompatibilities,itshouldbewelltestedpriorto deployment. Inthelongrun,HTTPdigestauthenticationisnotacompletesolutionforbolsteringwebsecurity,butasSSLtech nology showsits age and fragility, web administratorsshould consider layeredapproaches to securing sensitive communications.

Acknowledgements
ThankstoGeorgeGalforassistanceintesting;JoanMorganandJohnRedfordwhoprovidedhelpfulcommentsand suggestions.

C O P Y R I G H T 2 0 1 0 V I RT U A L S E C U R I T Y R E S E A R C H , L L C A L L R I G H T S R E S E RV E D .

7 / 8

H T T P D I G E S T I N T E G R I T Y : A N O T H E R L O O K , I N L I G H T O F R E C E N T AT TA C K S

VERSION 1.0

J A N U A RY 5 , 2 0 1 0

References
0Prfx AMAD DebKeys Null Prefix Attacks Against SSL/TLS Certificates http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf Apache Module mod_auth_digest http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html When Private Keys are Public: Results from the 2008 Debian OpenSSL Vulnerability https://cseweb.ucsd.edu/~hovav/papers/yrses09.html TLS/SSLv3 Renegotiation Vulnerability Explained http://www.g-sec.lu/practicaltls.pdf Mozilla Cross Reference: nsHttpDigestAuth.cpp http://mxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpDigestAuth.cpp http_auth_handler_digest.cc (Google Chrome) http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_auth_handler_ digest.cc?revision=26723&view=markup HTTP Request Smuggling http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf MD5 considered harmful today: Creating a rogue CA certificate http://www.win.tue.nl/hashclash/rogue-ca/ Defeating OCSP With the Character '3' http://www.thoughtcrime.org/papers/ocsp-attack.pdf Renegotiating TLS http://extendedsubset.com/Renegotiating_TLS.pdf An Extension to HTTP : Digest Access Authentication http://www.ietf.org/rfc/rfc2069.txt HTTP Authentication: Basic and Digest Access Authentication http://www.ietf.org/rfc/rfc2617.txt Rainbow Table http://en.wikipedia.org/wiki/Rainbow_table SSLSTRIP http://www.thoughtcrime.org/software/sslstrip/ Crying Wolf: An Empirical Study of SSL Warning Effectiveness http://lorrie.cranor.org/pubs/sslwarnings.pdf TLS Renegotiation Vulnerability (CVE-2009-3555) http://www.securegoose.org/2009/11/tls-renegotiation-vulnerability-cve.html Understanding the TLS Renegotiation Attack http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html Cross-site Tracing http://www.owasp.org/index.php/Cross_Site_Tracing

ExpTLS FFDA

HAHD

HRS MD5CA OCSP3 ReTLS RFC2069 RFC2617 RT SS SSLWarn TwTLS UReTLS

XST

C O P Y R I G H T 2 0 1 0 V I RT U A L S E C U R I T Y R E S E A R C H , L L C A L L R I G H T S R E S E RV E D .

8 / 8