» »

Napad na AES v virtualiziranih okoljih

Napad na AES v virtualiziranih okoljih

Slo-Tech - Raziskovalci Gorka Irazoqui Apecechea, Mehmet Sinan Inci, Thomas Eisenbarth in Berk Sunar iz Worcester Polytechnic Institute so objavili članek z naslovom Fine grain Cross-VM Attacks on Xen and VMware are possible! v katerem so pokazali, da je v virtualiziranem okolju s pomočjo Bernsteinovega korelacijskega napada mogoč uspešen napad na AES šifriranje. Napad je mogoče izvesti v okoljih Xen in VMWare in sicer iz enega virtualnega stroja na drugega.

Naj omenimo, da napad deluje samo v primeru, da se za šifriranje ne uporablja AES-NI strojno šifriranje, na omenjeni napad pa so ranljive številne kriptografske knjižnice, vključno z OpenSSL, PolarSSL in Libgcrypt. Napad deluje tudi v primeru, da se virtualni stroji nahajajo na različnih jedrih procesorja (a na istem fizičnem strežniku).

Korelacijski napadi v kriptografiji so podvrsta kriptoanalitičnih napadov, ki temeljijo na tim. znanem čistopisu (ang. known plaintext), izkoriščajo pa statistično ranljivost oziroma statistično značilno korelacijo med izhodnim stanjem posameznega pomikalnega registra z linearno povratno vezavo (ang. linear feedback shift register - LFSR) v generatorju kodnega toka podatkov (ang. keystream) in izhodom Boolove funkcije (ang. Boolean function), ki kombinira izhodno stanje vseh LFSR-jev. Do težav prihaja zaradi neustrezne izbire Boolove funkcije, oziroma se je napadu mogoče izogniti z izbiro ustrezne funkcije.

Bernstein je napad v osnovi sicer predstavil v nevirtualiziranih okoljih, izvaja pa se v štirih korakih (profiliranje, napad, korelacija in napad z grobo silo).

Za šifriranje v oblaku (tudi HTTPS) so to vsekakor slabe novice. Za kakršnokoli resnejšo uporabo šifriranja pa se tako ali tako priporoča uporabo ustreznih strojnih modulov (tim. HSM naprave).

19 komentarjev

nebivedu ::

Kaj pa hyperV? Je tam to tudi mogoče, ali samo Xen in VMWare?

tony1 ::

HSM naprave, ki pa so seveda zaprtokodne? :P

LightBit ::

"bitslice" AES implementacija je tudi varna.

LFSR in AES nimata nobene povezave.
Pri tem na napadu gre za to, da t[255] ne traja enako časa kot t[0].

Zgodovina sprememb…

  • spremenil: LightBit ()

l0g1t3ch ::

Lahko kdo bolj po domače pove kako ta napad deluje ?

Če prav razumem napadalec iz svojega VM-ja lahko "ugane" vsebino pomnilnika nekega drugega VM-ja, ki teče na istem hostu. In to je možno preko podrobne analize časa izvajanja posameznih ukazov ?

LightBit ::

Nekako tako, ja.
Ne katero koli vsebino pomnilnika, ampak razširjen ključ.

Zelo poenostavljeno kako deluje Bernsteinov napad:
Tipična AES implementacija uporablja 4 32-bitne tabele z 256 elementi (4KB), kar je sicer manj kot imajo procesorji L1 predpomnilnika (32KB), ampak običajno ima program še več drugih stvari, kar povzroči, da gre del tabele/tabel na L2 in ko AES reče daj mi X element (to naredi 160-krat na enkripcijo) v tabeli bo trajalo dalj časa, če je ta element na L2. To pri napadu pomaga ugotoviti kaj približno je X. Potem X-u odstranimo čistopis, ki ga poznamo in ostane nam ključ.

To je star (2005) napad in predvideva, da napadamo na istem računalniku kot je AES.
Novost pa je, da to deluje tudi v med VM-ji.

@nebivedu: Po moje je vseeno kater VM je (sploh, če/ker vsi uporabljajo isto strojno funkcijo).

nebivedu ::

Si prepričan? Strojno funkcijo že uporabljata, vendar je potem kar nekaj razlik.

LightBit ::

Xen in VMWare sta tudi različna.
Napad zahteva samo to, da sta računalnika identična (zelo podobna?).
Če imaš 2 virtualni mašini z enako konfiguracijo (enak hardware, enak OS, program), naj bi bili časi enaki.

Treba je tudi omeniti, da napadalec mora vedeti zelo zelo natančen čas trajanja enkripcije. Bernstein zraven pošilja te čase. Večina programov pa ne pove koliko časa je trajala enkripcija.

nebivedu ::

Škoda da za xen nimam teh podatkov, ampak samo za primer recimo kakšne so razlike md hyperV in wmware:
Cryptographic bandwidth (v Mb/s)
HyperV 2008 - 79
HyperV 2012 - 597
VMware 5.0 - 370
VMware 5.1 - 378

nebivedu ::

Sicer malo offtopic ampak "bottom line" za VMware vs HyperV (vsaj meni se zdi tale zaključek en izmed boljših):

Finally, one of the most difficult factors to compare is cost. If you're looking at a small number of virtualized servers running Windows Server 2012, you already get that with the purchase of the operating system. Windows Server 2012 Standard comes with two virtual instances, while Windows Server 2012 Datacenter includes an unlimited number of VMs on a single machine. If you're already investing in Windows Server 2012, it may not make sense to purchase an additional virtualization product for a small-to-medium deployment.

That said, if you are starting small and planning to scale out your virtualization farm significantly over time, VMware could present a smoother growth path. The vCenter Server is easily deployed as a virtual appliance, and it serves as a single, central provider of every vSphere management capability -- host provisioning and configuration management, VM templating and cloning, health and performance monitoring, automated load balancing of VMs and storage, etc.

By contrast, the management capabilities of System Center 2012 span multiple tools and repositories. These start with Virtual Machine Manager (VMM) -- for managing Hyper-V hosts, clusters, and virtual machines -- and extend to Operations Manager (which integrates with VMM to automate load balancing and provide health and performance monitoring), Configuration Manager, Data Protection Manager, Orchestrator, and App Controller.

On one hand, the abundance of System Center components increases the management overhead and complexity, in comparison to vCenter Server. On the other hand, if the goal is to virtualize a primarily Windows-based infrastructure (and it usually is), then all of those System Center tools may be needed to manage your Windows servers and Microsoft applications anyway.

And this raises an important point made by IDC's Al Gillen, the industry research firm's analyst on operating systems, cloud, and virtualization: The VMware and Microsoft stacks are not mutually exclusive.

"Let's say you're a big VMware shop," Gillen says. "The reality is you probably still need System Center to manage your Windows servers. So it's not really an apples to apples comparison." At the same time, he notes, shops are much more likely to use multiple hypervisors today than they were in the past.

You can certainly go much further with Microsoft's free hypervisor than you can with VMware's. At the top of the value chain, VMware still has some capabilities that Microsoft can't match. In between, the choice between Microsoft and VMware has never been harder. And that's great news for the customers.

LightBit ::

nebivedu je izjavil:

Škoda da za xen nimam teh podatkov, ampak samo za primer recimo kakšne so razlike md hyperV in wmware:
Cryptographic bandwidth (v Mb/s)
HyperV 2008 - 79
HyperV 2012 - 597
VMware 5.0 - 370
VMware 5.1 - 378

Saj to ne govori o napadu iz VMWare v Xen oz. obratno (vsaj kakor sem jaz razumel, ko sem diagnalno prebral papir).
Napad je med dvema enakima VM.

nebivedu ::

ja napad je med dvema enakima VM-jema, vendar ne vem, če ni ta vsa stvar res samo za VMware in xen, ki nimata možnosti virtualke prestavljat (sta stalno na istem hardware-u).

Namreč hyper v 2012 ima možnost upravljanja z vmm-ji in jih po želji prenaša iz serverja na server, zato mislim da je tukaj ta velika razlika.

Tale zadeva:
Single Root I/O Virtualization (SR-IOV) is the future of virtualization/acceleration of NICs and is supported by VMware (known as DirectPath I/O) but not for vMotion, so you can't move a VM using this technology. This loss of VM mobility is a big compromise because one of the biggest benefits of server virtualization is being able to move VMs around. There are other limitations to DirectPath I/O, such as a short list of supported NICs and no support for Memory Overcommit, VM Snapshots or Suspend/Resume. It should be mentioned that some of these limitations are solved on specific models of the Cisco UCS platform. Microsoft supports SR-IOV across editions and lets you live migrate a VM using SR-IOV to a host without an SR-IOV NIC as well as to another host with an SR-IOV NIC.

LightBit ::

Xen in VMware tudi lahko prestavljata med fizičnimi računalniki. http://www.vmware.com/products/vsphere/..., http://wiki.xen.org/wiki/Storage_XenMot...

Seveda v primeru, da mašini nista na enakem (drug procesor ...) fizičniem računalniku napad ne bo delovalo.

Zgodovina sprememb…

  • spremenil: LightBit ()

nebivedu ::

Našel: tudi xen lahko prestavlja virtualke med različnimi host-i.

Bo res enaka težava za xen, vmware in hyperv.

levaky ::

Da je nemogoče prestavljati VMje, ki imajo preko DirectIO passthrujane naprave mi je čisto logično.

Vsaj jaz si težko prestavljam prestaviti mašino, ki uporablja 1 navidezno mrežno za LAN in eno fizično, ki je "passthrough" preko DIO na mašino. Če se to premakne na drug host, kje bo tam mrežna? Razen če bi ESX poskrbel za forwardiranje prometa, ki pride na mrežno in na drugi strani ustvaril virtualno kartico...

Matej
---
http://www.zunaj.si - outdoor blog

nebivedu ::

Zakaj bi virtualka uporabljala fizično mrežno?

LightBit ::

Verjetno obstaja dober razlog. Morda za to, da omogoča kakšne low level opcije ali boljši performance.
Za GPU vem, da se to uporablja za 3D pospeševanje (brez prevajanja DirectX ukazov), OpenCL ali CUDA.

nebivedu ::

Če imaš ti polje 100 fizičnih strežnikov, gor postaviš recimo 500 virtualk. Recimo da so te virtualke obremenjene nekje samo 16 ur na dan, ostali čas jih pa rabiš nekje mogoče 1%. V HV2012 lahko komot narediš da virtualke sam sistem prestavlja počasi samo na en fizični strežnik, ostale fizične strežnike pa ugaša zaradi varčevanja z energijo, potem pa po potrebi glede na obremenitev spet prižiga ostale fizične mašine. Glede na tako zadevo ne boš imel fizičnih mrežnih priključkov, ker boš imel probleme.

Zato je meni sistem s serverskimi atom procesorji tako zanimiv - imaš 45 node-ov (en node 4 jedrni atom, 8gb rama in 4x mreža) v enem U4 racku na to postaviš kr nekaj virtualk, sistem ti pa sam potem zmanjšuje število nodeov glede na obremenjenost (vsa stvar brez licenc stane 60.000 evrov).

Zgodovina sprememb…

  • spremenilo: nebivedu ()

levaky ::

Enako lahko strežnike prestavlja tudi vmware. In ja, v 99% ne rabiš dostopa do fizičnih mrežn.

Kolikor sem bral po tujih forumih, ljudje uporabljajo fizične mrežne, kadar virtualizirajo routerje. V tem primeru je WAN link na mrežni, ki je fizično preusmerjena na virtualno mašino. Baje zaradi varnosti.

Bolj kot mrežne kartice se DIO uporablja za to, da se virtualki omogoči dostop do fizične grafične. Tako imajo potem ljudje eno ornk kišto z 1-3 grafičnimi karticami, potem pa KVM-over-IP do posameznih lokacij, kjer ima samo ekran, tipkovnico in miško.

Drug primer uporabe DIO je za t.i. All-in-one sisteme. Ornk plata+proc+ram, notri 1-2 SAS/SATA HBAja, ki jih preusmeriš na Solaris/FreeBSD virtualko, kjer ima potem VM direkten dostop do vseh diskov, na njih pa ZFS.

Ampak v teh primerih se VMji vedno nahajajo na enem in istem PCju in nekako ni potrebe po tem, da zadeva podpira DIO tudi če virtualke seliš na drug server, ker se to načeloma ne dela.

MAtej
---
http://www.zunaj.si - outdoor blog

Matthai ::

"If a bad guy can persuade you to run his program on your computer, it is not your computer any more".

"If a bad guy can persuade you to run your program on his computer, it is not your program any more".
All those moments will be lost in time, like tears in rain...
Time to die.


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Napad na AES v virtualiziranih okoljih

Oddelek: Novice / Varnost
193252 (2061) Matthai
»

Qubes OS - operacijski sistem za visoko stopnjo varnosti (strani: 1 2 )

Oddelek: Novice / Varnost
6910772 (5648) Matija82
»

Odkrita ranljivost v AES, nevarnosti ni

Oddelek: Novice / Varnost
133392 (1896) eVro
»

Raziskovalci uspeli rekonstruirati 1024-bitni RSA ključ v 104 urah

Oddelek: Novice / Varnost
53285 (2441) Matevžk
»

Nov, uspešnejši napad na AES

Oddelek: Novice / Varnost
122932 (2166) Matthai

Več podobnih tem