
AMI-Bios Sourcecode and UEFI Signing Key leaked? - mablae
http://adamcaudill.com/2013/04/04/security-done-wrong-leaky-ftp-server/
======
cnvogel
I admit that I have no idea at all about all that UEFI signing stuff, but the
only thing in the "Keys" directory that does _not_ look completely like random
data is this, and "DO NOT TRUST - AMI Test PK0" looks more like something I'd
distribute among my development team for testing, but would definitely not be
the _real_ thing:

$ strings Ivy_Bridge_018s/Keys/Variables/db

4}7Ve 0%1#0! DO NOT SHIP - AMI Test KEK0 110823215243Z 120823215242Z0%1#0! DO
NOT SHIP - AMI Test KEK0 (...)

$ strings Ivy_Bridge_018s/Keys/Variables/KEK

4}7Ve 0%1#0! DO NOT TRUST - AMI Test PK0 110823215221Z 120823215220Z0%1#0! DO
NOT TRUST - AMI Test PK0 (...)

$ strings Ivy_Bridge_018s/Keys/Variables/dbx

4}7Ve 0.1,0* #DO NOT SHIP - Microsoft Test KEK CA0 110506224835Z
121106224834Z0+1)0' DO NOT SHIP - Microsoft Test KEK0 (...)

$ strings Ivy_Bridge_018s/Keys/Variables/PK

4}7Ve 0%1#0! DO NOT TRUST - AMI Test PK0 110823215221Z 120823215220Z0%1#0! DO
NOT TRUST - AMI Test PK0 )MCn D5g( (...)

~~~
qb45
Asymmetric keys _do_ look like lots of completely random data. What you've
found is likely some kind of fingerprints (hashes).

If there are indeed some keys on this server they could be real, after all
this code wasn't supposed to ever go public.

~~~
cnvogel
Yes, but you'd expect the key (Keys/FW/.priKey) to be accompanied by some
useful metadata (naming the entity the key belongs to, and a certificate from
microsoft validating the key) to be added to the firmware image, wouldn't you?
And if there's only certificates containing "DO NOT USE" text?

But certainly, I have no idea about all that. If someone could post commands
how to verify (or at least dump) connection between DER encoded RSA keys and
the PK/KEK/db/dbx files (which seem to have a 40byte header, then, again DER
data)... that could shed some additional light on these matters.

~~~
mjg59
There'd be no reason to expect the firmware signing key to have any relation
to any of the certificates used in Secure Boot. They're used for separate
purposes.

------
KwanEsq
>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.

><http://adamcaudill.com/files/Screenshot_4_4_13_10_04_PM.png>

>References in the files indicate that the code is from sometime in February -
so this is current code.

Given that that image shows dates in 2012, I think the author has made the
classic mistake many of us make at the start of the new year, of still
thinking it's the old one.

~~~
miahi
For firmware, 2012 is actually very new. I don't think manufacturers change
the versions too often, even on firmware updates - they usually maintain/patch
the original firmware (the version that was used when the hardware launched).
A motherboard released in 2012 probably has an older version of firmware than
the leaked one.

~~~
mjg59
Microsoft's requirements for Windows 8 certified firmware continued changing
until surprisingly far through 2012. Code from early 2012 wouldn't satisfy it.

------
qb45
I don't see how BIOS signing could be really that important.

BIOS flash must be write protected in silicon before the OS boots to prevent
flashing by pwned kernel or drivers so we can assume that only BIOS setup
application can touch BIOS flash. Flashing inside BIOS setup application can
be prevented by password. And if somebody has physical access to the
motherboard to reset this password it's game over anyway.

Call me when somebody leaks something interesting or useful like the Secure
Boot private key of Microsoft.

~~~
zdw
Usually there isn't much protection, if you have root on a system.

On an infrequent basis I've used Flashrom (<http://www.flashrom.org>) to burn
new system BIOS's into flash on a running Linux system. Much easier than
fiddling with DOS boot disks, etc. Thus, anyone who can exploit to root could
theoretically reflash the BIOS in a system with code that would be persistent
through OS reinstallations. Personally, I'd focus on the PXE ROM if asked to
compromise systems in this way.

Some older systems have jumpers on board that can write protect the BIOS, but
frequently they either default to being in the writable state. I haven't
noticed these jumpers on modern PC hardware for a while.

This isn't unique to UEFI Secure Boot systems - I'd assume once you're in OS,
all bets are off in terms of who can do what to the hardware.

~~~
aortega
>I'd assume once you're in OS, all bets are off in terms of who can do what to
the hardware.

A common misconception. Even if you are running as ring-0, there are things
that you cannot do, and only BIOS can. For example, executing code in SMM
mode, mapping/hiding portions of memory, or changing some PCI configuration
options that get "locked" after BIOS.

~~~
zdw
Sounds like a chicken/egg scenario if you're able to reflash the BIOS
arbitrarily.

------
noja
Source appears to be ftp://fxp.jetway.com.tw/CODE/

~~~
gokhan
_"You have logged in for maximum times. Connection closed."_

Coming to your favorite torrent tracker soon.

~~~
christina_b
Now it has a password. Oh dear, I'm depressed I've missed out on this. The FTP
server appeared to have quite a few interesting things on it (for example, a
folder called "Samsung ARM").

~~~
quasque
Anonymous ftp still works, it's just hitting the maximum connected user limit.
Better to use an FTP client than the browser as it will persist the
connection.

------
gcb0
from the article: "This kind of leak is a dream come true for advanced
corporate espionage or intelligence operations."

i disagree. this is banal stuff for "corporate espionage or intelligence".
they have that and more for ages. no data that has a price is private.

what is interesting is that we could now have a decent open sourced BIOS
implementation. ...Maybe if someone in china or other country with less
software copyright starts the project we all can contribute?

~~~
kannanmr
This is not the first BIOS source to leak (Award BIOS 6 code leaked 10 yrs
ago, am sure still available in your fav torrent tracker). Opensource code
will certainly not make use of this leaked implementation, it is asking for
trouble.

~~~
marshray
IBM published a technical reference manual for the PC which included (among
other things) a complete commented source code listing of the BIOS.

------
hp50g
Anything which involves a company rather than an individual keeping a secret
is a crock of shit as far as security goes.

------
mjg59
The story's been updated with information from AMI - it sounds like the keys
are only intended to be used for testing purposes and should be changed before
use, but it's obviously possible for vendors to ignore that advice.

------
toysoft
[http://torentilo.com/download/8748214/AMI-Firmware-Source-
Co...](http://torentilo.com/download/8748214/AMI-Firmware-Source-Code.html)

Torrent...

------
toysoft
Someone has pass ?

<http://www.mmnt.net/db/0/0/www.jetway.com.tw>

