Únik privátneho kľúča AMI (diskuse)

[mankind_boost]

"Privátny kľúč na podpisovanie firmware"

Dobře jim tak!

[Bill Gates]

proč ?

[pc2005]

A link? Jako ne, že bych chtěl klíč, ten si vygeneruju sám, ale ten zdroják by se za pár (10? ) let hodil (až si koupím další komp).

BTW Je vidět, že taiwan secure boot opravdu pochopil, zveřejnění kódu umožní objevení bugů .

[Pavel Stárek]

Ty zdrojáky pro studijní účely by se mi hodily. Nějak to nemůžu najít.

[Pavel Stárek]

Kdyby to někdo potřeboval tak torrent je zde http://www.torrenthound.com/hash/bdc151b63cac4b0fdf06ba98ddf34f64b44180c3/torrent-info/AMI-Firmware-Source-Code

[Andrej]

A few hours ago I received a call from my frequent research partner, Brandon Wilson, about an open FTP server hosted in Taiwan serving up some rather interesting data. Internal emails, various system images (and even the Ghost software!), numerous photos - some personal, some high resolution PCB images, private specification sheets, Excel documents loaded with private information - but that wasn't the worst.

In a folder called code was quite a treasure. The source code for different versions of American Megatrends (AMI) firmware - but there was even a bonus on top of that! They included their private signing key with the code in the 'Ivy Bridge' archive.

308204A30201000282010100ED71D63F21FF0B4563A43D871D22448FC9...

If you aren't familiar with how AMI does UEFI firmware upgrades, they were nice enough to produce some documentation (PDF).

By leaking this key and the firmware source, it is possible (and simple) for others to create malicious UEFI updates that will be validated & installed for the vendor's products that use this 'Ivy Bridge' firmware. If the vendor used this same key for other products - the impact could be even worse. Even with a quick reaction, odds are users will be unprotected for some time. As users often don't install firmware updates unless they are having issues - I expect this one to be around for a while.

This kind of leak is a dream come true for advanced corporate espionage or intelligence operations. The ability to create a nearly undetectable, permanent hole in a system's security is an ideal scenario for covert information collection.

This vendor's lax (non-existent?) security could have much broader repercussions though. For AMI, they now have a major piece of intellectual property freely available for download by competitors. For users, this code could now be subject to new scrutiny - if a security issue is found in the firmware, it could potentially impact all users whose firmware is based on the leaked code.

If the code was old, as it's been when products like Symantec's were leaked, this might not be so bad - but it's not.

References in the files indicate that the code is from sometime in February 2012 - so this is fairly current code. For AMI, I hope they perform a security audit of their code to make sure that this leak doesn't put users at excessive risk.

A foolish oversight now has the potential to impact many.

I've contacted both the vendor involved and AMI to alert them to the issue. Obviously, I won't be releasing the name of the vendor, the FTP address, or anything that was seen on the server.

-- http://thepiratebay.se

[pc2005]

some high resolution PCB images, private specification sheets

Hmm kdyby to byly schémata motherboardů, tak bych možná začal slintat (a šetřit) .

[Jenda]

magnet:?xt=urn:btih:bd8b50ebfc73b4f0ea53bda4f7f6a1861b1eb19c&dn=leaked%5Fbios

[Ondra]

AMI Firmware Source Code, bdc151b63cac4b0fdf06ba98ddf34f64b44180c3

[Pali]

http://www.mmnt.net/db/0/0/ftp.jetway.com.tw/CODE/

[Pavel Stárek]

Už to chce nějaké jméno a heslo, je tedy lepší použít ty torrenty.

[pc2005]

Zajímavý, včera to ještě psalo nějakou jinou chybovou hlášku (když jsem to neúspěšně hledal na torrentech).

[JZD]

Koukám že na Uložto to někdo nahrál taky http://ulozto.cz/xSEVY1dL/code-tar-gz.

[ewew]

Dobrý nápad podpisovať všetko jedným kľúčom. Toto je vážna situácia. Neviem síce aký typ kľúča používaju, ale keď má niekto súkromný kľúč, tak revokácia zrejme nepomôže.

Lepšie by bolo keby mala každá generácia biosu/firmvéru vlastný podpisový kľúč.

[Jendа]

Možná by bylo nejlepší, kdyby se FW na úrovni blobu flashovaného do BIOSu vůbec nepodepisoval.

[Nikt0]

+1

[ewew]

To je verejný kľúč zadrotovaný v hw ? Lepšie riešenie je podpis súboru na webe výrobcu biosu. Nechať na uživateľovy overenie pravosti.

[Jendа]

To je verejný kľúč zadrotovaný v hw ?

Vypadá to tak (alespoň tak jsem to pochopil, v HW se moc nevyznám).

Lepšie riešenie je podpis súboru na webe výrobcu biosu. Nechať na uživateľovy overenie pravosti.

Přesně tak jsem to myslel.

[Ovocníček]

Až na to, že to podepisování se dělá kvůli tomu, aby ten FW nemohlo něco flashnout za zády uživatele.

[Jendа]

Co tedy umožnit flashování jen při výběru nějaké možnosti/volby v BIOSu při bootu?

[ewew]

Táto možnosť som raz videl v jednom starom PC s Award biosom. Len riziko je pri inštalácii. Nemám to overené ale vtedy môže dôjsť k porušeniu biosu.

[kralyk z abclinuxu]

By mohlo něco zopakovat stejnou činnost, kterou při výběru té volby dělá ten bios. Security through obscurity...

[petr_p]

Jak?

[sestka vlevo dole]

Delate si legraci? Vyberem v BIOSu spoustite nejakou sekvenci prikazu strojoveho kodu. Neumite si predstavit, ze si ji spoustite jinak nebo tu samou cinnost vykonavate jinou sekvenci?

[potato]

Ne, neumím, pokud je například zařízení konstruováno tak, že se připojí při cold bootu a lze ho odpojit/vypnout tak, že ho nelze softwarově připojit/zapnout. BIOS ho samozřejmě musí takto odpojovat/vypínat.

[kralyk z abclinuxu]

Aby to mělo smysl, musel bys zakázat možnost modifikace biosu.

[Jendа]

Modifikace BIOSu lze provést pouze za výše uvedených podmínek (coldboot).

[sestka vlevo dole]

BIOS karet se inicializuje drive nez se ke slovu dostane uživatel.

[kralyk z abclinuxu]

Hm. Takže v podstatě řešení technicky velmi podobné lockdownu u herních konzolí. V takovém případě závisí bezpečnost celého řešení na (ne)přítomnosti bugů v implementaci.

[Jendа]

To platí snad u každého řešení. Nebo jak jinak bys to chtěl mít? Klidně navrhuj.

[kralyk z abclinuxu]

Jasný, platí to vždy, ale tyhle řešení jsou na to o něco citlivější, mi přijde. Ten BIOS a celá ta POST sekvence včetně HW prostě musí být naprosto neprůstřelný, prostě proto, že tam ta funkce přepsání BIOSu nebo klíčů někde je.

Jinak ale není to špatný řešení, v rámci možností to je asi opravdu nejrozumnější.

Celkově ale nevim, jestli bych do toho šel, protože proti čemu mě tohle reálně ochrání? Proti zásahům do bootu a kernelu z userspace, to je asi tak vše. Proti Evil Maid mi to nepomůže. Proti děravýmu userspace taky ne.

[Jendа]

Jinak ale není to špatný řešení, v rámci možností to je asi opravdu nejrozumnější.

No právě, jak bys chtěl implementovat řešení odolné proti chybě v implementaci sebe samého?

Celkově ale nevim, jestli bych do toho šel, protože proti čemu mě tohle reálně ochrání?

Jde o to, že když tě někdo zpwnuje, stačí ti přeinstalovat OS z důvěryhodného disku, a jsi čistý. Zatímco když mohl nainstalovat backdoor do HW, musíš vyhodit celý počítač do popelnice.

[kralyk z abclinuxu]

Tím "backdoor do HW" myslíš backdoor do firmware? Nebo kam do HW?

[ewew]

Už je to nejaký čas čo sa objavila táto správa o bios vírusoch.

[Jendа]

Ano, myslím tím FW. Současný FW je uživatelem nekontrolovatelný a i třeba taková síťovka je docela výkonný počítač. Co když ti útočník přidá do jejích FW featuru, že když přijde magic packet, karta ti přečte a odešle nebo přepíše přes DMA nějaký kousek paměti? Naprosto mimo režii OS a možnosti uživatele to ovlivnit. A ano, tohle už někdo realizoval. Zadejte do svého oblíbeného vyhledávače ethernet card backdoor a proklikejte si prvních pár odkazů.

[pc2005]

Tak do UEFI zaintegrujeme driver pro IOMMU .

[kralyk z abclinuxu]

Taky mě to napadlo, ale stále mi to přijde přitažené za vlasy. Už nejsme v 90. letech, kdy měli všichni Award BIOS. Na druhou stranu je ale pravda, že každý druhý má na laptopu wifinu Broadcom. Ale stejně by musel případný útočník ušít útok na míru jak mému OS, tak i mému HW. Neříkám, že to není možné, určitě je. Četl jsem články o proof-of-concept útocích tohohle druhu. Ale prakticky vzato mě jiné bezpečnostní problémy aktuálně trápí mnohem víc než tohle (resp. jejich pravděpodobnost)...

[petr_p]

Když nadhazujete vykonávání kódu, tak budu kontrovat privilegovaným stupněm System Management Mode, který není dostupný ani operačnímu systému.

[little.owl]

Presne tak.

[sestka vlevo dole]

Ovsem ale to, co bios spustí, nemusi byt operacni system, ze

[little.owl]

Nicmene muze byt nastaven tak ze nabootuje jen a pouze kod podepsany nejakym klicem, ze.

[sestka vlevo dole]

Presne tak

[petr_p]

Kódu, co firmware spouští po POSTu, můžete říkat jakkoliv, ale nic to nemění na tom, že takový kód nemá přístup k celé fyzické paměti, některým registrům, instrukcím a portům.

Bezpečná aktualizace firmwaru se může dělat tak, že cokoliv, třeba i zákeřný program, připraví obraz nového firmwaru na určitou fyzickou adresu, a pak dá vědět firmaru (ve světě IBM PC se používá ACPI). V příštím okamžiku, kdy pojede SMM, tak firmware zkontroluje integritu obrazu, zkopíruje jej do EEPROM, kam přirozeně software na úrovni operačního systému nemá přístup, a je hotovo.

[little.owl]

Zrovna zpusob jak SMM pouzival SMI nebyl nejstastnejsi a byly tam uz urcite problemy (1,2). V UEFI SMM se z toho poucili a implementuji komplexni protokol, vcetne bufferu, ktere se pouzivaji pro prenos dat. AFAIK ACPI tam snad neni primo pouzito, je to UEFI service s vlastnim interfacem a OS nepristupnou pameti.

[pc2005]

Zajímavý historie se opakuje. Přechod z MSDOSu na OS s ochranou paměti (program si nemůže dělat, co se mu zlíbí), se mě moc nelíbil (protože jsem neměl možnost se v tom hrabat). Takže teďka to bude podobný, akorát to bude firmware.

BTW První iteraci jsem nakonec vyřešil Linuxem. Že by se brzy víc prosadil coreboot?

[little.owl]

Ring model je fajn.

[pc2005]

Akorát se přidávaj nový a nový ringy (a žere to tranzistory).

[Johny]

Na to by stačil jeden jumper na základovce.....

Takže pravej důvod asi bude jinde..

[xkucf03]

+1

[Ovocníček]

Blbost, to by všecky kompy se záruční nálepkou musely do servisu, hodně notebooků třeba taky i po záruce (mňam), a vůbec, to byste si asi gratuloval za ten nápad, kdybyste pak chtěl flashovat těch kompů víc ;)

[prqek]

Tak se by od jumperu natáh kabel na jehož konci by byl malý přepínač přístupný bez rozmontování počítače, ale ne zas moc snadno přístupný. U těch nb třeba pod baterií.

[little.owl]

Tohle je zbytecne drahe, zejmena ted kdyz je z i hlediska vsech nakladu lepsi pouzit dve pameti pripajene na boardu nez jednu v socketu. Normalni uzivatel Windows navic nic takoveho nepotrebuje.

[bohyn]

ideální řešení pro bfu, chytráku. Navíc bych tě chtěl vidět jak to řešíš na tabletu nebo notebooku

[Rejpal]

Musím si vybrat, jestli to chci zabezpečené nebo chci "řešení pro bfu".

[Johny]

BFU si bude flashovat BIOS? Jasně.. Už to vidím...

[Sten]

Ne, veřejný klíč je v BIOSu a ověřuje se jím to, co se tam místo něj snaží naflashovat

[Jendа]

BIOSem se podle mě zhruba myslí HW. Nebo jak by měl vypadat klíč v HW? Vyrobený pomocí traces na desce? :)

[little.owl]

Treba embedded OTP (One Time Programmable) pamet, na SoC uz i casto integrovana.

[bohyn]

super nápad, otevřeme virům brány rovnou do biosu.

[Jendа]

Nechápu, mohl bys to trochu rozvést?

[bohyn]

aspoň některé biosy (třeba na dellu) se dají flashnout z OS. V podstatě jediné co je chrání je podpis

[Jendа]

To je ale špatně. Pak by bylo vhodné řešení navrhované výše.

[bohyn]

nebylo, vytvoříte flashku v komprimovaném OS a kdo zaručí že na ní bude to co jste stáhl z webu výrobce?

[Jendа]

Aha, takže uživatel by neměl mít možnost dát si do BIOSu, co chce. S podobnou logikou, proč by měl mít možnost nainstalovat si jaký OS chce nebo jaký SW chce?

[Failer]

Máš problém se Stallmanem?

[Jendа]

Já? Ne, proč?

[Ondrej 'SanTiago' Zajicek]

No, nevim jak v novych UEFI systemech, ale jinak flashnout BIOS z OS bez jakekoliv ochrany (jine nez opravneni v OS) AFAIK slo bezne po mnoho let, zadne klice se nepouzivaly a pritom viry napadajici BIOS se prakticky nevyskytovaly.

[pc2005]

Pokud nepočítám EPROMky na starých kompech (naposled tak první pentia, ale už 486 čipsety podporovaly flash - to je koneckonců stejně jen otázka vyvedení navíc pár vodičů s paměťové sběrince), tak všechny PC, co měly měnitelnou paměť s BIOSem, mohly tu paměť modifikovat procesorem.

Možností bylo i na BIOSu mnoho:

- První sektor obsahuje záchranný flash program (amiboot.rom z diskety).

- Přímý přístup na adresní sběrnici BIOSu (vhodná sekvence čtení/zápisu do (ne)obyčejné lokace v operační paměti).

- Četl jsem o nějaké subfunkci int 15h, která to měla umožňovat, nikdy jsem ale nepoužil.

P.S. (do publika) Podporuje UEFI něco jako amiboot.rom v případě výpadku energie během flashe? Jak se řeší secure[boot/flash] v takovém případě?

[petr_p]

Nevím, jestli to vyžaduje standard, ale můj UEFI firmware od Asusu, který je založený na právě zde propíraném AMI, má na desce jumper, který způsobí po zapnutí přepsání firmwaru ze správně pojmenovaného souboru na mass storage zařízení strčeného do správného USB portu.

[xkucf03]

A už to konečně funguje? Na jedné starší desce (taky Asus) jsem měl taky takový jumper, ale když jsem si rozbil BIOS (špatně naflashovaný) tak tahle funkce nic nedělala (asi byla implementovaná v BIOSu, který byl teď rozbitý) a musel jsem čip přendat do jiné desky a přeflashovat tam.

[petr_p]

Nezkoušel jsem to.

[pc2005]

Co jsem zkoušel, tak u AMI ten kód býval dost slabej (řešení s disketou). Ono nacpat inicializaci disketového řadiče, parser FAT, flashovací rutinu ve flat módu do prvního sektoru na flash čipu je dost lahůdka (musím se přiznat, že jsem doteď neudělal driver na FDD v assembleru bez OS/BIOS funkcí :-/ ).

Když jsem si rozbil BIOS na hlavním počítači, tak se o flashování systém pokoušel (disketovka něco četla), ale nikdy se to nepovedlo. Jiný AMI BIOS co jsem dissasembloval měl ve flashovací rutině dokonce detekci čipu, takže fungoval jen na určité množině flash pamětí (každý výrobce a každý čip má odchylky v sekvenci, která spouští například výmaz paměti).

BTW pokud jsi ten BIOS flashoval včetně bootblocku, tak mohlo to poškození být i v něm.

[pc2005]

A bez toho jumperu se to nenaflashuje? To asi ne, to by pak nešlo vzdáleně updatovat UEFI servery (třeba v případě úniku privátního klíče ).

Jinak existenci selfflashe bych bral jako povinnost i pokud to není ve standardu UEFI (z USB umí flashovat i spousta BIOSů).

[petr_p]

Za normálních okolností máš funkční klikátko coby UEFI aplikaci. (Z toho titulu se bojím, jak velké poškození firmware zvládne, protože ovladač USB, mass-storage a tak dále bude o něco složitější, než ovládání disketové mechaniky. Na druhou stranu jsem zkoušel přes UEFI kopírovat z USB flash na SATA disk a bylo to zatraceně pomalé, takže asi je to jednoduché jak jen možno.)

[Grunt]

Naprosto stejný argument jako že otevřením operačního systému otevřeme bránu rovnou jádra samotného systému.

[dustin]

Byla to jenom otázka času, než se to začne sypat. Uměle překomplikovaná řešení obvykle dlouho nepřežijí.

[pc2005]

; Description:  OSYS object is used to detect the currently running OS
; Input: Nothing
; Output: OS type
; running under 0x01 - Linux
;               0x02..0x0F - reserved for other non-windows OS
;       0x10 - Win 98/Se
;               0x11 - Win Me
;               0x12 - Win 2000 or above
;               0x13 - Win XP
;               0x14 - Win server 2003
;               0x15 - Win Vista
;       0x16 - Windows 7
;               0x16..n - reserved for Windows OS

↑ Si věřej...

[pocitujlasku]

mna skor pobavilo to rozdelenie Linux - jedna moznost a potom x-verzii Windows :)

[luky]

Alespon je linux jednicka ;)

[Sten]

No co, v Linuxu to všechno nějak funguje, ve Windows je potřeba to pro každou verzi patřičně upravit

[Ivan]

Ono je to tak, ze s kazdou novejsi verzi MS pouziva vice a vice ze standartu ACPI. Musim uznat ze to maji v MS velice dobre zdokumentovane a ze je pak jasne co od HW vendoru ocekavaji. On ten MS uz zdaleka neni tak uzavreny jako byval.

Ten pristup, ktery zvolili neni uplne nesmyslny. Zakladni ACPI specifikace bez rozsireni ma neco okolo 600 stran. Tezko se da predpokladat, ze to implementuji vsichni bezchybne uplne napoprve.

PS: na druhou stranu ale pro nekoho plati: "Wokna to nepotrebuji - nemusi to fungovat vubec".

[Ivan]

PS: kde jsou ty casy kdy takovyhle "uniky" byly celkem normalni a na anonymnich FTP serverech vendoru se daly najit HW specifikace, nekdy i se zdrojakama ovladacu pro wokna.

[_]

ta doba stale trva u nekterych vyrobcu/dodavatelu se nic nezmenilo a ani nezmeni.

[little.owl]

Musim uznat ze to maji v MS velice dobre zdokumentovane a ze je pak jasne co od HW vendoru ocekavaji.

Tak, totez plati i u pozadavku na UEFI. Tady v tom naopak Linux velmi plave a byt vyrobce HW nevim poradne co u nej implementovat, protoze plnou podporu UEFI podle standardu nema ani nahodou.

[houba]

Mozna to nebude tak horky

Per AMI, the signing key included in the ‘Ivy Bridge’ archive is a default test key; AMI instructs customers to change the key before building for a production environment. It’s not currently known if the customer was following recommended practices. ... Assuming the vendor was following AMI’s instructions, the private key found on the vendor’s public FTP server should have little practical value; though how this vendor was handling keys isn’t known, so the usefulness of the key is also unknown. There is also the possibility of other AMI customers violating AMI’s instructions.

[pc2005]

To stačí jen zkompilovat podepsaný tímhle dummy klíčem a otestovat zda nabootuje win8 ne? Stejně by malware zneužívající únik tohodle klíče fungoval jen na kompech s tímhle UEFI (doufám teda).