Microcorruption - Santa Cruz

It's been awhile since I published anything related to Embedded CTF, so here is another level that I had in the queue...

Santa Cruz is a little more cryptic in that functions are more poorly named.

There is still a lot of similarity between this level and the previous however. For example, both levels continue to have the very end of the login adjust the stack pointer to a potentially vulnerable spot and then return to the address stored at that spot. This is likely to be our vulnerability again.

On a lark I tried something different to start. I wondered what happened if we injected like 500 characters instead of say 50. My initial thinking was that I could inject enough garbage and overwrite one critical return point with a call to <unlock_door> where the beginning of <stop_progEXEC> occurs. The result would have been the last thing the program did after telling you that you failed and that your password was too long and then trying to quit on you would have been to unlock the door for you. It turns out however that the maximum amount of characters that will be read in is 100. I tried a direct approach of overloading with several hundred but it limited my maximum input. 

So maybe we should put that idea into our back pocket for some other time.

Inspection of the code shows that normal program execution never calls <__do_nothing> and also does not call <test_username_and_password_valid>

Some exploration with input yields the following behavior:

• The full length of the username and password are copied (up too 100 characters each).
• The start of the username is always address 0x43a2 regardless of username length.
• The start of the password is always address 0x43b7 regardless of username or password length.
• The code requires memory address 0x43c6 to be null.
• The code requires memory address 0x4303 to be 0x08 - minimum length.
• The code requires memory address 0x4304 to be 0x10 - max length.
• A final call returns from 0x43cc if the password is not too long (this is the historical vulnerability).

Registers at about line 0x45d0

r11: 0x43b5

r15: 0x43b5 (start of pw)

r13: 0x43c6 (null delimiter put in by password)
r14: 0x43cc (houses return address)

Given that behavior and those requirements we can meet them with the following strategy:

usernameuse0812PASSWORD'\0'meusernameusernameSHELLCODESHELLCODESHELLCODE
<- fill ->< ^^REQD fill ^REQD><--- filler --><-- return point & code--->

where the password overwrites a portion of the user name in memory and is used to fullfill the requirement of the null delimiter at the correct address and the username is used to inject the code. As for the shell code itself we can use similar code to what we have previously been using. Likely we will have to alter it a bit as addresses have changed, but the basic tactic of either calling <unlock_door> directly or using the status register and the interupt trap will work.

Specifically you will need 42 characters of fill for the username after which shell code will start and a password of 15 charcters in length.

The following username and password entries will break the lock. Can you get better shell code based on the previous levels to get on the leaderboard?

Username: (hex code enabled)

4141414141414141414142424242424242081242434343434343434343434444444444444444444445454A44

length: 44, 12835 cycles

Using Burp Suite with Cluster Bomb to Brute Force a Web Login

Of course you only are going to attempt a brute force login against something that you:

(A) Have permission to attack in the first place
(B) Know you won't affect the client's environment in a negative fashion including:
      (1) Lock out users
      (2) Knock over servers
      (3) Clog the network

Brute forcing is the kind of the thing that, if you know you aren't going to hurt stuff, makes sense to do while you are away getting lunch or otherwise have it going in the background. After all, you never know what you might find.

Choosing a good password list is a topic all to itself, and one I may cover at a later date. But for now let's assume that you have a list of users and some passwords. Cluster bombing always makes sense even if some of the passwords go with a specific user. For example, let's say that Joe has a password of Seahawks for his ssh login, but not for the web application in question. Let's also say that Susan has a password of Orioles for her FTP login but not for the web application.

What if Susan's password for the web application is Seahawks?

This might seem far fetched, but it happens, and if you include all the passwords that you have (or think as likely) and run them against all the user names that you have (or think as likely) and you are using Burp Suite, then you want to run a cluster bomb attack on the application.

So how to do it? First we need to set up our proxy for burp with the browser we are using so that we can capture login information...

Then we ensure that intercept is on for burp and enter our data on the web page. Notice that our username of 'foo' and password of 'bar' are captured. This information is held by burp and will be used over and over again in the attack.

Specifically, the parameters indicated will be replaced by contents of files - a list of user names and a list of passwords. The next step is to right click this screen and send it to intruder. Notice that, with the intruder tab selected, the sub tabs of Target, Positions, Payload and Options present themselves. Target won't have to be altered as we are using http or port 80, but our Positions will need to be specified. Remove the unwanted foo and bar - we only put them there so that were could easily identify where they were on the form.

On the next tab, Payloads, we will indicate what usernames and passwords will be plugged in for the attack. As we are using a cluster bomb attack every username will be tried with every password, which is what we want.

Then on the options tab you want to make certain that you handle redirections and start the attack.

Lastly, as you watch the attack in the background you can sort by length of results to see if you have any hits. For very little set up time these kinds of attacks may give you some level of additional access that you can leverage from information that you may already have.