Recently I’ve done some harmless trolling. I’ve opened a PR to SecList to remove “my password”, “dolphins”, from all of the common passwords lists. Or in simple English, there is a public list on the internet of the most common passwords people use and I’ve asked them to remove the password “dolphins” from all lists so hackers won’t be able to hack my account. Of course this is ridiculous, and that’s why it’s funny :)
Anyhow, the post got more attention than expected
Most surprisingly, on the recent Meltdown paper at https://meltdownattack.com/meltdown.pdf there is an example of stealing browser passwords, and one of the passwords is "Dolphins", I wonder whether it's a strange coincidence or that the author was impressed with my PR.
I would like to explain here how I got to this silly idea. From time to time, I get to consult developers and admins about security. Whenever we talk about passwords I have a few guidelines such as, use 2FA everywhere.I always advise to check if the password is found on any of the lists of SecLists GitHub project. Clearly, if you find your password there it's not a good enough password.
Recently I’ve found myself guiding a SysAdmin that didn’t seem like the brightest tree in the forest. As a security researcher that got me thinking, again, what could go wrong. When I imagined that person might try to solve his problem by attempting to remove the password from the lists, instead of changing it, I thought it’s so hilarious, I must do it.
Apparently, GitHub users liked it too, and got too many comments. Sometimes when I try to load the comments page of the PR I get:
All of the research presented in this paper was done by me and two coworkers who preferred to stay anonymous, I write everything as if I did it by myself for clarity and fluency.
To understand what a Kosher phone is, one must first understand what a feature phone (aka dumb phone) is. A feature phone is a phone that is usually sold for a very cheap price (up to 50$) and it lets the proud owner do the following things:
Make phone calls
Send SMS
Send MMS
Manage a calendar
Listen to FM Radio
Play simple games such as Snake
Browse the internet over GPRS or 3G using a dis-functional web browser.
Bluetooth communication
Play ringtones
Display ugly images as wallpapers
Take photos using ~2MPixel camera
Some utilities such as world clock, unit converter and calc
While recently some devices also include:
Limited Facebook app
Twitter app
WhatsApp
A Kosher phone would be an adapted feature phone to the “special” needs of a certain community of the Ultra Orthodox Jews. The community in target asked for a phone that is more dumb than the dumb phone, a phone that suffers from complete retardation. The general idea is that they don’t want to be open to the outside world in any way, but they still want a means to communicate between themselves without breaking the strict boundaries they made. They were looking for phones that can only perform the following tasks:
Make phone calls
Manage a calendar
Bluetooth only with headphones
Play only a strict list of Hasidic ringtones.
Some utilities such as unit converter and calc
Besides that, they would be extra happy if they could have:
Jewish calendar
Prayers time table
A disclaimer: No one forces this phone on them, they choose to have it on their own will. No government or agency is involved in this, and the only mean of force that drive the people to use this kind of phone is the community they live in.
I choose for start a Nokia phone, as they are considered cost effective for hardware quality and stability. From Nokia I got an approval for the project, but no help whatsoever. They said, I’m welcome to do whatever helps me sell their phones, but this target group is too small for them to put any developing time on it. This is how the journey for the Kosher phone has started.
During my journey I had the pleasure of co-developing of 5 generations of the Kosher phone:
Nokia 1208
Nokia 2680
Nokia 2720
Samsung E1195
Nokia 208.4
There were a few models in between that didn't get to the final stage either because I failed in making a Kosher firmware for them or because of other reasons that are out of my control.
I won’t describe all of the tricks I've used during the development, because:
These phones still make a nice income that I would not want anyone to take away.
Not all of it is mine to share.
However, I think the time has come for me to share some of the knowledge I've collected during this project.
It would be too long to cover all of the phones in a single post, so I will start with just one of them, and just a single part that I find most interesting.
Nokia has quite a few series of phones differ in the firmware structure and firmware protection. The main purposes of the protections are to:
Make it hard for people to play with Baseband firmware and harm the GSM network
Protect the SIM-lock feature which locks the phone to sim cards from only one provider (Something that became illegal in some countries such as Italy and Israel).
The series are the following categories:
DCT1 (Digital Core Technology / Data Cellular Technology)
DCT3
DCT4
DCT4+
BB5 (Base band 5)
Asha S40 (AKA xGold 213)
In general the DCT1 works with the old analog networks (Usually refer to as 1G), DCT3, DCT4 and DCT4+ works with GSM (2G). BB5 is sometimes 2G and sometimes 3G (I think). And anything that comes after being 3G compliant. It is important to understand the fact that there are different generations of phones because a way to fiddle with the firmware of a phone from one series would usually work with all of the other phones on the same series, while it won’t work with phones from other series.
I’ll start with the DCT4+ phone, the Nokia 1208. Nowadays there are quite a few people out there who know how to patch DCT4+ firmware, but the solution is still not out in the open. One would have to collect lots of small pieces of information from many forum posts in order to get a full solution… Well, not anymore, because I’m going to present here the solution in all of its glory.
A DCT4+ firmware consists of two parts, a flashable part and a non flashable secured part (probably ROM). The flashable part contains the:
OS, usually referred to as the MCUSW.
Strings and localization strings, usually referred to as the PPM
General purpose file system in a FAT16 format. This part contains configuration files, user files, pictures, ringtones, and more. This is where Nokia pushes the phone provider variations. This part is much less protected. It's usually referred to as the CNT or IMAGE.
All of this data is accessible from the software in one flat memory module, meaning that codes that runs on the device can access almost anything that it know where to locate.
At this point I would focus on the OS part, in an attempt to patch it to make the phone Kosher. The OS contains 99% of the code that operates the phone, that's including the implementation of user interface, menus, web browser, SMS managing, communication and anything else the phone does. The only things that are not part of the OS are the code for performing the flashing, the code for protecting the flash and some of the BaseBand these are all found in the ROM part, beside that only 3ed party apps such as games are located outside of the OS, in the CNT part.
Obtaining the binary is not hard, it’s simply available for download from many websites, and from Nokia servers accessible by the Nokia flashing tool Phoenix or by the NaviFirm+ tool. The MCU part (meaning the OS part) comes in the form of a file with the .mcu or .mcusw (MicroController Unit SoftWare) extension.
It starts with the constant byte 0xA2 that marks the version of the file. The file has quite a simple format. From offset 0xe6 everything that follows is encoded as:
1 Byte: Type (Always 0x14)
1 Dword: Address
3 Bytes: Length
1 Byte: Unknown
1 Byte: Xor checksum
Combining all of the data chunks would give us something that starts at address 0x1000000 with the following data:
Note that some of the 0xff bytes are just missing data because of the way it is encoded. The first data chunk belongs to address 0x1000000 but it’s just 0x2c bytes long and the next data chunk starts at 0x1000064. The binary that follows byte 0x1000084 is encrypted, and is auto decrypted by hardware. I know that this is done at the hardware level because:
I can see what bytes are actually sent to the phone during flashing, and
There are few places in memory such as the bytes from 0x1000000 to 0x1000084 that are not encrypted. After I’ll manage to open the encryption I would find that In some places in the code these bytes are accessed simply by adding 0x8000000 (I’m not missing a zero) to the address, which is a flag to the CPU that says that this data is not encrypted, so don’t decrypt it.
Now an interesting question that comes next is what is the encryption, and how can I reverse it to patch the code. My answer is going to be quite disappointing, I found out what encryption is it by gluing pieces of information that are published on the Internet. If you want to know how the guys on the Internet found what it is, remember that I want to know it too. My guesses are either:
Someone leaked it from Nokia
Someone reversed it from the silicon, with a process usually called Silicon Reverse Engineering
The encryption was implemented in ARM code in the unflashable array (Very unlikely), and that was recovered in a method I would describe later in this post.
It was reversed mathematically from samples. I think the mechanism has a problem in which some bytes with the same value at the same array and with the same distance from each other might be encrypted into the same value, which can give information that could be used to deduce parts of the mechanism mathematically.
Or any combination of the options above.
------- UPDATE -------
Apparently the reversing of the encryption and encoding was done by:
The ROM contains a relatively small amount of code, but as you could probably understand by now, I don’t have this part. The only thing I care about from this code is one function that does the following two things:
Validating first 1MB of the MCU code.
If and only if the validation succeeds it activates the BaseBand (Any GSM communication)
Meaning that if something in the first 1MB of the MCU code is patched, the validation found in the ROM would fail and the phone won't communicate with anything. This won’t interrupt anything else at phone so it would keep running, but the user interface would display no signal sign. The validation function in the ROM is invoked from the MCU code, so the function call can be patched out, but again, it would make the phone not a phone as it won’t be able to make any phone calls. It might sounds like this is what the customer is looking for but it’s not, phone calls are still Kosher if they are not done on Sabbath. Note, that Bluetooth communication is still functional, and can be instrumented to become an easy to access debug interface.
Another validation that is found in the MCU code is a common 16bit checksum, that is done less for security reasons, but to check the phone for flashing errors or flash corruption. The right checksum value is found somewhere in the first 0x100 bytes of the MCU. This checksum is easily fixed with any hex editor. If the check fails the phone shows a “Contact Service” message, and shuts down.
At this point I don’t know much about what kind of validation is done on the first 1MB, I just have a few samples of official firmwares that pass the validation. Every sample has a function that residents in that 1MB of code and validates the rest of the code. If that function fails, meaning if I patch something in the code coming after the first 1MB, it immediately reboots the phone. The funny thing is, that the CPU is so slow, that I can actually get a few seconds to play with the phone before the reboot takes place. Again patching out this check equals no signal.
16-bit checksum - “Contact Service” message + Shutdown if it fails.
If changed - I get no signal.
Bytes that I can change as much as I want, probably some version info and public key of something.
Going deeper: To attack this protection I had to reach a better understanding of all of the different integrity checks. I don’t have the binary for the check performed on the first 1MB, so I reversed the check performed on the rest of the binary in an attempt to find some mistake. Using find crypt IDA script I found few implementations of SHA1, MD5 and other hashing functions that could be used and should be used to check binary integrity. I found a function that gets arguments of the type of the hash, starting address, length and returns a digest of that data. Following the xrefs of that function brought me to the following code:
The digesting function is “hashInitUpdateNDigest_j” of course. The SHA1_check_related address had the following data in it:
This is SHA1 digest of other arrays of binary, in chunks of about 0x2b0000 bytes. All of the data from 0x1000100 to 0x1100100 is protected by the ROM. The data from 0x1100100 to 0x13affff digest to EE41347A8C88F02F563BB973040E12338C03AFFA under SHA1. So I guessed that this function is the validation function that uses SHA1 to check the rest of the binary.
Later on in the same function I found the following code:
This function is performing the comparison of the calculated hash to the one in the table, if it mismatches it calls the hashMismatch function and then to the reset function with error code 4.
The hashMismatch function looks as followings:
Meaning it is a call to a function from another library, that is too far to jump using Thumb mode, so ARM mode is used to perform the call.
Therefore what I got is a code that is secured and is well checked by the ROM, which implements SHA1 check on the rest of the code, and when the check fails, it uses the code that it just failed to verify to alert the user that there is a problem with the binary.
See it is located in the 5th MB part of the binary!
From here the solution was as simple as writing a small patch that fixes the “binary mismatch” flag and jumps back to place right after the check.
How could such a fail happen to a big company like Nokia? Well, there are quite a few good explanations for that:
It could be that they really wanted to give the user some indication about the problem, or that they had to invoke some cleanup function before shut down, and by mistake, the relevant code was in another library that got linked to higher addresses and no one thought about it.
It is possible that this is a back door someone at Nokia left for himself (Only a speculation, I base it on a gut feeling and nothing else).
Everything was well checked on Debug build, but when they moved to Release, something went differently in the link and again they didn’t notice it.
Anyhow, this is my preferred approach for patching the flash, although, using this method I can’t patch the first MB directly, only what comes after, good enough for my tasks.
However, if it’s not enough, some guys reversed the 1st MB check for some of the phones and made it public. Though the function they published is only good for some modules, and not for the entire series.
Again the question of how? Well, it’s possible that it was silicon reverse engineering, but there’s rumored to be another method. The idea is that through JTAG debugging, one could single-step through the program and spy on the Instruction Fetch stage of the pipeline in order to recover the instructions from masked-ROM. Replacing those instructions with a NOP before they reach the WriteBack stage of the pipeline would linearize the code and allow the entire ROM to be read by the debugger while the CPU sees it as one long NOP sled. As I’ve not tried this technique myself, I’d appreciate any concrete details on how exactly it might be done.
Anyhow, now that I have a way to patch the firmware, I had lots of patches to make in order to make this phone Kosher. I had to reverse the menu functions entirely, which was quite a pain. I had to reverse the methods for loading strings in order to have a better way to find my arms and legs around this big binary file. Some of the patching was a bit smoother than others. For instance, after removing Internet options from all of the menus I wanted to be extra careful in case I missed a secret menu option, that the Internet won’t work. To disable the internet one might suggest searching for TCP implementation, but that's too much work, and it might harm IPC. One can also suggest searching for things like default gateway and set it to something that would never work, but again this is too much work. What I did was, searching for all the places where the word “GET” all capitals is found in the binary. Luckily I had just one match, and I patched it to “BET”, so from now on, no Internet server would ever answer requests. Moreover,To be on the extra, extra safe side I’ve also patched “POST” to “MOST”, lets see them downloading porn with that.
Other fun parts were making the Bluetooth connect to only audio devices, which took lots of reversing and learning the Bluetooth protocols.
In my next post stay tuned for the file system of the phones and ways to make them misbehave.
POC:
You can see on the video that the firmware was patched, because the code *#0000# for getting the firmware version has been changed to *#0001#. The fact that the phone receives a phone call indicates that I’ve overcome all of the protections.
I haven't posted for quite some time as my recent fun project failed to produce any worthwhile results. I hope to find the time to polish it, to be able to publish something.
Meanwhile some interesting stuff has happened at my work which is worth writing about.
I have found some security flaw in the all mighty SQL Server database, all versions included.
My company, Sentrigo, has asked me to write a Proof Of Concept which later we decided to make into a tool which mitigates the problem. We published the tool for free download on our web site http://www.sentrigo.com/passwords.
The tool created some buzz (We call it buzzwordizer), so I decided to write down what exactly stands behind it.
It appears that SQL Server is saving in memory all plain text passwords of any user that is currently logged in with a specific kind of authentication called native SQL authentication (enabled only in mixed mode). The passwords are saved intentionally in an internal data structure containing log-in information. That data structure is kept allocated in memory, it's not just some memory left-overs wandering around the free blocks in the heap. I know this for sure, because I have succeeded in writing a tool to jump through some pointers in constant offsets in memory, to get from the global sessions table to all passwords. Needless to say, I have never seen these passwords vanish from memory for as long as the user is still logged in.
There are only two ways to log in to SQL Server. One is this method and the other is Windows authentication, which lets Windows perform the entire process of logging in. The latter method is not flawed. Microsoft suggest that you use the Windows authentication method, and even refers to the other one as deprecated in some cases. Despite that, Sentrigo has learned that many users still use the less recommended method, because it is easier to configure.
Now, one may ask what is so wrong in saving plain passwords in memory? Every trained Ninja knows that a highly privileged log-in is required to gain access to process memory. And once such log-in is obtained, the sky is the limit for what the user can do with it. On the other hand, up until SQL Server 2008 there had been a SQL command called DBCC BYTES that allowed a privileged user to read the local process memory remotely. Notice that being a database privileged user does not necessary mean being a local machine administrator, on the contrary - some organizations separate the two for security reasons, which is violated by this flaw.
Furthermore, the flaw could be combined with some other flaw which provides only memory leaking, to create a remote passwords dumper, although I'm not familiar with any such flaws at the moment.
To summarize it I would like to quote my CTO Slavik Markovich, from one of the posts published about this bug: "Developers go to great lengths to ensure passwords are not even transmitted in clear text (for example at the time of login), let alone stored in a readable form. Users have come to expect that their personal passwords, are exactly that –personal – and that not even administrators can see them. Exploiting this vulnerability, an administrator will be able to see the passwords of users and applications that have connected to SQL Server, all the way back to the last restart. We respectfully disagree with Microsoft’s view that since it requires administrative privileges, the risk is mitigated. Even if you trust your admins, there are plenty of hackers capable of gaining escalated privileges, who could now easily access other systems across the network using these passwords."
After all, I would not consider this as major security problem as remote code exploitation, but it does indicates low security considerations, and could lead to bigger problems.
The thing I have found the most amazing about it is the way the Microsoft Security Response Team downplayed it. I have met more than one guy from the team in the past, and I must say that the team includes some well trained Ninjas that really should be adored for their good understanding of technical and low level details. They are all well familiar with every security aspects, and they have done some miraculous work in the past. On the other hand, from my point of view, they got a big fail on bureaucracy. They were quoting stuff from their books about how you should always trust your Administrators, and by that, they have failed to address this bug in the correct manner. And last and not least, the bug is still there. Bruce,to me you are still a phenomenal Ninja.
