原标题：Wi-Fi 爆重大安全漏洞，Android、iOS、Windows 等所有无线设备都不安全了

移动设备横行的时代，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 漏洞，如今各大企业回应：

苹果 iOS 和 Mac： 苹果证实安全漏洞将会在 iOS、macOS、watchOS、tvOS 的下一个软件更新的测试版本中得到解决，在未来几周内就会通过软件升级的形式提供给用户。

微软： 微软于 10 月 10 日发布安全补丁，使用 Windows Update 的客户可以使用补丁，自动防卫。我们及时更新，保护客户，作为一个负责任的合作伙伴，我们没有披露信息，直到厂商开发并发布补丁。

谷歌移动/谷歌Chromecast/ Home/ Wi-Fi： 我们已经知道问题的存在，未来几周会给任何受影响的设备打上补丁。

谷歌 Chromebook：暂时没有发表评论。

亚马逊 Echo、FireTV 和 Kindle：我们的设备是否存在这样的漏洞？公司正在评估，如果有必要就会发布补丁。

三星移动、三星电视、三星家电：暂时没有发表评论。

思科：暂时没有发表评论。

Linksys/Belkin：Linksys/Belkin 和 Wemo 已经知道 WAP 漏洞的存在。安全团队正在核查细节信息，会根据情况提供指导意义。我们一直将客户放在第一位，会在安全咨询页面发布指导意见，告诉客户如何升级产品，如果需要就能升级。

Netgear：Netgear 已经为多款产品发布修复程序，正在为其它产品开发补丁。你可以访问我们的安全咨询页面进行升级。为了保护用户，Netgear 公开发布修复程序之后才披露漏洞的存在，没有提到漏洞的具体信息。一旦有了修复程序，Netgear 会通过“Netgear 产品安全”页面披露漏洞。

Eero：我们已经知道 WAP2 安全协议存在 KRACK 漏洞。安全团队正在寻找解决方案，今天晚些时候就会公布更多信息。我们打造了云系统，针对此种情况可以发布远程更新程序，确保所有客户及时获得更新软件，自己不需要采取任何动作。

英特尔：英特尔正在与客户、设备制造商合作，通过固件和软件更新的方式应对漏洞。如果想获得更多信息，可以访问英特尔安全咨询页面。

Nest：我们已经知道漏洞的存在，未来几周将会为 Nest 产品推出补丁。

飞利浦 Hue：KRACK 攻击利用了 Wi-Fi 协议。我们建议客户使用安全 Wi-Fi 密码，在手机、计算机及其它 Wi-Fi 设备上安装最新补丁，防范此类攻击。飞利浦 Hue 本身并不直接支持 WiFi，因此不需要防范补丁。还有，我们的云帐户 API 可以用 HTTPS 进行保护，增强安全，这是一个额外的安全层，不会受到 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:highleveldeionInakeyreinstallationattack,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.TOOLSWehavemadestodetectwhetheranimplementationofthe4-wayhandshake,groupkeyhandshake,orFastBSSTransition(FT)handshakeisvulnerabletokeyreinstallationattacks.Theseswillbereleasedoncewehavehadthetimetocleanuptheirusageinstructions.Wealsomadeaproof-of-conceptthatexploitstheall-zerokey(re)installationpresentincertainAndroidandLinuxdevices.Thisistheonethatweusedinthedemonstrationvideo.Itwillbereleasedonceeveryonehashadareasonablechancetoupdatetheirdevices(andwehavehadachancetopreparethecoderepositoryforrelease).Weremarkthatthereliabilityofourproof-of-conceptmaydependonhowclosethevictimistotherealnetwork.Ifthevictimisveryclosetotherealnetwork,themayfailbecausethevictimwillalwaysdirectlycommunicatewiththerealnetwork,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

作者：苏宓

原文链接：http://blog.csdn.net/csdnnews/article/details/78259290?locationNum=2 fps=1

关于 KRACK 详细内容介绍和视频演示详见 krackattacks.com 官网：https://www.krackattacks.com。返回搜狐，查看更多