The Making of the Kosher Phone

As seen on POC||GTFO 0x03 and more

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:

1. Nokia 1208
2. Nokia 2680
3. Nokia 2720
4. Samsung E1195
5. 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:

1. These phones still make a nice income that I would not want anyone to take away.
2. 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:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  AD 7E B6 1A 1B BE 0B E2 7D 58 6B E4 DB EE 65 14  .~¶..¾.ג}Xkהמe.

00000010  42 30 95 44 99 18 18 38 DB 00 FF FF FF FF FF FF  B0•D™..8.

00000020  FF FF FF FF F8 1F 8B 22 50 65 61 4B FF FF FF FF  ר.‹"PeaK

00000030  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

00000040  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

00000050  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

00000060  FF FF FF FF FF FF FF FF FF FF FF FF F8 C4 AA C3  רִ×ֳ

00000070  85 CF C6 E7 00 04 8A 5F 01 00 01 00 00 00 00 00  ֶֿ...ח..._........

00000080  00 00 00 00                               ...

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:

1. I can see what bytes are actually sent to the phone during flashing, and
2. 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:

• G3gg0 who is also responsible for the amazing tool Trix (http://www.g3gg0.de/wordpress/)
• nok5rev
• And Krisha

More information about how it was done, and the original source code is found on the following link: http://www.gsmfreeboard.com/showthread.php?t=119075&highlight=DCT4Crypter 

-----------------------------

That came out not as clear as I expected...

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.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  AD 7E B6 1B 23 10 03 40 C6 05 E4 01 20 A2 00 00  .~¶.#..@Æ.ä. ¢..

00000010  00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF  ...........ÿÿÿÿÿ

00000020  FF FF FF FF F8 1F AA 02 50 65 61 4B FF FF FF FF  ÿÿÿÿø.ª.PeaKÿÿÿÿ

00000030  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

00000040  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

00000050  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

00000060  FF FF FF FF FF FF FF FF FF FF FF FF C0 52 90 D4  ÿÿÿÿÿÿÿÿÿÿÿÿÀR.Ô

00000070  4A E4 5C 8F 00 02 00 00 01 00 01 00 00 00 00 00  Jä\.............

00000080  00 00 00 00 FF FF FF FF FF FF FF FF 01 CE 00 00  ....ÿÿÿÿÿÿÿÿ.Î..

00000090  03 00 00 00 00 04 CC A2 00 04 CC A3 FF FF FF FF  ......Ì¢..Ì£ÿÿÿÿ

000000A0  00 00 F1 EF 89 33 EB 2D 1F 09 3B DA C7 C0 3D 9F  ..ñï‰3ë-..;ÚÇÀ=Ÿ

000000B0  BB D3 29 98 01 C8 BC B0 06 6E A8 11 0E D1 69 67  »Ó)˜.ȼ°.n¨..Ñig

000000C0  A4 A3 9A A5 BF 7B 27 5A E6 C7 61 2D F7 B8 70 9C  ¤£š¥¿{'ZæÇa-÷¸pœ

000000D0  D4 1C 09 96 AF 5B F2 05 20 92 49 DF D5 0B FC DE  Ô..–¯[ò. ’IßÕ.üÞ

000000E0  A8 30 B7 39 34 59 13 7D E7 BD 72 3F C7 CF B3 5A  ¨0·94Y.}ç½r?ÇϳZ

000000F0  60 2C 5E 7D 63 17 56 C4 9F 6C C5 1A 01 BF B5 CF  `,^}c.VÄŸlÅ..¿µÏ

00000100  EA 01 FF BE 00 FE 6A 84 EA 50 20 20 20 20 6A 04  ê.ÿ¾.þj„êP      j.

00000110  2D CF 20 20 20 20 6A 01 9D 7C 20 20 20 20 6A 01  -Ï      j..|    j.

00000120  B3 C8 20 20 20 20 6A 01 A5 C2 20 20 20 20 6A 04  ³È      j.¥Â    j.

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:

1. 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.
2. 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).
3. 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.

Python scripts coming soon…

Cheers,

Assaf

Problems with software reverse engineering

A dark times to us all reverse engineers, especially the software kind. During my ~ten years of practice in the area, I’ve found out that today we have less tools for the task than what we had five years ago. Sure, nowadays IDA has a decompiler and some kind of a Python integration, but we all miss tools that served us for so long such as SoftICE and the Zynamics bindiff.
In this blog post I would like to tell my humble opinion on the subject.
Lets say a person, who I’ll refer to as the user, is given a one million pages long book (Font size 7). The user is being asked the simple question of “Does Alice ever meet Bob in this story?”. The user can read all million pages or die trying, in order to answer the question. But if the user had a digital copy of the book he could have searched for all of the places in the book where the word Alice and the word Bob are found not more than two pages apart. If the user had a Python interface to all the information found in the book, he could have used RegExp or some kind of lexical Python modules to maybe look for the word “meet” in all variations such as “meeting”, “met” or so on. Moreover, he could have found a way to figure out if there is a nickname for Alice such as “The Bitch”, and to automatically add this nickname to the search.
The way I see it, the current status of software reverse engineering is much closer to the hard copy book search task, than the digital one, and much further away from a decent Python interface.

The most commonly used tool IDA is giving the user a huge textual dump of disassembly, with some basic blocks, functions and higher level of understanding, where the highest level it gets is with the decompiler in which the user gets a C like code to read. I agree that it is easier to read C code than Opcodes but not by far. The user would never be able to read all the text for even the simplest program such as the Ms-Minesweeper. To produce this kind of text dump IDA had to had some kind of “understanding” of what each and every opcode is doing. I call this “opcoding doing” the opcode side effects. For instance, the side effects of the “ADD EAX, EBX” opcode would be reading EBX, EAX and writing to EAX and EFLAGS. IDA got this precious knowledge of side effects but it doesn’t let the user access it. I think this is the biggest point of failure in the understanding of what reverse engineering should look like.
Lets consider an example of creating a crack for a simple serial protected tool. The approach usually is of using a debugger to break on some known related API such as the GetDlgItemTextA or MessageBoxA to get to the point where the username is read or a wrong key message is displayed. Replacing this part of the task with a search of all functions in the code that are one or two steps away from both of these APIs, slicing with all the functions that contain the XOR opcode with two different operands, and some other characteristics relevant only to those kind of functions, would most likely produce a very short list of potential functions. When analyzing the functions, it is probably using many other functions that the user doesn’t care about, while only few of them are relevant to the serial validation. Displaying a list of all functions that are accessible from a certain function and filtering only the ones that might make an access to the buffer that is pointed by EDI or so, would make the job of the reverser much more effective.
The text of the opcodes is hardly ever what the reverser really cares about, he just wants to know what are the side effects of a function are, whether it changes EAX or not, whether it makes a copy of the buffer or not. The decompiled code is nice, but considering the fact that it’s not possible to recompile this code, why write it in C and not as an equations or list of arithmetic operations.
The reversing tool should be a much dummer tool that just creates the access point to as much information as available, the analysis should be done later on with scripts and plugins. The analysis that is done on a malware is not the same one that is done on a DRM product and is not the same one that is done on recovering algorithm.
However, putting all that aside, we have to have undo functionality. The lack of the undo function in IDA represents not only the fact that the tool is incomplete, it represents the fact that tool was made with small projects in mind, while sometimes the reversing work is something that is done over a long period of time. Symantec, Kaspersky and others told it took them a few months work of more than one reverser to get a basic understanding of the Stuxnet, which as far as I know, had very little anti-debugging tricks to it. IDA is not made for collaboration or long time research.

I would love to hear more opinions about this subject, and what people think should be done about it.

Cheers,
Assaf

Wonder Cheat 3

Recently I had a major nostalgic emotional burst which took me all the way to the Sega Master System ™ I had in my childhood. One of the games I remember the most from this 22 years old console is the Wonder Boy III, the Dragon’s Curse. So I fired up the Meka emulator and downloaded the ROM, and sat down for few hours of unlimited fun.

During the search for the ROM I found out that there was another version of the game with slightly better graphics for the TurboGrafx-16 console (AKA PC-Engine) which is called the Dragon’s Curse.

For the readers who never heard of WB3 or the Sega Master System, I shall explain, in short, the game’s look n’ feel. The game is some kind of a combination of RPG with a platforming action game. You need to get different kinds of swords, shields and armors by either finding them in treasure chests throughout the game, or buying them in shops found in the city. Besides the gear, the player has to collect gold, potions, magics and power ups. The game has about 6 levels that the player has to finish, while at the end of each one there is a boss that has to be destroyed. When a boss is beaten, the character in the game transforms into some kind of a new animal-human creature that possesses a special ability that helps him get to the next level. The characters are Hu-man, Lizard-man (Can shoot fire), Mouse-man (Very short, and able to climb some walls), Piranha-man (Can swim), Lion-man (Can punch up), Hawk-man (Can fly).

Bosses:

The part that I find interesting about this game is the way save games were implemented in time before Flash memory. During the game there was a place in town where the player could get a 14 characters long code that if entered in the main menu, would take him back to the same status as he was in the time of getting the code.

Meaning these 14 characters encode the full status of the game, including amount of Gold, Lives, Potions, Gear and more. The characters are either numbers 0 to 9, or capital ABC, excluding few characters such as I, O & Q, for the reason that they look too much like 1 and O, which could be quite confusing. Besides that, not every combination of characters is valid, meaning there must be some kind of a checksum. I remember that many years ago, every time I got bored playing the game I was trying to brute-force codes, with very little success. I was always very curious about this mechanism, and I had a belief that somewhere, there is some kind of a very special code that would turn the game upside down.
During the last week I decided to finally cope with this old craving, and finally reverse engineer the secret behind this coding system. First I had to find out which CPU is used by the Sega Master System to know how to load the game in IDA. Wikipedia mentioned, rightfully, that the Z80 is the main CPU of the console, and loading the ROM file into address zero seemed to work just fine. Second, I had to find the relevant code, so I searched the Internet for some special codes that might lead me to the right place. I found out that there is one very special code that is WE5T 0NE 0000 000, which is the name of the company who made the game. This special code could not possible encode a game status, so it must get a special treatment in the code. Searching for the string (without the spaces) through the entire file took me to the following code:

Xrefs took me to:

From reversing I found that every character tributes exactly five bits to the data, that comes to be total of 70 bits (5 * 14) which turn into total of 9 bytes of data. Two bits of the 9 bytes are index to a xoring table that is then xored to the 9 bytes. After the xoring, all the bytes are added together to form a checksum that is compared to the first 7 bits (which are not used in the addition). If the first 7 bits match, the code is valid and is passed to another function that sets the game state.
I’ve written a full functional code decoder / encoder in Python, and is available for download from the following link:
http://xp-dev.com/svn/Cheats/


Links:
For more information about Wonder Boy III and The Draogon’s Curse follow the links below.
http://www.geocities.jp/monsterworld2/Wonderboy_Land.htm
http://hg101.kontek.net/wonderboy/wonderboy.htm
http://retro.ign.com/articles/930/930245p3.html
I would like to thank them for the pictures I took from these sites without asking for permission, hope it’s ok.

Cheers,
Assaf.

P.S.
The Dragon’s Curse has something different in the coding system, I would have to reverse it too. Does anyone know how to reverse the PC-Engine’s ROMs?

Sentrigo Passwordizer

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.

Relevant links:
http://www.sentrigo.com/
http://www.sentrigo.com/passwords
http://www.slaviks-blog.com/
http://www.businesswire.com/portal/site/google/?ndmViewId=news_view&newsId=20090902005149&newsLang=en
http://searchsecurity.techtarget.com/loginMembersOnly/1,289498,sid14_gci1366853,00.html
http://www.securitypronews.com/insiderreports/insider/spn-49-20090902PasswordFlawFoundInMicrosoftSQLServer.html
http://www.eweek.com/c/a/Security/Microsoft-Downplays-SQL-Server-Database-Vulnerability-893487/