Reversing a reverser

Two weeks ago, when I finally managed to get a 64bit machine and migrate to a 64bit OS, I installed for the first time Windows 7 64bits. Installation of a new OS is a terrifying experience, specially when moving to a new platform, some software that we're used to, ceases to function correctly, we need to reinstall tons of software, some we forget, some are no longer available. I think everyone has gone thru the process at least one time in their lives.

So, I was installing the tools of the trade, IDA being one of them and one of my favorite tools ever. As soon as I started IDA, I noticed that it failed loading the symbols of the target PE/PE+ file. What was going on? I reinstalled the tool, installed Microsoft debugging tools, and the symbols were resolved with Windbg but not with IDA.The weirder part of it, was that IDA was still asking me if I wanted to load the symbols, and yes, I answered affirmatively.I started debugging symbol loading, and everything worked fine. The problem was just within IDA.

I activated logging in symbol load, and I got this:

DBGHELP: new session: Thu May 19 16:11:28 2011
DBGHELP: Symbol Search Path: ¸Û¾
DBGHELP: No header for C:\Users\popo\Desktop\win7x86\logoncli.dll.  Searching for image on disk
DBGHELP: C:\Users\popo\Desktop\win7x86\logoncli.dll - OK
DBGHELP: ¸Û¾\logoncli.pdb - file not found
DBGHELP: ¸Û¾\dll\logoncli.pdb - file not found
DBGHELP: ¸Û¾\symbols\dll\logoncli.pdb - file not found
DBGHELP: C:\Users\popo\Desktop\win7x86\logoncli.pdb - file not found
DBGHELP: logoncli.pdb - file not found
DBGHELP: logoncli - export symbols
DBGHELP: closing session: Thu May 19 16:11:28 2011

The symbol search path had a weird string value. I checked the environment variables , and again everything was fine. I was irritated by now with IDA, because being such a great tool I couldn't get any clue of what was going on.
I searched all over the Internet and there was no answer for this problem anywhere, no clue in Hex-Rays blog. What the hell? Is it only me?
I started manipulating pdb.cfg and again, nothing.

One thing though that I noticed was that the symbols files were loaded if in the same directory than the object file, so for the first week I managed to go along by loading manually the .pdb and then copying it to the same directory of the executable.
Yesterday I asked myself, I'm I a reverser of a mouse? So I dug into reversing and debugging IDA.
This is what I found.

By the time IDA tries to initialize the symbols, the search path is corrupted. So I backtracked were was the path being set. This block of code tries to start-up a couple of components, and for the code to get the right values from _NT_SYMBOL_PATH or _NT_ALTERNATE_SYMBOL_PATH , it needed to successfully create one of this COM objects.

After getting the class ID of the COM object, all I needed to do was to go to my old XP and find out which executable file was being started.

The executable I found was a .dll file called msdia90.dll. All that's left to do is to grab this dll, copy it to my new machine and register it within the system:

regsvr32 msdia90.dll

And finally IDA worked its magic as always. Hurra!!...

Robbing sessions

What happens when the system trusts certain kinds of users? You can steal remote or local sessions. This post intents to demonstrate a local session assault as a PoC. More details will be given if you wish to escalate the technique :). Keep in mind that although this discussion is applicable to XP family, I'll be just talking about what happens in Windows 7 and 2008.

So, when we're switching between session in a Windows machine, thanks to Remote Desktop services and/or Fast User Switch, lsm is notified about our intents and haply, if we present the credentials of the user who owns the targeted session, switches us to the intended session, and locks our old one.

This is what the api tells us, but in practice there is more about it. LSM misbehaves and as you can see from the picture, before validating the password it checks the caller credibility.

So how can we bypass this check, just by injecting into our own winlogon process, who is a trusted caller, and that's running in our same session, so no need to cross sessions tricks.
I built a tool for a simple demo called rob console, this tool simply switches you to the first login session you made into the machine, without requesting for a password. Keep in mind that you need to be an admin to call the tool. The tool runs only in Windows 7 32 bits.
To see it in action do the following: login to your machine, your first session will open and this will be the session you will be robbing. Go to the your 'Start menu' and choose 'Switch user', login again, this time with your admin account, run the tool and voilá.
Please note that the tool connects to session 1, if you happened to logoff from any previous session the tool will fail the switch, because session 1 will not be available any more.
To see if session 1 is still around use the following command:

query session

SESSIONNAME USERNAME        ID  STATE   TYPE DEVICE
services                     0  Disc
console      popo            1  Active
             Administrator   2  Disc
rdp-tcp                  65536  Listen

If session 1 is no longer, than you need to reboot the machine in order to reset the session counter.
Now that you know the music let's dance the tango, cute things to do: remote session stealing - as soon as you connect remotely, even without logging in, a session will be created, this opens the chance to steal any remote session without the need to formally establishing the logon session with all the extras, drive mapping, user env., etc.
Combine this to elchomp, and you have an attack without forensic trail. Everything is done by the user, only the user, and nobody else but the user.

Enjoy.

Unlocking the Windows Station

Ever wondered why you shouldn't leave your computer with your session opened while the screen is locked?
This hazard falls in several OS domains if you consider the various types of attacks available out there.
This one in particular is focused on Windows, so if you're a Windows fan keep reading.
As far as I remember, at least since XP, this approach has been possible, although not wildly publicized. The "attack", consists just in injecting code in a cross-session Winlogon privileged process, that's retaining the desktop hidden. For this we need two things: remote or local access to the machine, (although local should be locked :)), and a privileged token, so we can cross session boundaries.
So, if we're already the machine's owner why do I call it an "attack"? Instead of forcing myself into the user locked session I could just patch the machine's code and collect every info I'd need like passwords, etc.
Well, that's true, but consider the amount of noise you'll make, the forensic trails you'll leave and consider your physical location. If for example the machine is network locked out, your only chance might be to use a USB or firewire local attack, and grab immediate access to an open domain session. If lucky could be the domain admin.
Besides, it's much funnier seeing CEOs faces when their sessions are opened wide.
Why is it an hazard? because everything becomes available to the intruder, private cache, private certificates, protected storage passwords, EFS files, etc. Not a pretty sight.

The tool is available here: https://www.filesanywhere.com/fs/v.aspx?v=8b6d698c615e76b4a2ab
To setup things you should remotely access the machine with administrative rights, copy unlockcon.exe to a folder, select the appropriate Win7 OS type, rtm or sp1, and copy the newdll.dll to the same location as unlockcon.exe.
Now, all you need is run it, and watch it do it's magic.

If you don't have two computers, then try this, create a batch file called unlock.bat and add the following commands to it's content:

timeout /t 30
unlockcon.exe
run the bat and lock the desktop. wait for 30 seconds and voilá...

nice trick to play with your friends.

How does it work?
Winlogon since Windows 7, is a state machine, that keeps track of it's interaction with the user, this state is recorded in an exported symbol xGlobalContext. When following winstation unlocking process, it ends in WluiReleaseUI, which is the crucial part of the process that unlocks the screen. See also WlAccessibilitySwitchDesktop and WluiAbort.

One final note: this tool doesn't reset the Winlogon state machine state. So, you won't be able to lock the desktop back to it's original look and feel. Instead, you can manually do it yourself by going to the start menu and in the shutdown button, click 'switch user'. (hint for a reverser who want's to code it's own fully functional tool).

Hope you liked it

Next post will be about session stealing, remote and local.