Security on davidzou.com

BIOS Password Bypass

Mon, 28 Mar 2016 00:00:00 +0000

BIOS Administrator/Supervisor Password Bypass/Removal

These instructions are provided without warranty. Use at own risk.
Please be careful when playing with hardware. You can easily break or damage components.

This guide will run through bypassing and changing/removing a BIOS password. This guide can also bypass the supervisor password prompt which occurs when the incorrect password has been entered too may times, resulting in the message “System Security - Security password retry count exceeded”. This guide will use Lenovo BIOS and UEFI as examples.

The rough steps you will need to take are:

Disassemble your device
Locate the EEPROM chip on the mainboard
Find a datasheet for your EEPROM chip and/or locate the SLC and SDA pins
Short the SCL and SDA pins while the BIOS checks the password
Change/remove the password

Step 1: Disassemble

Start by removing the back cover of your laptop. Chances are that you won’t find the EEPROM behind the exposed parts behind the back cover. You will probably need to remove the entire back/base of the laptop or even get to the other side of the mainboard. Most Lenovo laptops have the EEPROM on the other side of the mainboard (the keyboard side).

Step 2: Locate the EEPROM

You are looking for an 8-pin Serial EEPROM chip, though it can come in a 5 pin SOT-23 package. To confirm what chip you have, simply read the characters off the chip and Google it. One with results for a serial EEPROM would indicate the correct chip. Due to the small packages of these chips, the characters marked on the chip may not be the model number of the chip and may be an abbreviation. Also, if you find results for serial flash chips with a capacity of a few hundred K (Kilobits) or a few M (Megabits), chances are that you have found the chip the Embedded Controller or BIOS/UEFI is stored in. Keep looking!

Step 3: Find a datasheet and/or locate the SLC and SDA pins

On most 8-pin packages, the SDA and SCL pins are on pins 5 and 6 respectively. Pin 1 can be identified by the dot/circle etched next to it (some packages may have a semicircle etched on the edge between pins 1 and 8) and the pins are numbered anticlockwise.

Step 4: Ensure the BIOS reads `NULL` from the EEPROM when checking the password

The BIOS communicates with the serial EEPROM through a bus called I²C. The serial clock and data pins are open-drain and are grounded in a specific order for communication to occur. We want to ensure that the only data that gets read out is NULL. This should fool the BIOS into thinking there is no password set.

We can conveniently tie both the SCL and SDA pins together in order to achieve what we want. Note that tying SCL or SDA to Ground or Vcc will cause the BIOS to hang, as transitions between low and high are part of the I²C protocol.

We can simply short the SCL and SDA pins together with a conductor such as a flat head screwdriver or a paperclip.

The procedure seems to be slightly different for BIOS and UEFI systems. BIOS based systems seem to read the password from the EEPROM after the user pushes the ENTER key after entering the password, while UEFI based systems seem to read all the configuration required from EEPROM into memory right after the power is turned on. BIOS based systems will be the easiest to bypass, while UEFI based systems may require a few goes before you succeed.

You can determine whether your system is BIOS or UEFI based by checking specifications or the user manual to see if it supports UEFI boot. You can also enter the BIOS/UEFI setup in read-only mode by using an empty password. If the “Boot” menu mentions “UEFI”, then you have a UEFI based system, otherwise you have Legacy BIOS.

Chances are you have removed the keyboard to get to the EEPROM chip. As some of the steps require the use of a keyboard, you may wish to plug a USB keyboard in to use. Otherwise you’ll need to awkwardly poke and prod underneath the keyboard.

BIOS based procedure

Turn on the device
Press F1 repeatedly to enter BIOS setup and get the password prompt
Short SDA and SCL pins and keep it shorted.
Press ENTER on the keyboard and then un-short the two pins. You should get an OK prompt. If you get a notice BIOS setup is locked. Only the System Supervisor can make changes, then you have not shorted the two pins successfully. Restart the computer and try again.
Navigate to the Security menu > Password menu
Highlight the Supervisor Password option
Short the SDA and SCL pins again and keep it shorted
Press ENTER on the keyboard and then un-short the two pins. You should get a prompt for a New Password and Confirm New Password. If you get a prompt for the Current Password, close the menu and try again.
Enter any password you want to set, or leave it blank for no password.
After confirming the password, press F10 to save changes.
If you are trying to remove the the “Security password retry count exceeded” message, you must load default settings by pressing F9 and save with F10. This does not affect passwords.

UEFI based procedure

Turn on the device
As soon as the backlight of the screen turns on, short SDA and SCL pins and keep it shorted.
Press F1 repeatedly to enter BIOS setup. You should be taken directly into the BIOS setup. Un-short the two pins. If you are shown a password prompt, switch the device off and try again.
Navigate to the Security menu > Password menu and set a Supervisor Password
After confirming the password, press F10 to save changes.
If you are trying to remove the the “Security password retry count exceeded” message, you must load default settings by pressing F9 and save with F10. This does not affect passwords.

DER Laptop BIOS Unlock

Mon, 28 Mar 2016 00:00:00 +0000

The DER (Digital Education Revolution) lasted 5 years starting in 2009, with the last generation of laptops handed out in 2013.

The first two models were pretty rubbish laptops. They had tiny screens and the S10e had unacceptably small keys. All models except the X131e had an SSD, and the DET SOE image was horrendously slow. They had a plethora amount of software installed and they didn’t make much of an effort to prevent useless services and startup entries. The login process was unbearable… at least for me (I’ve been made impatient thanks to SSDs).

Year	Model	Machine Type	Storage
2009	IdeaPad S10e	4333	160GB HDD
2010	ThinkPad Mini 10	3507	160GB HDD
2011	ThinkPad Edge 11	0328	160GB HDD
2012	ThinkPad X130e	2338	320GB HDD
2013	ThinkPad X131e	3367	120GB SSD

The laptops have a BIOS supervisor password and was locked until the owner of the laptop finished year 12 or the school uses it as a T4L device. The BIOS was configured to boot from the internal HDD only. When a student finishes year 12, the laptops are It’s the school’s decision who gets to keep the laptop after year 12, but most schools allowed students to keep the laptops unless they didn’t want it. When a student is graduating, a new entry should show up in SCCM to Unlock the BIOS and image the laptop to a clean install of Windows 7.

The DET have recently been decommissioning DER related servers/services and lately there have been problems with the SCCM. There have been imaging DER laptops and joining the DETNSW domain. Seeing as this year’s year 12 have last generation of DER laptops and the DER program is pretty much non-existent, I would show the procedure to unlock the BIOS, for any people who still have a locked BIOS and have physical access to the internals of the laptop.

For all the IT people who work with these DER laptops, you can actually obtain the BIOS unlock binaries from the SCCM after starting the DER Grad Unlock. The SCCM will create some folders in the system drive while it performs the unlock. You can suspend the SCCM process using Sysinternals Process Explorer after it starts and downloads the required files. You can then spend all the time you need to obtain the required permissions to access the files and make a copy. If you want a copy of the files, shoot me an email to my det nsw email account. You can find me on SMU by searching for my last name (the entry that has a Business Telephone No. ending in 1).

I have already written an article explaining how to bypass the supervisor password if are able to disassemble the laptop. In this post, I will provide a guide to disassembling the last three generations of DER laptops and removing the supervisor password.

The above-mentioned article is available here.

Required Tools

Torx T6 screwdriver
Philips #1 screwdriver

Recommended Tools

USB keyboard
Spudger or fingernails

Lenovo Edge 11 (0328)

Disassembly

Remove the back cover by unscrewing the three torx screws
Remove the battery pack and then remove the two large flat Phillips screws holing the keyboard.
Remove the HDD by removing the two M2x7 screws and sliding it out
Remove the keyboard by pushing it up and out though the HDD bay. The keyboard is attached by two flat flex cables. The larger connector can be unlocked by sliding the black ends of the connector towards the trackpad. The smaller connector has a locking lever which can be pried up with a fingernail or tweezers.
Disconnect the two flat flex cables from the mainboard in a similar manner to the smaller connector on the keyboard. One is for the trackpad and one for the power switch).
Disconnect the microphone from the mainboard by sliding the black part of the connector towards the right. (The connector is located under the bottom left corner of the keyboard.
Remove the three M2x7 screws exposed after removing the keyboard
Remove the part of the chassis which consists of the palm rest, trackpad and power button by using a spudger or running fingernails between the main chassis and the palm rest. This part is held together with small plastic hooks running around the chassis. Apply a little force to unhook them.

Locating the EEPROM Chip

The EEPROM chip is located to the right of the speaker connector. It should be a chip labelled L08 but could labelled PS08A or be a different chip.

Other Information

The Edge 11 runs a Legacy BIOS. Follow the procedure for BIOS based systems.

The SDA and SCL pins are the two above the number 8 of the label (the opposite corner of the dot/circle marker).

As the power button is located on the part of the chassis which is removed, you will lose the functionality of the power button. You can still simulate a press of the button by shorting the pins that lead to the power button. The pins for the power button are the first two pins (from the left) of connector CN2.

Be extremely careful when shorting these pins. Shorting pins other than the first two will result in you damaging the power management chip and your device will have problems powering off!

Lenovo X130e (2338) and X131e (3367)

Disassembly

Remove the back cover by unscrewing the three torx screws
Remove the HDD/SSD by removing the two M2x7 screws and sliding it out
Remove four M2x8 screws holding chassis and keyboard
Remove the two M2.5x5 screws to the left and right of the battery pack
Slide entire keyboard up towards the battery and then lift up from the bottom
Disconnect the two flat flex cables (for the keyboard and TrackPoint) from their connectors by levering the front part of the connector up.
Disconnect the flat flex cables from the mainboard in a similar manner to the ones on the keyboard.
Disconnect the microphone by sliding the connector towards the right
Remove the three M2x5 screws exposed after removing the keyboard
Remove the part of the chassis which consists of the palm rest and trackpad by using a spudger or running fingernails between the main chassis and the palm rest. This part is held together with small plastic hooks running around the chassis. Apply a little force to unhook them.
Remove the piece of black plastic around the microphone connector (to the right of the USB ports on the left hand side) as the EEPROM is located underneath.

Locating the EEPROM Chip

The EEPROM chip is located just below the microphone connector. I have seen two chips used for the EEPROM. It should be a chip labelled L08 or PS08A but could be a different chip.

Other Information

The X130e and X131e run UEFI. Follow the procedure for UEFI based systems.

The SDA and SCL pins are the two above the number 8 of the L08 label or the 8A of the PS08A label (the opposite corner of the dot/circle marker).

NFC Security - Armourcard Active Jammer

Mon, 14 Mar 2016 00:00:00 +0000

NFC is becoming the de facto standard for contact-less systems. For the convenience, we are potentially giving up some privacy and security.

Contactless payment technologies such as Mastercard Paypass and Visa Paywave are designed for maximum flexibility for merchants, not maximum security for customers. Some merchants may choose to have transactions processed immediately, while others may choose to process them in batch after hours. Whatever the reasons, the designers of the protocol have chosen to make the following information readable in plaintext through NFC.

Card Number (First four digits indicate the type of card)
Expiry
Date and amounts of the last 10 transactions

With this information, credit card fraud can be commited. You may think that without a full name and CVV (the security number also know as the CVC or CVV2) you cannot process a transaction, however, the only number required to process a transaction is the card number. Merchants are able to pay higher processing fees to allow transactions without extra information such as the expiry and CVV. Amazon is a famous merchant that allows transactions without the security code.

Granted, you are covered if money is stolen from your account, however you need to actively check your transactions regularly for fraudulent transactions to report. This can be time consuming and difficult if you have to verify each and every transaction.

Sydney public transport users using the Opal card can provide the following information through NFC:

Card number
Card Balance
Last tap details
- Transport type
- Tap on/off
- Time and Date
Number of journeys used in the last week the card was last used
If Auto Top-Up is enabled

The information mentioned can be viewed easily with the Credit Card Reader and Opal Travel apps. To obtain the information, any NFC reader can be used.

To protect myself, I have been using an Eagle Creek RFID International wallet for the last two years. These types of RFID shielding contraptions are usually lined with a layer of foil to shield the magnetic fields emitted by NFC/RFID readers.

NFC/RFID communications work by the reader sending out a magnetic field and inducing it into the NFC/RFID card, which gets power through inductive coupling. The card then provides feedback to the magnetic pulses by loading down its antenna coil. The NFC/RFID reader is able to detect the card loading down the coils, and thus can read information back from the card.

The issue with passive shielding is that given a powerful enough magnetic field, you can still induce power though the shielding material. I recently got access to a more powerful RFID reader and was able to read a card though the RFID shielding wallet.

Just last week, I stumbled upon the Armourcard active jammer. The Armourcard is a jamming device as opposed to the more common shielding material. This means that there is circuitry inside the card which detects RFID/NFC signals emitted by a reader and emits its own scrambled signal to interfere with communications.

The Armourcard is credit card sized and is constructed from a double layer PCB with black solder mask. It is approximately 0.8mm thick (as thick as a credit card) around the edges and approximately 3mm thick at the bulge (the white parts of the card). The front side contains two LEDs and exposed traces that act as a touch sensitive button.

The back side holds the traces which act as the antenna coil.

The red LED flashes when the card is actively jamming a signal. The button on the front size is used to disable the jamming temporarily and to test the battery. The green LED will flash while the button is touched. As it has active circuitry inside, the Armourcard has a limited lifetime which is claimed to be approximately two years.

With the low powered NFC reader in my Xperia Z1c, the jamming LED starts flashing when the phones is 6cm away from the Armourcard. In comparison, the phone is only able to read a card when it is 3cm away from the phone. This instils some confidence as the Armourcard will always engage before the reader is able to read a card. With the Armourcard anywhere near a card, the NFC/RFID reader will fail to detect a card present.

DETNSW SSO Authentication: Convenience vs. Security

Sat, 27 Feb 2016 00:00:00 +0000

While writing the DER Batch Reset Tool, I was forced to investigate how the DETNSW handles its SSO. The original plan was just to obtain a session cookie from the browser and use the cookie in the reset tool, but it was rather tedious copying a cookie every few minutes while coding up the script. The batch reset tool uses the Python requests module, which has session support to store cookies between requests.

The DETNSW SSO server is probably somewhere around a decade old, as I remember using the same system as a student when I first started high school. The one thing that has changed is that one less set of credentials is required when using one of the DETNSW’s services such as the student/staff portal.

All the computers connected to the DETNSW’s network are part of a state-wide intranet in the 10.x.x.x Class A network. Direct connections to the internet are filtered, thus all internet traffic must go through the department HTTP proxy proxy.det.nsw.edu.au:8080 with the exception of some licensing and update servers. The proxy is an HTTP proxy with Basic authentication (through HTTP headers of the first connection). They have no support for HTTPS proxy.

Initially, to visit the student/staff portal, one would need to enter their username and password for the proxy authentication and then again on the SSO login page. However, some years later, the SSO login page got replaced with a page which seems to automatically authenticate users based on the proxy authentication. One can only assume this was done because staff complained about having to enter their credentials twice if they just opened a browser and want to visit a DETNSW site.

When requesting a DETNSW site, you get redirected to this non-secure URL, where some magic happens and you are automatically authenticated. Is this yet another page for details to leak?

And here is the page itself. Looks like an innocent enough form and it POSTs to a secure site! Do we have some actual security?

<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Portal Login</title>
        <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"/>
        <meta name="author" content="Andy {REDACTED}"/>
    </head>
    <script type="text/javascript" src="../jfunctions.js"/></script>
    <body onload="javascript: submit_form();">
        <br/><br/><br/>
        <p>
            <h2 align="center">Please wait while you are being logged into the DET Enterprise Portal...</h2>
        </p>
        <form name='loginform' method='post' action='https://sso.det.nsw.edu.au/sso/UI/Login?goto=...' >
            <input type="hidden" name="ssoDetails" value="dXNlcm5hbWU=:cGFzc3dvcmQ=">                     
            <input type="hidden" name="site2pstoretoken" value="">
            <input type="hidden" name="ssousername" value="">
            <input type="hidden" name="password" value=""> 
            <input type="hidden" name="IDToken1" value=""> <!-- BA for openam -->
            <input type="hidden" name="IDToken2" value=""> <!-- BA for openam -->           
        </form>
    </body>
</html>

Oddly enough, if you POST all the details shown here using the Python requests module, it doesn’t authenticate the user and redirects you to the sign in page to enter your credentials. So what’s the difference between the browser and Python requests?

JavaScript. They must be using JS to do more than just submit the form automatically. The hidden value ssoDetails is already part of the form but looks suspiciously like base64. What could they possibly be doing?

var base64Chars = new Array(
        'A','B','C','D','E','F','G','H',
        'I','J','K','L','M','N','O','P',
        'Q','R','S','T','U','V','W','X',
        'Y','Z','a','b','c','d','e','f',
        'g','h','i','j','k','l','m','n',
        'o','p','q','r','s','t','u','v',
        'w','x','y','z','0','1','2','3',
        '4','5','6','7','8','9','+','/'
        );

...

function submit_form() {
    var details = document.forms['loginform'].elements['ssoDetails'].value;
    var details_array=details.split(":");
    document.forms['loginform'].elements['ssousername'].value = db(details_array[0]);
    document.forms['loginform'].elements['password'].value = db(details_array[1]);
    document.forms['loginform'].elements['IDToken1'].value = db(details_array[0]); // for openam
    document.forms['loginform'].elements['IDToken2'].value = db(details_array[1]); // for openam
    document.forms['loginform'].submit();
}

Surprise surprise… base64. (The entire JS file is available here). It looks like they have implemented base64, probably for IE users as IE only had base64 JS functions from version 10 onwards.

And at first glance, it’s evident they are populating the form with details from the ssoDetails form value. This means the DETNSW servers have an un-hashed copy of everyone’s password stored somewhere on a server and is willing to send out a base64 encoded version of it through an unencrypted connection.

It’s understandable that they need to store a plaintext password, as the department has countless numbers of systems to integrate and some of them are ancient. What’s not understandable is why the SSO server must take a username and password. Surely they could have programmed the SSO server to talk to the proxy authentication server and use a token of some sort.

So now, we don’t even need Wireshark to steal a password, we just need to get the target user to authenticate the proxy connection.

Taking a further look at the response headers for that page which returns us the username and password, we can see it doesn’t even disable caching.

Ideally, the server should set the following headers:

1
2
3

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

We can just trawl through the browser’s cache and extract the details. So now we don’t even need the user to authenticate on the spot!

Fortunately, if you haven’t been active on a DETNSW site for a few minutes, they will invalidate your session and prompt you to log in manually. Okay, so what if the cache entry has been overwritten due to newer content and the user has been logged in previously (more than a few minutes ago) in this browser session?

The solution is 3 key strokes and some clicks away. And since the SSO server doesn’t talk to the proxy authentication server, you are treated as if you had just opened the browser and will be handed the account password. So this security timeout feature is essentially useless. Due to limitations of the HTTP proxy authentication, there is no proper way for the proxy server to know when a user entered their credentials into the browser (since the browser keeps a copy of the credentials in memory and uses it automatically every time a new connection is made).

In summary

Proxy is HTTP where the password is sent in plaintext (base64 encoded)
User credentials are stored in plaintext (un-hashed)
User credentials are sent to the user to process the login
User credentials are not protected with TLS
User credentials are allowed to be cached in the browser’s cache
SSO auto-login server can’t determine how long since a user authenticated with the proxy

I’ll give Andy the benefit of the doubt and assume he didn’t really have a choice when he implemented this auto-login. I’m sure someone has signed off on his work knowing exactly how bad the security is.

The good news is that DETNSW is planning to move to NTLM-authentication. This is fine for devices part of the DETNSW domain and using Internet Explorer, any other browser/device will still be required to enter a username and password. The bad news is that NTLM is really broken, as it is vulnerable to MITM and pass-the-hash attacks. Even with these vulnerabilities, it is still way more secure than plaintext passwords. Hopefully they add support for HTTPS proxy for non-domain computers.

Security on davidzou.com

BIOS Password Bypass

Step 1: Disassemble

Step 2: Locate the EEPROM

Step 3: Find a datasheet and/or locate the SLC and SDA pins

Step 4: Ensure the BIOS reads NULL from the EEPROM when checking the password

BIOS based procedure

UEFI based procedure

DER Laptop BIOS Unlock

Required Tools

Recommended Tools

Lenovo Edge 11 (0328)

Disassembly

Locating the EEPROM Chip

Other Information

Lenovo X130e (2338) and X131e (3367)

Disassembly

Locating the EEPROM Chip

Other Information

NFC Security - Armourcard Active Jammer

DETNSW SSO Authentication: Convenience vs. Security

In summary

Step 4: Ensure the BIOS reads `NULL` from the EEPROM when checking the password