Slo-Tech - Zlonamerna programska oprema je v zadnjih letih postala naša vsakdanja spremljevalka na internetu, obvezen del računalnika pa so zato (vsaj za nekatere operacijske sisteme) postali protivirusniki in programi za odstranjevanje raznorazne nesnage, ki nam greni delo z računalnikom.
Protivirusno programje danes bolj ali manj uspešno pregleduje vsebino sistemskega pomnilnika in trdega diska ter s pomočjo virusnih vzorcev išče zlonamerno programsko kodo, ki jo nato skuša odstraniti.
Vendar pa trdi disk in sistemski pomnilnik nista edina kosa strojne opreme, kamor je mogoče skriti zlonamerno kodo. Kljub temu, da je področje strojnih korenskih kompletov (ang. firmware rootkit) manj znano, pa nekatere raziskave kažejo, da tovrstne grožnje niso le znanstvena fantastika.
V tokratnem članku smo zato opravili intervju z neodvisnim svetovalcem za varnost in omrežja Arrigom Triulziem, ki je novembra lani predstavil svojo raziskavo strojnih korenskih kompletov. V okviru svojega raziskovalnega dela je razvil strojni korenski komplet, ki ga je shranil na mrežno kartico. S pomočjo orodja NIC SSH, ki ga je razvil, se je na tako okuženo mrežno kartico mogoče neopazno povezati in mimo operacijskega sistema (in seveda požarnega zidu) dostopati do računalnika.
Seveda je odveč pripomniti, da takšne okužbe ni sposoben zaznati noben protivirusnik in praktično nobeno programsko orodje. Možnosti nadzora so tako skorajda neomejene, zaznava okužbe pa težavna.
Sploh pa zato, ker je avtor predstavil koncept, ki ni požel zaslužene medijske pozornosti. Vsi so slišali za Ring -3 rootkite a le redki za projekt Maux. Pohvalno.
Se pravi, če kupiš recimo elchapo 100 MBit kartico z RTL8139 čipom in jo vštekaš v mašino, ki se je sicer niti ne dotakne ( ker recimo nima driverjev zanjo ), ji lahko remotely zaflashas BIOS ?
Če je to res, bi bilo treba nekoga pripeljat pred strelski vod in si čimprej omislit open-source hardver, sploh pa mrežne...
KOt sem jaz doslej razumel zadevo, je RTL8139 nič drugega kot avtomat, vdelan FLASH pa je samo namenjen BIOS kodi za main CPU.
Včasih je bilo tistih par KB FLASHa posebej, sedaj so pa hoteli znižati stroške.
Nikoli ni bilo rečeno, da bi bil notri nek CPU, ki bi lahko to kodo tudi sam izvajal.
Jasno je tudi, da je lahko mrežna master na PCIju, ampak le v čisto mehaničnih DMA prenosh, ki se odvijejo tako, kot je nastavljeno v posebnih registrih, ne pa da se lahko čipu strga in jih izvaja kar tako na željo remote hosta...
1. On je tam shekal "Broadcomove Communication processorje", ne pa NIC-e. gre za čipe BCM9xxx, ne pa BCM-8xxx, ki so na karticah. Za to je uporabil SDK, ki je na voljo za DL pri Broadcomu. Za NICe ni videti ničesar ( BCM-8xxx, BCM-81xx itd).
2. Tudi tam ne gre kar tako za nek "Derren Brown" paket, ki ti hipnotizira kartico in jo prepriča v to, da počne norčije. Potrebno je to, da čisto normalno poženeš program, ki ti ( skrito?) preprogramira mrežno, kar je malce težje, sploh če si neprivilegiran user.
3. Napad se da čisto lepo zaznati, saj ti lahko narediš čeksum FW FLASHa med bootom najbrž...
Če se prav spomnim, Matthai je nekoč omenjal, da to gre z nekaterimi 3Com mrežnimi, s sfriziranim FW, oz. s FW, ki je že po defaultu namenjen za remote šarjenje po kišti.
Z RTL čiperajem pa dvomim, da gre, ni dosti boljši kot Win modem, oboje je samo pretvornik nivojev, vse ostalo dela CPU.
Potrebno je to, da čisto normalno poženeš program, ki ti ( skrito?) preprogramira mrežno, kar je malce težje, sploh če si neprivilegiran user.
Ja, v vecini primerov je najbrz tako (na sreco). Sej poanta tega ni, da bi preko vulnerable mrezne kartice ownal masino, ampak da po tem ko enkrat dobis na drugacen nacin vse privilegije zakrinkas svojo prisotnost na sistemu oz. si naredis nek backdoor, da bos lahko drugic lazje oz. se vedno (kljub zakrpanju napake) dostopal do masine.
Drugo je, ce bi nek proizvajalec namerno stancal backdoore. (Glede na to, da je vsa proizvodnja na Kitjaskem - kdo ti sploh garantira, da ni ze zdaj tako?)
Ta(k) backdoor je tako kul zato, ker prezivi ponovno instalacijo OS-a, razno softwarsko cekiranje itd. Ponovadi po tem ko odkrijes, da je nekaj narobe samo reinstaliras sistem, malo verjetno pa je da bos takrat sel preverjati se ves hardware.
3. Napad se da čisto lepo zaznati, saj ti lahko narediš čeksum FW FLASHa med bootom najbrž...
Ni tako simpel. S cim pa primerjas tisti checksum? Kako ves, da je ta del ki racuna checksum trustworthy? V bistvu moras nekako zagotoviti, da prvega dela (ki se izvede ko pozenes PC) nobeden ne more spreminjati, ta potem preveri, ce je BIOS zaupanja vreden. Ce je preda njemu kontrolo in ta potem preverja naprej, tko po korakih. Vsaj tako si jaz predstavljam vse skupaj.
V bistvu ni tako simpel. S cim pa primerjas tisti checksum? Kako ves, da je ta del ki racuna checksum trustworthy? Kaj ce mrezna nekako laze, tistemu ki racuna checksum?
Primerjaš ga lahko s checksumom known_good kartice. Recimo s takim, ki je bil narejen na novi kartici, ali pa takrat, ko si naložil svoj FW.
Ja, nič ni 100% ampak to bi praktično ustavilo možnost takega napada.
Jah napad bi ustavilo ze to, ce ne bi bil EEPROM za firmware, ampak EPROM Seveda pa je IMHO vedno tradeoff med enostavnostjo za uporabo (ter ceno) in varnostjo na drugi strani.
Če se prav spomnim, Matthai je nekoč omenjal, da to gre z nekaterimi 3Com mrežnimi, s sfriziranim FW, oz. s FW, ki je že po defaultu namenjen za remote šarjenje po kišti.
Ja. Daedalus ima doma eno tako staro kišto. Pa ne gre za hack, gre za feature. Mislim, da se zadevi reče remote console ali nekaj takega.
Primerjaš ga lahko s checksumom known_good kartice. Recimo s takim, ki je bil narejen na novi kartici, ali pa takrat, ko si naložil svoj FW.
Res? Preberi si, ko Triulzi govori o revizijah čipov. Če bi uspel dobiti točno tako kartico, bi morda še šlo, ja...
Sploh je pa problem "proizvodnja na Kitajskem" (ali v ZDA, hehe). Konec koncev imamo lahko tudi "povezanega" uvoznika. Saj se še spomnite SOVInega spletnega podjetja Webs? Verjetno pri SOVI niso taki genialci, da bi se zadeve prvi spomnili. In verjetno imajo tudi kakšni kriminalci nekaj možganov...
Kako pa veš, da je FW ki ga imaš nekje drugje trusted?
Lahko je tudi ta prirejen in potem flashas s prirejenim.
Igralne konzole to rešujejo z asimetrično enkripcijo firmwara. Seveda bi taka rešitev pomenila da vsi anti-DRMjevci takoj priletijo z vilami in baklami.
DRM / TC tudi ni rešitev. Preberi intervju natančno...
Poleg tega je že Rutkowska pokazala, da je digitalno podpisovanje gonilnikov (v Windows) v bistvu le slaba šala...
Jaz v bistvu sicer nisem govoril o DRMju oz. TC kot takemu (primarni namen teh tehnologij ni v zagotavljanju zaščite za firmware), še manj pa o podpisovanju gonilnikov (ki ima čist drug namen).
Firmware v konzolah je namreč podpisan z digitalnim podpisom, katerega loader (ki je del samega CPU) preveri pred nalaganjem in zavrne zagon, v kolikor se podpis ne sklada. To zagotovi, da firmware sam ni bil podpisan. Seveda pa je tu jasno, da privatni ključ, s katerim je firmware podpisan nikakor ni javno dostopen.
Metoda se je izkazala kot zelo učinkovita, saj trenutno edina znana možnost izogiba temu zahteva dostop do same strojne opreme ter opremo katero zelo težko skriješ v žep ;)
Podpisovanje gonilnikov ima tukaj močno veliko veze.
Kot je namreč pokazala Rutkowska, je problem v tem, kdo lahko dobi CA podpis svojega ključa. Izkaže se, da je treba poslati mail in fax na Microsoft in plačat ene 150 EUR. Z nekaj triki je ona tako zadevo izvedla popolnoma anonimno - preko neta. Tudi potrdila o registraciji podjetja ni težko ponarediti (in seveda - različne države imajo različna potrdila - živ bog ne ve kakšno je recimo v državi XY). Proizvajalcev hardwera je preprosto preveč, da bi vsakega podrobno pregledal.
Pri konzolah je stvar bistveno drugačna, ker je proizvajalec (sestavljalec) en sam in vgrajuje tiste komponente, ki jih je sam kupil. Nabor komponent je seveda omejen in ne moreš v konzolo vgraditi nek svoj hardware.
Proizvajalcev hardwera je preprosto preveč, da bi vsakega podrobno pregledal.
Tule se tvoj argument zlomi. Proizvajalcev hardwara niti približno ni preveč, da se ne bi dalo preprosto zagotoviti, da se na določenem kosu hardwara izvaja samo firmware, ki pripada dejansko tistemu proizvajalcu. Tak matching ni noben problem zagotoviti. Pri driverjih je situacija drugačna, saj namen tistega podpisovanja NI zagotavljanje, da določen driver pripada točno določenemu kosu strojne opreme. Prav tako se driverji neprimerno hitreje spreminjajo.
Zato povezave pri tej vrsti zaščite s podpisovanjem driverjev ni.
Glede na to da nisi omenil nič drugega se očitno strinjaš, da je tak način zaščite pred temi napadi lahko zelo učinkovit in jih lahko praktično v celoti prepreči.
Tule se tvoj argument zlomi. Proizvajalcev hardwara niti približno ni preveč, da se ne bi dalo preprosto zagotoviti, da se na določenem kosu hardwara izvaja samo firmware, ki pripada dejansko tistemu proizvajalcu. Tak matching ni noben problem zagotoviti. Pri driverjih je situacija drugačna, saj namen tistega podpisovanja NI zagotavljanje, da določen driver pripada točno določenemu kosu strojne opreme. Prav tako se driverji neprimerno hitreje spreminjajo.
Ne. Imamo namreč tudi revizije hardwera. Poleg tega imajo proizvajalci razvojne obrate raztresene po vsem svetu. Zelo težko je tudi zagotoviti, da bi recimo imeli enako stopnjo varovanja v vseh obratih. Poleg tega recimo pride urgentni update firmwarea - v tem primeru bo treba poupdatati še TPM čip... ali pa uporabiti digitalno podpisovanje. Ampak ko ti key enkrat leakne, imaš problem. Boš nehal zaupati vsemu hardweru tega proizvajalca, ali samo hardweru, ki je bil proizveden od določenega datuma dalje, kako boš vzdrževal PKI... kaj pa če leakne na skrivaj?
V praksi bi zadeva naletela na kup problemov. Saj ne rečem - v teoriji bi se dalo to super rešiti, dvomim pa,da bi zaživelo v praksi.
Brane, pozabljaš na bistveni problem. Checksumov ne moreš preverjati po tem, ko si enkrat že zbootan, saj so te takrat lahko že Ring -X rootnili in ti strojna oprema laže.
Rešitev bi bil seveda poseben TPM ali Coreboot. Vendar je tudi tukaj nekaj problemov. Kaj se zgodi ob netbootu? Je morda eth že rootnil BIOS oz. je rootnjen že sam in BIOSu laže? Kje se bodo shranjevali checksumi? V BIOSu? Kako bo z updatei checksumov?
Cel kup praktičnih problemov. Ne pravim, da jih ni mogoče rešiti, bi pa zadeva zahtevala temeljit redesign PCja. Poleg tega folku težavo predstavljajo že okužene e-mail priponke... v praksi je tole za njih pure science fiction...
No, BIOS pač prebereš s programatorjem, če ravno to sumiš.
Ko veš, da je BIOS kosher, potem že lažje gradiš naprej. Če imaš recimo coreboot, lahko direkt iz njega preveriš chscksume vseh ostalih FLASHev v sistemu.
PA še en praktičen problem - kam bi shranil vse checksume vseh revizij? Na TPM čip?
Še vedno ne razumeš kak stvar dela.
Ti maš poleg samega Firmwara še shranjen checksum tistega firmwara, ki je kriptiran s privatnim ključem zaupanja vredne krovne organizacije. Loader (ki je realiziran na samem CPUju in se ga ne da spreminjat) ta checksum odkriptira ter ga primerja z lastno izračunanim. Ne rabiš s tem nobenega TPMa in tudi injection drugega checksuma je hudo zakomplicirana zadeva, za katere rabiš kaj več kot pa samo namestiti programčič na mašino (v bistvu je potreben tak poseg, katerega ni mogoče kar mimogrede "spregledati").
Revizije hardwara tule nimajo nobene veze, saj vsaka revizija nosi sabo svoj checksum.
Tako ti edina luknja ostane dejstvo, da krovna organizacija ne sme zgubiti svojega privatnega ključa.
Kot sem že omenjal: tak sistem že deluje zelo dobro, trenutno je edini napad možen timing attack, kjer je potrebno direktno na vodilo ob točno pravilnem trenutku dodati pravi ključ, kar je vse prej kot trivialno in tudi uporabnik načeloma človeka z par tisoč EUR vredno elektroniko, ki stika po njegovem sistemu, relativno zlahka opazi.
No daj mi pojasni, kako bi to rešil. Recimo, da jaz ustanovim svoje podjetje v Spodnjem Dupleku (ali celo v neki azijski vasi) in začnem izdelovati nek hardware... Kako bom potem prepričal CA, da sem jaz res jaz... in da ni recimo jaz nekdo iz neke avstralske vasi?
Ravno o tem govorim. Nimajo povsod po svetu urejene "notarske službe".
Pa še tole - ko bom razposlal urgentni update firmwarea - koliko časa bo trajalo, da bo CA razposlal naokrog na vse računalnike popravljene checksume?
Kako pa ti veš da si nekaj prejel od določene osebe? Ne se glupega trola delat no. Je žaljivo in proti pravilom.
No, tole terja nekoliko podrobnejše pojasnilo. Ne delam se neumnega, gre pa za to, da ti ne razumeš kako deluje PKI infrastruktura. Oz. zadeve morda poznaš v teoriji, ne veš pa, da se v praksi vse skupaj lahko začne obnašati precej... nenavadno.
Recimo, da se mi danes javi podjetje iz Azije, ki mi pošlje neke podatke. Kako vem, da sem podatke prejel od njih? Na podlagi e-naslova? Na podlagi dejstva, da sem jim odpisal odgovor in so potem iz tega naslova potrdili podatek? To vsekakor ni dovolj zanesljivo.
Na podlagi digitalnega podpisa? Aha! Kako sem ga pa dobil? Kateri CA ga je potrdil? Nek Azijski? Kako pa vem, da je ta Azijski CA zaupanja vreden? OK, morda ga je potrdil svetovni CA. Kako pa naj vem, da azijski CA ustrezno skrbi za vse varnostne postopke in da ni prišlo do leaka?
Zakaj sem prej omenil digitalne podpise driverjev? Zato, ker je tam podoben problem. Kako dokazati, da si ti res podjetje XY. Ker ne obstaja univerzalen svetovni register podjetij - in ker se potrdila o ustanovitvi razlikujejo glede na nacionalne države, je Microsoft pač ubral neko bolj ali manj smisleno pot, kjer pošlješ fax in e-mail. Dejstvo pa je, da se da to povsem enostavno ponarediti. Le stane te nekaj sto EUR. In ti dobiš veljaven podpis s strani MSja.
Zdaj pa malo razmisli naprej in ugotovi zakaj se za biometrične potne liste niso odločili za uvedbo PKI infrastrukture. Saj, v (Zahodni) Evropi bi zadeva še šla. Ustavi se pa že pri Albaniji in njihovih varnostnih postopkih varovanja PKI infrastrukture.
PKI infrastruktura v realnosti niti približno ni enostavna za vzdrževat.
Hello, this is Arrigo as invoked by Matej... Google Translate and me took about 10 minutes to register and now I need to Google Translate all your comments... once I have made sense of them I'll try to respond.
You can also use presis to help with translations. With it's 500 characters limitation it's not as convenient as Google, but it often makes more sense (and doesn't try to translate names).
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Before you wrestle your way through, I'll try to ease your pain ate least regarding my questions by repeating them again:
1. As resume of an exploit was posted here, it seems as it would be possible to do it totally remotely, ie by sending some kind of "magic packet" that would cause NIC itself to reflash its memory, but fineprint suggests that much more is needed- user has to execute malignant program and that program has to have access to NIC's registers. Even after reflashing the new FW, this ought to be detectable simply by checksumming the NIC's Flash. What exactly is needed for exploit to function and why would its later detection be a problem ?
2. NIC's you have used aren't exactly common gear. I have several NIC with broadcom chips, but all of them are BCM8xxx series, which do not seem to have internal MIPS core, at least not exposed to the user. So, are owners of elcheapo (Realtek etc) cards in danger or is their gear simply "too stupid" ?
Let me try to answer a few of the issues which have been raised so far...
1) Firmware checking: it is not as simple as saying "oh look, I have a known-good card, let me compare firmware"... Matthai appears to say the right stuff (at least the Google interpretation makes sense) and indeed there is more to it than a checksum. Consider a card which uses digital signatures: this implies a complete PKI infrastructure and within the card there needs to be a CA certificate to verify the signature. Now consider OEMs: they want to slightly modify the NICs so they need to have either a 2nd-level CA certificate so that they can sign firmware on their own or have a single signing key. What happens if they "lose" this key? Can it be lost? If this were to happen how do you push a CRL into an installed NIC? What about knowing if the firmware is good? It is the firmware itself which has to support loading new firmware: when you get an OK how do you know that it is a real OK and what happened was not simply >/dev/null? The answer to this is (partially) TC but then you land the chicken and egg problem of remote wakeup. Now, I don't know how many of you have ever used WoL (Wake-on-LAN) but this is a popular feature in large companies where they want desktops to wake up in the middle of the night so that updates can be pushed out to them. So this means that the NIC wakes up the machine (allow me this simplification for the time being) and therefore it is the NIC which drives the powering up of the system. When does the TC chip wake up? Should it always be up? But then the WoL packet needs to be "authorised" somehow (not in the protocol right now) for the NIC to react, and then the NIC has to ask the TC chip to verify the NIC? I don't have an answer for this, I am just trying to show how the story as a whole is complicated. I am also assuming that you are aware that right now TC implementations do no verification whatsoever of PCI devices or indeed of the PCI bridge.
2) remote flashing: it exists on several cards for the convenience of OEMs. Once the card is installed flashing requires booting into an operating system which is "expensive", far more than instructing someone on the assembly line to plug a UTP cable in and press a key on a machine. So, what is required? Well, in the cards I've looked at a magic UDP packet followed by the data in the correct format so nothing else is required. What about the "user experience"? If the user is on the system when the NIC is being remotely flashed then the NIC stops accepting and sending packets so you get the pretty red cross on the computer in the Windows tray. Big deal? Yes because users notice but what about a firewall? Also, for how long is the NIC offline? answer: under a minute. How do you detect it? You don't unless you have a way to extract the firmware without asking the NIC otherwise I can serve you what I want.
3) The cards... long story. To cut it short because this post is long enough (and Matej might want to add another interview) it is quite simple: the more expensive the NIC the more vulnerable it is until you reach a point where it is sufficiently expensive that it secures its firmware with fully-fledged PKI. Several mid-range Broadcom cards come with MIPS CPU and yes, a super el-cheapo RTL card won't provide much of an attack surface but how many juicy targets (for this kind of attack) run RTL? I can assure you that several HP DL3xx series systems are juicy targets...
4) EFI: been there, done that, seen the film. EFI (and ACPI) are ideal companions to my firmware hacks. You can use EFI to pre-load the GPU stuff. You see, when you look at my slides I sort of gloss over the slight issue of persistance, mainly because the PACSEC 2008 slides reflect my 2007 work (I can't tell you where it was presented before PACSEC but let it be sufficient to say that PACSEC data was almost one year old). If you take a machine with nicssh installed (i.e. full Project Maux Mk. II) and you cold boot it you are only left with the NIC part of it... That is obviously Not Good so you need to figure out persistence and this is where you look around: during the boot process the BIOS initialises the PCI devices *before* booting the OS (long before actually, think about the good ol' "Press Ctrl-A to configure your Adaptec 2940") so what you do is you have a little bit of the NIC firmware which responds to the PCI device initialisation asking to load from the hidden "spare" sectors of the SATA drive the data into a specific GPU memory location. The devil is of course in the detail and the beauty of EFI is that it is fully modular and Apple has a nice EFI SDK available for download and I had a spare iMac 2006 lying around... Note also, regarding the other BIOS posts, that precisely because the BIOS initialises the PCI devices you have an interesting problem there too: how do you know what you have initialised?
5) Jedi packet trick: combine the remote NIC flash with an internal "over-the-PCI-bus" NIC flash and then it becomes clear that you have a direct conduit between the inner & outer NICs bypassing all OS controls. Note also that there is no way to count PCI-to-PCI transfers in the current PC architecture ("current" = "shipping").
6) For the Joanna fans: she recently presented a paper at Intel about hacking the AMT processor ("business-class" service processor, does the same as iLO for HP and IPMI support on SuperMicro boards). She comes in playing with the CD boot and she attacks "from above". Think about how you would hack from below...
Well, obviously solution demands harware of some quality.
One thing would be to be able to read internal Flash regardless of the FW in the card. Other would be to demand offsite update to be explicitly activated for users that want it.
Speaking of AMT, I've seen it implemented in several mid-range HP workstations (priced around 600-800EUR here). And I don't think I've seen a HP server that doesn't have a Broadcom card or two.
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Regarding Broadcom. I never had any succes in obtaining even the slightest bit of basic design information about their products. Leave alone the firmware.
When does the TC chip wake up? Should it always be up? If it has Stand-by power and specified bit to send signal to the mainboard, it is defenitely on and in listening state. WOL isn't really data-level afaik and is only power-on signal to the mainboard, once chip 'decodes' the packet it gives the signal so the system will power on.
2. Flashing may be done prior to 'assembly'. Usually it is a simple 8 pin (Atmel?) chip that holds all basic data. You can usually find it on a discrete card. I'm not sure if same works for integrated NIC's or. when the chip itself has some flash memory, which probably has.
Belkin's NIC, F5D5000y holds Atmel's AT93C46 1-4Kbit serial 3-wire eeprom. Same type with old 3Com's EtherLink III, 10Mbps, which I think was used in some compaq pc that supported PC-trough-network diagnostic.
I'm not sure how flashing this chip would work over network. It is certainly writable from DOS.
Some nanoparticles are more equal than others
Good work: Any notion of sanity and critical thought is off-topic in this place
