点击上方“程序员大咖”，选择“置顶公众号”
关键时刻，第一时间送达！
移动设备横行的时代，Wi-Fi 已成为现代人生活的必备要素之一。但近日有计算机安全专家发现，Wi-Fi 设备的安全协议存在漏洞，如今用于保护 Wi-Fi 网络安全的保护机制已经被黑客攻破，苹果、微软、谷歌、Nest 等无线设备纷纷不再安全，就现有的漏洞，黑客可以轻松入侵用户装置、监听接入网络的设备。
无论你在家还是在公众场合，只要连接 Wi-Fi ，极有可能会被入侵。
据了解，这个安全协议漏洞名为“KRACK”，即“Key Reinstallation Attack”（密钥重安装攻击），它曝露了 WPA2 的一个严重的安全漏洞，黑客可以利用 KRACK 进行入侵。
何为 WPA2？
首先了解 WPA，全称为 Wi-Fi Protected Access（保护无线电脑网络安全系统），有 WPA 和 WPA2 两个标准，是一种保护无线网络安全的加密协议。而 WPA2 是基于 WPA 的一种新的加密方式，支持 AES 加密，新型的网卡、AP 都支持 WPA2 加密，但现在已经被黑客破解。攻击者如今可读取通过 WAP2 保护的任何无线网络（诸如路由器）的所有信息。
最初，比利时鲁汶大学计算机安全学者马蒂·凡赫尔夫（Mathy Vanhoef）发现了该漏洞，他表示：
我们发现了 WPA2 的严重漏洞，这是一种如今使用最广泛的 Wi-Fi 网络保护协议。黑客可以使用这种新颖的攻击技术来读取以前假定为安全加密的信息，如信用卡号、密码、聊天信息、电子邮件、照片等等。
这类安全缺陷存在于 Wi-Fi 标准的本身，而非特定的某些产品或方案中。因此，即使是得到正确部署的 WPA2 同样有可能受到影响。即只要是设备支持 Wi-Fi，则都可能会收到影响。在初步研究中发现，Android 和 Linux 显得尤为脆弱，同时封闭的苹果操作系统 iOS 和 macOS 也难逃厄运，此外 Windows、OpenBSD、联发科技、Linksys 等无线产品都会受到一定程度的影响。
攻击原理
攻击的原理是利用设备加入 Wi-Fi 网络时所用的通信。一共有四个步骤，第一步确认设备正在使用正确的路由器 Wi-Fi 密码，然后同意一个用于连接期间发送所有数据的加密密钥。 而黑客可以利用重新安装攻击漏洞，诱导用户重新安装已经使用过的密钥。具体实现方法是操纵并重播密码握手消息。当受害者重新安装密钥时，增量发送分组号（即随机数）以及接收分组号（即重播计数器）等相关参数将被重置为初始值。
从本质上来讲，为了保证安全性，每条密钥只能安装并使用一次。遗憾的是，我们发现 WPA2 协议当中并不包含这一强制要求。Vanhoef 表示漏洞存在于 WPA2 协议的四路握手（four-way handshake）机制中，四路握手允许拥有预共享密码的新设备加入网络。而通过操纵加密握手过程，我们将能够在实践当中利用这一致命缺陷。
在最糟糕的情况下，攻击者可以利用漏洞从 WPA2 设备破译网络流量、劫持链接、将内容注入流量中。换言之，攻击者通过漏洞可以获得一个万能密钥，不需要密码就可以访问任何 WAP2 网络。一旦拿到密钥，他们就可以窃听你的网络信息。
漏洞的存在意味着 WAP2 协议完全崩溃，影响个人设备和企业设备，几乎每一台无线设备都受到威胁。
对于漏洞的回应
事实上，周一时，美国国土安全局网络应急部门 US-CERT 确认了漏洞的存在，而早在 2 个月前，US-CERT 已经秘密通知相关的厂商和专家，告诉它们存在这样的漏洞。
针对 KRACK 漏洞，如今各大企业回应：
如何降低被攻击的风险
如文章开头所述，任何使用 Wi-Fi 的设备都有可能面临这一安全风险。
现在变更 Wi-Fi 网络的密码并不能避免（或者缓解）此类攻击。因此，用户不需要对 WiFi 网络的密码进行更新。相反，大家应当确保全部设备皆进行更新，并应更新自己的路由器固件。在路由器更新完毕后，还应选择性地变更 WiFi 密码以作为额外预防手段。
在不安全的网络时代，也许可从一些事实中寻求些许的安慰。本次攻击手段面向四次握手，且不会利用接入点——而是主要指向客户端。黑客只能解密通过 Wi-Fi 连接本身加密的数据，如果你正在访问安全网站，该数据仍会通过 HTTPS 协议进行加密，在此也建议浏览网页时，尽量选择 HTTPS 站点。但是，不排除攻击者可能会针对 HTTPS 进行单独攻击。
最后，在漏洞尚未修复之前，对于普通手机用户来说，使用支付宝、微信支付、网银的时候，建议大家还是尽量使用蜂窝移动网络，外出远行，提前办好流量套餐，有效避免黑客攻击。
INTRODUCTIONWediscoveredseriousweaknessesinWPA2,aprotocolthatsecuresallmodernprotectedWi-Finetworks.Anattackerwithinrangeofavictimcanexploittheseweaknessesusingkeyreinstallationattacks(KRACKs).Concretely,attackerscanusethisnovelattacktechniquetoreadinformationthatwaspreviouslyassumedtobesafelyencrypted. Thiscanbeabusedtostealsensitiveinformationsuchascreditcardnumbers,passwords,chatmessages,emails,photos,andsoon.TheattackworksagainstallmodernprotectedWi-Finetworks.Dependingonthenetworkconfiguration,itisalsopossibletoinjectandmanipulatedata.Forexample,anattackermightbeabletoinjectransomwareorothermalwareintowebsites.TheweaknessesareintheWi-Fistandarditself,andnotinindividualproductsorimplementations.Therefore,anycorrectimplementationofWPA2islikelyaffected.Topreventtheattack,usersmustupdateaffectedproductsassoonassecurityupdatesbecomeavailable.NotethatifyourdevicesupportsWi-Fi,itismostlikelyaffected.Duringourinitialresearch,wediscoveredourselvesthatAndroid,Linux,Apple,Windows,OpenBSD,MediaTek,Linksys,andothers,areallaffectedbysomevariantoftheattacks.Formoreinformationaboutspecificproducts,consultthedatabaseofCERT/CC,orcontactyourvendor.TheresearchbehindtheattackwillbepresentedattheComputerandCommunicationsSecurity(CCS)conference,andattheBlackHatEuropeconference.Ourdetailedresearchpapercanalreadybedownloaded.DEMONSTRATIONAsaproof-of-conceptweexecutedakeyreinstallationattackagainstanAndroidsmartphone.Inthisdemonstration,theattackerisabletodecryptalldatathatthevictimtransmits.Foranattackerthisiseasytoaccomplish,becauseourkeyreinstallationattackisexceptionallydevastatingagainstLinuxandAndroid6.0orhigher.ThisisbecauseAndroidandLinuxcanbetrickedinto(re)installinganall-zeroencryptionkey(seebelowformoreinfo).Whenattackingotherdevices,itishardertodecryptallpackets,althoughalargenumberofpacketscanneverthelessbedecrypted.Inanycase,thefollowingdemonstrationhighlightsthetypeofinformationthatanattackercanobtainwhenperformingkeyreinstallationattacksagainstprotectedWi-Finetworks:Ourattackisnotlimitedtorecoveringlogincredentials(i.e.e-mailaddressesandpasswords).Ingeneral,anydataorinformationthatthevictimtransmitscanbedecrypted.Additionally,dependingonthedevicebeingusedandthenetworksetup,itisalsopossibletodecryptdatasenttowardsthevictim(e.g.thecontentofawebsite).AlthoughwebsitesorappsmayuseHTTPSasanadditionallayerofprotection,wewarnthatthisextraprotectioncan(still)bebypassedinaworryingnumberofsituations.Forexample,HTTPSwaspreviouslybypassedinnon-browsersoftware,inApple'siOSandOSX,inAndroidapps,inAndroidappsagain,inbankingapps,andeveninVPNapps.DETAILSOurmainattackisagainstthe4-wayhandshakeoftheWPA2protocol.ThishandshakeisexecutedwhenaclientwantstojoinaprotectedWi-Finetwork,andisusedtoconfirmthatboththeclientandaccesspointpossessthecorrectcredentials(e.g.thepre-sharedpasswordofthenetwork).Atthesametime,the4-wayhandshakealsonegotiatesafreshencryptionkeythatwillbeusedtoencryptallsubsequenttraffic.Currently,allmodernprotectedWi-Finetworksusethe4-wayhandshake.Thisimpliesallthesenetworksareaffectedby(somevariantof)ourattack.Forinstance,theattackworksagainstpersonalandenterpriseWi-Finetworks,againsttheolderWPAandthelatestWPA2standard,andevenagainstnetworksthatonlyuseAES.AllourattacksagainstWPA2useanoveltechniquecalledakeyreinstallationattack(KRACK):Keyreinstallationattacks:highleveldescriptionInakeyreinstallationattack,theadversarytricksavictimintoreinstallinganalready-in-usekey.Thisisachievedbymanipulatingandreplayingcryptographichandshakemessages.Whenthevictimreinstallsthekey,associatedparameterssuchastheincrementaltransmitpacketnumber(i.e.nonce)andreceivepacketnumber(i.e.replaycounter)areresettotheirinitialvalue.Essentially,toguaranteesecurity,akeyshouldonlybeinstalledandusedonce.Unfortunately,wefoundthisisnotguaranteedbytheWPA2protocol.Bymanipulatingcryptographichandshakes,wecanabusethisweaknessinpractice.Keyreinstallationattacks:concreteexampleagainstthe4-wayhandshakeAsdescribedintheintroductionoftheresearchpaper,theideabehindakeyreinstallationattackcanbesummarizedasfollows.Whenaclientjoinsanetwork,itexecutesthe4-wayhandshaketonegotiateafreshencryptionkey.Itwillinstallthiskeyafterreceivingmessage3ofthe4-wayhandshake.Oncethekeyisinstalled,itwillbeusedtoencryptnormaldataframesusinganencryptionprotocol.However,becausemessagesmaybelostordropped,theAccessPoint(AP)willretransmitmessage3ifitdidnotreceiveanappropriateresponseasacknowledgment.Asaresult,theclientmayreceivemessage3multipletimes.Eachtimeitreceivesthismessage,itwillreinstallthesameencryptionkey,andtherebyresettheincrementaltransmitpacketnumber(nonce)andreceivereplaycounterusedbytheencryptionprotocol.Weshowthatanattackercanforcethesenonceresetsbycollectingandreplayingretransmissionsofmessage3ofthe4-wayhandshake.Byforcingnoncereuseinthismanner,theencryptionprotocolcanbeattacked,e.g.,packetscanbereplayed,decrypted,and/orforged.Thesametechniquecanalsobeusedtoattackthegroupkey,PeerKey,TDLS,andfastBSStransitionhandshake.PracticalimpactInouropinion,themostwidespreadandpracticallyimpactfulattackisthekeyreinstallationattackagainstthe4-wayhandshake.Webasethisjudgementontwoobservations.First,duringourownresearchwefoundthatmostclientswereaffectedbyit.Second,adversariescanusethisattacktodecryptpacketssentbyclients,allowingthemtointerceptsensitiveinformationsuchaspasswordsorcookies.Decryptionofpacketsispossiblebecauseakeyreinstallationattackcausesthetransmitnonces(sometimesalsocalledpacketnumbersorinitializationvectors)toberesettozero.Asaresult,thesameencryptionkeyisusedwithnoncevaluesthathavealreadybeenusedinthepast.Inturn,thiscausesallencryptionprotocolsofWPA2toreusekeystreamwhenencryptingpackets.Incaseamessagethatreuseskeystreamhasknowncontent,itbecomestrivialtoderivetheusedkeystream.Thiskeystreamcanthenbeusedtodecryptmessageswiththesamenonce.Whenthereisnoknowncontent,itishardertodecryptpackets,althoughstillpossibleinseveralcases(e.g.Englishtextcanstillbedecrypted).Inpractice,findingpacketswithknowncontentisnotaproblem,soitshouldbeassumedthatanypacketcanbedecrypted.TheabilitytodecryptpacketscanbeusedtodecryptTCPSYNpackets.ThisallowsanadversarytoobtaintheTCPsequencenumbersofaconnection,andhijackTCPconnections.Asaresult,eventhoughWPA2isused,theadversarycannowperformoneofthemostcommonattacksagainstopenWi-Finetworks:injectingmaliciousdataintounencryptedHTTPconnections.Forexample,anattackercanabusethistoinjectransomwareormalwareintowebsitesthatthevictimisvisiting.IfthevictimuseseithertheWPA-TKIPorGCMPencryptionprotocol,insteadofAES-CCMP,theimpactisespeciallycatastrophic.Againsttheseencryptionprotocols,noncereuseenablesanadversarytonotonlydecrypt,butalsotoforgeandinjectpackets.Moreover,becauseGCMPusesthesameauthenticationkeyinbothcommunicationdirections,andthiskeycanberecoveredifnoncesarereused,itisespeciallyaffected.NotethatsupportforGCMPiscurrentlybeingrolledoutunderthenameWirelessGigabit(WiGig),andisexpectedtobeadoptedatahighrateoverthenextfewyears.Thedirectioninwhichpacketscanbedecrypted(andpossiblyforged)dependsonthehandshakebeingattacked.Simplified,whenattackingthe4-wayhandshake,wecandecrypt(andforge)packetssentbytheclient.WhenattackingtheFastBSSTransition(FT)handshake,wecandecrypt(andforge)packetssenttowardstheclient.Finally,mostofourattacksalsoallowthereplayofunicast,broadcast,andmulticastframes.Forfurtherdetails,seeSection6ofourresearchpaper.NotethatourattacksdonotrecoverthepasswordoftheWi-Finetwork.Theyalsodonotrecover(anypartsof)thefreshencryptionkeythatisnegotiatedduringthe4-wayhandshake.AndroidandLinuxOurattackisespeciallycatastrophicagainstversion2.4andaboveofwpa_supplicant,aWi-FiclientcommonlyusedonLinux.Here,theclientwillinstallanall-zeroencryptionkeyinsteadofreinstallingtherealkey.ThisvulnerabilityappearstobecausedbyaremarkintheWi-Fistandardthatsuggeststocleartheencryptionkeyfrommemoryonceithasbeeninstalledforthefirsttime.Whentheclientnowreceivesaretransmittedmessage3ofthe4-wayhandshake,itwillreinstallthenow-clearedencryptionkey,effectivelyinstallinganall-zerokey.BecauseAndroiduseswpa_supplicant,Android6.0andabovealsocontainsthisvulnerability.ThismakesittrivialtointerceptandmanipulatetrafficsentbytheseLinuxandAndroiddevices.Notethatcurrently50%ofAndroiddevicesarevulnerabletothisexceptionallydevastatingvariantofourattack.AssignedCVEidentifiersThefollowingCommonVulnerabilitiesandExposures(CVE)identifierswereassignedtotrackwhichproductsareaffectedbyspecificinstantiationsofourkeyreinstallationattack:CVE-2017-13077:Reinstallationofthepairwiseencryptionkey(PTK-TK)inthe4-wayhandshake.CVE-2017-13078:Reinstallationofthegroupkey(GTK)inthe4-wayhandshake.CVE-2017-13079:Reinstallationoftheintegritygroupkey(IGTK)inthe4-wayhandshake.CVE-2017-13080:Reinstallationofthegroupkey(GTK)inthegroupkeyhandshake.CVE-2017-13081:Reinstallationoftheintegritygroupkey(IGTK)inthegroupkeyhandshake.CVE-2017-13082:AcceptingaretransmittedFastBSSTransition(FT)ReassociationRequestandreinstallingthepairwiseencryptionkey(PTK-TK)whileprocessingit.CVE-2017-13084:ReinstallationoftheSTKkeyinthePeerKeyhandshake.CVE-2017-13086:reinstallationoftheTunneledDirect-LinkSetup(TDLS)PeerKey(TPK)keyintheTDLShandshake.CVE-2017-13087:reinstallationofthegroupkey(GTK)whenprocessingaWirelessNetworkManagement(WNM)SleepModeResponseframe.CVE-2017-13088:reinstallationoftheintegritygroupkey(IGTK)whenprocessingaWirelessNetworkManagement(WNM)SleepModeResponseframe.NotethateachCVEidentifierrepresentsaspecificinstantiationofakeyreinstallationattack.ThismeanseachCVEIDdescribesaspecificprotocolvulnerability,andthereforemanyvendorsareaffectedbyeachindividualCVEID.YoucanalsoreadvulnerabilitynoteVU#228519ofCERT/CCforadditionaldetailsonwhichproductsareknowntobeaffected.PAPEROurresearchpaperbehindtheattackistitledKeyReinstallationAttacks:ForcingNonceReuseinWPA2andwillbepresentedattheComputerandCommunicationsSecurity(CCS)conferenceonWednesday1November2017.Althoughthispaperismadepublicnow,itwasalreadysubmittedforreviewon19May2017.Afterthis,onlyminorchangesweremade.Asaresult,thefindingsinthepaperarealreadyseveralmonthsold.Inthemeantime,wehavefoundeasiertechniquestocarryoutourkeyreinstallationattackagainstthe4-wayhandshake.Withournovelattacktechnique,itisnowtrivialtoexploitimplementationsthatonlyacceptencryptedretransmissionsofmessage3ofthe4-wayhandshake.InparticularthismeansthatattackingmacOSandOpenBSDissignificantlyeasierthandiscussedinthepaper.Wewouldliketohighlightthefollowingaddendumsanderrata:Addendum:wpa_supplicantv2.6andAndroid6.0+Linux'swpa_supplicantv2.6isalsovulnerabletotheinstallationofanall-zeroencryptionkeyinthe4-wayhandshake.ThiswasdiscoveredbyJohnA.VanBoxtel.Asaresult,allAndroidversionshigherthan6.0arealsoaffectedbytheattack,andhencecanbetrickedintoinstallinganall-zeroencryptionkey.Thenewattackworksbyinjectingaforgedmessage1,withthesameANonceasusedintheoriginalmessage1,beforeforwardingtheretransmittedmessage3tothevictim.Addendum:othervulnerablehandshakesAfterourinitialresearchasreportedinthepaper,wediscoveredthattheTDLShandshakeandWNMSleepModeResponseframearealsovulnerabletokeyreinstallationattacks.SelectederrataInFigure9atstage3oftheattack,theframetransmittedfromtheadversarytotheauthenticatorshouldsayaReassoReqinsteadofReassoResp.TOOLSWehavemadescriptstodetectwhetheranimplementationofthe4-wayhandshake,groupkeyhandshake,orFastBSSTransition(FT)handshakeisvulnerabletokeyreinstallationattacks.Thesescriptswillbereleasedoncewehavehadthetimetocleanuptheirusageinstructions.Wealsomadeaproof-of-conceptscriptthatexploitstheall-zerokey(re)installationpresentincertainAndroidandLinuxdevices.Thisscriptistheonethatweusedinthedemonstrationvideo.Itwillbereleasedonceeveryonehashadareasonablechancetoupdatetheirdevices(andwehavehadachancetopreparethecoderepositoryforrelease).Weremarkthatthereliabilityofourproof-of-conceptscriptmaydependonhowclosethevictimistotherealnetwork.Ifthevictimisveryclosetotherealnetwork,thescriptmayfailbecausethevictimwillalwaysdirectlycommunicatewiththerealnetwork,evenifthevictimis(forced)ontoadifferentWi-Fichannelthanthisnetwork.Q&ADowenowneedWPA3?No,luckilyimplementationscanbepatchedinabackwards-compatiblemanner.Thismeansapatchedclientcanstillcommunicatewithanunpatchedaccesspoint(AP),andviceversa.Inotherwords,apatchedclientoraccesspointsendsexactlythesamehandshakemessagesasbefore,andatexactlythesamemomentintime.However,thesecurityupdateswillassureakeyisonlyinstalledonce,preventingourattack.Soagain,updateallyourdevicesoncesecurityupdatesareavailable.Finally,althoughanunpatchedclientcanstillconnecttoapatchedAP,andviceversa,boththeclientandAPmustbepatchedtodefendagainstallattacks!ShouldIchangemyWi-Fipassword?ChangingthepasswordofyourWi-Finetworkdoesnotprevent(ormitigate)theattack.SoyoudonothavetoupdatethepasswordofyourWi-Finetwork.Instead,youshouldmakesureallyourdevicesareupdated,andyoushouldalsoupdatethefirmwareofyourrouter.Nevertheless,afterupdatingbothyourclientdevicesandyourrouter,it'sneverabadideatochangetheWi-Fipassword.I'musingWPA2withonlyAES.That'salsovulnerable?Yes,thatnetworkconfigurationisalsovulnerable.TheattackworksagainstbothWPA1andWPA2,againstpersonalandenterprisenetworks,andagainstanyciphersuitebeingused(WPA-TKIP,AES-CCMP,andGCMP).Soeveryoneshouldupdatetheirdevicestopreventtheattack!Youusetheword"we"inthiswebsite.Whoiswe?Iusetheword"we"becausethat'swhatI'musedtowritinginpapers.Inpractice,alltheworkisdonebyme,withmebeingMathyVanhoef.Myawesomesupervisorisaddedunderanhonoraryauthorshiptotheresearchpaperforhisexcellentgeneralguidance.Butalltherealworkwasdoneonmyown.Sotheauthorlistofacademicpapersdoesnotrepresentdivisionofwork:)Ismydevicevulnerable?Probably.AnydevicethatusesWi-Fiislikelyvulnerable.Contactyourvendorformoreinformation.Whatiftherearenosecurityupdatesformyrouter?Ourmainattackisagainstthe4-wayhandshake,anddoesnotexploitaccesspoints,butinsteadtargetsclients.Soitmightbethatyourrouterdoesnotrequiresecurityupdates.Westronglyadviseyoutocontactyourvendorformoredetails.Ingeneralthough,youcantrytomitigateattacksagainstroutersandaccesspointsbydisablingclientfunctionality(whichisforexampleusedinrepeatermodes)anddisabling802.11r(fastroaming).Forordinaryhomeusers,yourpriorityshouldbeupdatingclientssuchaslaptopsandsmartphones.Howdidyoudiscoverthesevulnerabilities?Whenworkingonthefinal(i.e.camera-ready)versionofanotherpaper,Iwasdouble-checkingsomeclaimswemaderegardingOpenBSD'simplementationofthe4-wayhandshake.InasenseIwasslackingoff,becauseIwassupposedtobejustfinishingthepaper,insteadofstaringatcode.ButthereIwas,inspectingsomecodeIalreadyreadahundredtimes,toavoidhavingtoworkonthenextparagraph.Itwasatthattimethataparticularcalltoic_set_keycaughtmyattention.Thisfunctioniscalledwhenprocessingmessage3ofthe4-wayhandshake,anditinstallsthepairwisekeytothedriver.WhilestaringatthatlineofcodeIthought“Ha.Iwonderwhathappensifthatfunctioniscalledtwice”.AtthetimeI(correctly)guessedthatcallingittwicemightresetthenoncesassociatedtothekey.Andsincemessage3canberetransmittedbytheAccessPoint,inpracticeitmightindeedbecalledtwice.“Bettermakeanoteofthat.Othervendorsmightalsocallsuchafunctiontwice.Butlet'sfirstfinishthispaper...”.Afewweekslater,afterfinishingthepaperandcompletingsomeotherwork,Iinvestigatedthisnewideainmoredetail.Andtherestishistory.The4-wayhandshakewasmathematicallyprovenassecure.Howisyourattackpossible?Thebriefansweristhattheformalproofdoesnotassureakeyisinstalledonce.Instead,itonlyassuresthenegotiatedkeyremainssecret,andthathandshakemessagescannotbeforged.Thelongeranswerismentionedintheintroductionofourresearchpaper:ourattacksdonotviolatethesecuritypropertiesproveninformalanalysisofthe4-wayhandshake.Inparticular,theseproofsstatethatthenegotiatedencryptionkeyremainsprivate,andthattheidentityofboththeclientandAccessPoint(AP)isconfirmed.Ourattacksdonotleaktheencryptionkey.Additionally,althoughnormaldataframescanbeforgedifTKIPorGCMPisused,anattackercannotforgehandshakemessagesandhencecannotimpersonatetheclientorAPduringhandshakes.Therefore,thepropertiesthatwereproveninformalanalysisofthe4-wayhandshakeremaintrue.However,theproblemisthattheproofsdonotmodelkeyinstallation.Putdifferently,theformalmodelsdidnotdefinewhenanegotiatedkeyshouldbeinstalled.Inpractice,thismeansthesamekeycanbeinstalledmultipletimes,therebyresettingnoncesandreplaycountersusedbytheencryptionprotocol(e.g.byWPA-TKIPorAES-CCMP).SomeattacksinthepaperseemhardWehavefollow-upworkmakingourattacks(againstmacOSandOpenBSDforexample)significantlymoregeneralandeasiertoexecute.Soalthoughweagreethatsomeoftheattackscenariosinthepaperareratherimpractical,donotletthisfoolyouintobelievingkeyreinstallationattackscannotbeabusedinpractice.Ifanattackercandoaman-in-the-middleattack,whycan'thejustdecryptallthedata?Asmentionedinthedemonstration,theattackerfirstobtainsaman-in-the-middle(MitM)positionbetweenthevictimandtherealWi-Finetwork(calledachannel-basedMitMposition).However,thisMitMpositiondoesnotenabletheattackertodecryptpackets!Thispositiononlyallowstheattackertoreliablydelay,block,orreplayencryptedpackets.Soatthispointintheattack,heorshecannotyetdecryptpackets.Instead,theabilitytoreliablydelayandblockpacketsisusedtoexecuteakeyreinstallationattack.Afterperformingakeyreinstallationattack,packetscanbedecrypted.Arepeopleexploitingthisinthewild?Wearenotinapositiontodetermineifthisvulnerabilityhasbeen(orisbeing)activelyexploitedinthewild.Thatsaid,keyreinstallationscanactuallyoccurspontaneouslywithoutanadversarybeingpresent!Thismayforexamplehappenifthelastmessageofahandshakeislostduetobackgroundnoise,causingaretransmissionofthepreviousmessage.Whenprocessingthisretransmittedmessage,keysmaybereinstalled,resultinginnoncereusejustlikeinarealattack.ShouldItemporarilyuseWEPuntilmydevicesarepatched?NO!KeepusingWPA2.WilltheWi-Fistandardbeupdatedtoaddressthis?ThereseemstobeanagreementthattheWi-Fistandardshouldbeupdatedtoexplicitlypreventourattacks.Theseupdateslikelywillbebackwards-compatiblewitholderimplementationsofWPA2.Timewilltellwhetherandhowthestandardwillbeupdated.IstheWi-FiAlliancealsoaddressingthesevulnerabilities?ForthoseunfamiliarwithWi-Fi,theWi-FiAllianceisanorganizationwhichcertifiesthatWi-Fidevicesconformtocertainstandardsofinteroperability.Amongotherthings,thisassuresthatWi-Fiproductsfromdifferentvendorsworkwelltogether.TheWi-FiAlliancehasaplantohelpremedythediscoveredvulnerabilitiesinWPA2.Summarized,theywill:Requiretestingforthisvulnerabilitywithintheirglobalcertificationlabnetwork.ProvideavulnerabilitydetectiontoolforusebyanyWi-FiAlliancemember(thistoolisbasedonmyowndetectiontoolthatdeterminesifadeviceisvulnerabletosomeofthediscoveredkeyreinstallationattacks).Broadlycommunicatedetailsonthisvulnerability,includingremedies,todevicevendors.Additionally,vendorsareencouragedtoworkwiththeirsolutionproviderstorapidlyintegrateanynecessarypatches.Communicatetheimportanceforuserstoensuretheyhaveinstalledthelatestrecommendedsecurityupdatesfromdevicemanufacturers.Whydidyouusematch.comasanexampleinthedemonstrationvideo?Userssharealotofpersonalinformationonwebsitessuchasmatch.com.Sothisexamplehighlightsallthesensitiveinformationanattackercanobtain,andhopefullywiththisexamplepeoplealsobetterrealizethepotential(personal)impact.Wealsohopethisexamplemakespeopleawareofalltheinformationthesedatingwebsitesmaybecollecting.Howcanthesetypesofbugsbeprevented?Weneedmorerigorousinspectionsofprotocolimplementations.Thisrequireshelpandadditionalresearchfromtheacademiccommunity!Togetherwithotherresearchers,wehopetoorganizeworkshop(s)toimproveandverifythecorrectnessofsecurityprotocolimplementations.Whythedomainnamekrackattacks.com?First,I'mawarethatKRACKattacksisapleonasm,sinceKRACKstandsforkeyreinstallationattackandhencealreadycontainsthewordattack.Butthedomainnamerhymes,sothat'swhyit'sused.Didyougetbugbountiesforthis?Ihaven'tappliedforanybugbountiesyet,norhaveIreceivedonealready.HowdoesthisattackcomparetootherattacksagainstWPA2?ThisisthefirstattackagainsttheWPA2protocolthatdoesn'trelyonpasswordguessing.Indeed,otherattacksagainstWPA2-enablednetworkareagainstsurroundingtechnologiessuchasWi-FiProtectedSetup(WPS),orareattacksagainstolderstandardssuchasWPA-TKIP.Putdifferently,noneoftheexistingattackswereagainstthe4-wayhandshakeoragainstciphersuitesdefinedintheWPA2protocol.Incontrast,ourkeyreinstallationattackagainstthe4-wayhandshake(andagainstotherhandshakes)highlightsvulnerabilitiesintheWPA2protocolitself.Areotherprotocolsalsoaffectedbykeyreinstallationattacks?Weexpectthatcertainimplementationsofotherprotocolsmaybevulnerabletosimilarattacks.Soit'sagoodideatoauditsecurityprotocolimplementationswiththisattackinmind.However,weconsideritunlikelythatotherprotocolstandardsareaffectedbysimilarattacks(oratleastsowehope).Nevertheless,it'sstillagoodideatoauditotherprotocols!Isthereahigherresolutionversionofthelogo?Yesthereis.Andabigthankyougoestothepersonthatmadethelogo!Whendidyoufirstnotifyvendorsaboutthevulnerability?Wesentoutnotificationstovendorswhoseproductswetestedourselvesaround14July2017.Aftercommunicatingwiththesevendors,werealizedhowwidespreadtheweaknesseswediscoveredare(onlythendidItrulyconvincemyselfitwasindeedaprotocolweaknessesandnotasetofimplementationbugs).Atthatpoint,wedecidedtoletCERT/CChelpwiththedisclosureofthevulnerabilities.Inturn,CERT/CCsentoutabroadnotificationtovendorson28August2017.WhydidOpenBSDsilentlyreleaseapatchbeforetheembargo?OpenBSDwasnotifiedofthevulnerabilityon15July2017,beforeCERT/CCwasinvolvedinthecoordination.Quitequickly,TheodeRaadtrepliedandcritiquedthetentativedisclosuredeadline:“Intheopensourceworld,ifapersonwritesadiffandhastositonitforamonth,thatisverydiscouraging”.NotethatIwroteandincludedasuggesteddiffforOpenBSDalready,andthatatthetimethetentativedisclosuredeadlinewasaroundtheendofAugust.Asacompromise,Iallowedthemtosilentlypatchthevulnerability.Inhindsightthiswasabaddecision,sinceothersmightrediscoverthevulnerabilitybyinspectingtheirsilentpatch.Toavoidthisprobleminthefuture,OpenBSDwillnowreceivevulnerabilitynotificationsclosertotheendofanembargo.SoyouexpecttofindotherWi-Fivulnerabilities?“Ithinkwe'rejustgettingstarted.”—MasterChief,Halo1
【点击成为安卓大神】
