Wednesday, November 19, 2014

Bash Scripting: Printer Test Script


Print Script Tutorial Lecture
TheCAT
11/19/2014

Objective: Send a printer test page to a group of networked printers. Ideally, the test page has a date and user name. Additionally it should be in color and span the depth and breadth of the page. This script can then be used in conjunction with lab checks to ensure that the printers in the labs are in good working order and so that an individual that encounters the page can understand its purpose.


Minimum Command Requirements:
man
lp or lpr
chmod

Optional Commands:
date
cat
convert
lpoptions
& many more possible


Possible Syntax:
for, do, done
if then else fi
case esac
exit
shift

Tools:
nano/vim/emacs
a .jpg or two


Side note: A print script can range from 5 lines to 150 or more. You can use any language and there are no hard and fast rules beyond the objectives – which are more of a guideline.


First let's look at what lp and lpr do.

user@machine$ man lp

user@machine$ man lpr

While I personally think that lp is a little more versatile offering a lot of options I actually used lpr for my script – no real rhyme or reason there so consider either one a viable alternative.

So you can see that you are ultimately going to have to provide some data to the command like the name of the printer and the file to print.

But what to do when there is more than one printer?

Well, we could just run the command multiple times, each time updating the name of the printer to reflect the next printer on our list of printers. In fact that is exactly what we are going to do, but we aren't going to do it by hand, we are going to put it in a script.

One method for doing something a lot of times is to put it in a for-loop. In this case each iteration of the loop corresponds to printing the same file to a new printer.

You now have the foundation for the entire script; the rest is just refining the bits of what we discussed so far. And for that we will work individually... more on this at the very end. Other questions to ask yourself



* What are the printers?

       - do these live in the script?

       - do they live in a separate file?

* What file to use?

       - do I create my own image?

       - Text or picture?

* How to get the date on it?

* How to get a name on it?

* Do I test all the printers at once?


But before we start coding (and after we finish solving the problem) let's start with something we will need at the top of any script: the magic cookie. No not that chocolate yummy thing. This is a line at the top of our file that reads as follows:


#! /bin/bash

This tells kernel to run the script in a bash shell. So when you run a command from the command line, there is a fork command that creates and entirely new shell which is an exact copy of the shell currently running. We want to make certain that when the script is run, that the new shell is also a bash shell. This falls under the execve command that follows (but we now we are way out of scope)...

Lastly let's discuss chmod. Change file mode allows us to set permissions for a file. On our systems when you create a new file the permissions default to: -rw------- meaning only we can read and write to it, but cannot execute. For a text file this isn't terrible, but since we are building a script we will want to make it executable. Additionally there is the consideration of whether we want other people to run our script. Do you want to let other cats run it? Or anyone at all? For now let's assume that we want to make it so that only we can run it. When we are done, we will want to:


chmod 700 my_script 

Now let's get to work and start thinking about how to set up what we need based on the previous bullet point questions....


For Loop Syntax

for item in apple banana cherry; do
    echo $item
done


for number in {1..9}; do
    echo $number
done

for f in `ls`; do 
    echo $f
done



Monday, November 10, 2014

Microcorruption - Montevideo


Again, they have the same strange add 0x10 to the stack pointer at the very end of the execution of login. This allows us, as before, to overflow the buffer and inject a return address that we want. If this were a software version the address we could put in there would be “unlock door” but since this is a hardware version we have to again get 0x7F into the SR and call 0x10 <_trap_interrupt> to open the lock. Pretty much the same as before, so let's try the same code.

Of course it doesn't work, and as we can see they have added strcpy into the mix which effectively copies all information up to and including the null terminator – but it stops there. So we only get one occurrence of 00 and it has to be at the end.

But other than that our methodology should be intact, we just have to adjust the code. We can still have the filler up front, then the re-deirect to our code as before, but we have to be a little more creative to work around the 00 entries in our password.

Ideas:

So we have some filler, the address to our shell code, another bit of filler and then our code:

3f40 fffe mv #xfffe, r15 ← load fffe into register 15
1f53 increment r15 ← increment to ff00
024f mv r15, sr ← move to status register
b012 1000 call 0x10 ← has to be the last thing

So putting it together we have the following parts:

41414242434344444545464647474848 filler
0244 address to our
4141 filler
3f40fffe1f53024fb0121000 injected shell code

41414242434344444545464647474848024441413f40fffe1f53024fb0121000

Wow, that's a really long password. Perhaps we can think of something shorter?

So rather than inject our shell code after the password, why not make our shell code the password itself? At the end we can redirect the program counter (instruction pointer) to the start of our shell code. Of course we will need to watch out for null terminators which means we can't call 0x10 from inside, but the provided code already does for us at address 455c. All we have to do is jump there.

So, instead of starting our code with 4141 (AA) let's start with the injected code and as the filler. We also change the jump to address (to an address within the code that does it for itself). The last portion is the address where the beginning of the password is stored. Here's an entry that works and is much shorter.

3f40fffe1f53024fb0125c45   41414141    ee43

←           shell code          → ←  filler   → ← starting address of shell code →

Tuesday, November 4, 2014

Microcorruption - Whitehorse


I probably should have read the manual (right, who does that?) before now. But better late than never. The manual on pages on 4 and 5 talks about how 0x7F is the code to unlock the door – not a function call but basically a hardware interrupt that accomplishes the same thing. Additionally there is mention of 0x7D and 0x7E which set a byte in memory if the entered password matches. Look for those to come into play at some point. We actually already saw these in Cusco, although that knowledge wasn't fully necessary at that point.

As in a Cusco, there is still an instruction (after the password has been checked and after the “wrong password” message is displayed) that adds 10 to the stack pointer. So the stack pointer jumps forward x10 to address 3cc6, and the next instruction is to return to the value held at the address 3cc6. The assumption is apparently that you have not entered a password longer than x10 bytes and put your own value in that address. But as the saying goes: when you assume you make an 'ass' out of 'u' and 'me'..

So we can put what we want in 3cc6 because nothing prevents us from entering a longer password than 16 characters – that is nothing prevents us from overflowing the buffer. Last time we did this we put the starting address of the “unlock door” function. This time however there is no unlock door function, but there is ample room to put code that we write in assembly.

So first we want to get control of the instruction pointer. Put the address at that point to the area of the buffer that we have overflowed, that is point the instruction pointer at the code we are overflowing into the buffer. This is called injecting code.

So what do we want to do? As you may recall from Cusco, hardware interrupt x7e when placed in the SR (stack register) and called with the interrupt trap causes the password to be checked. Hardware interrupt x7d sets a password in memory indicating that the password was correct, and x7f straight up unlocks the door.

Let's do the following:
Point the instruction pointer at memory we control.
Get x7f into the SR **
Call the interrupt trap.

We can look at the existing instructions in the code to cobble the bits and pieces together – or if you want a project you can learn this version of assembly and roll your own. But the basic structure of the code we can use is as follows

3e40 007f mv #x7f00, r14
0f4e mv r14, r15
024f mv r15, sr
32d0 0080 bis (highbit), sr **
b012 1000 call 0x10

**Note: the manual says x7F opens the door, but on my version of the game they had an extra part in there that set the high bit to 1 yielding xFF as the value required to unlock the door. The only way you figured this out was by looking at the code within <INT>


453e:  32d0 0080      bis       #0x8000, sr
so while you were examining <conditional_unlock> where it loads x7e onto the stack and calls <INT> you can see as you step through it that x7e gets loaded into the SR (from r15) and they flip the high bit on and then call the trap.

You can trim down the code above if you work through it – I don't want to take all the fun out – but a successful entry based on the code above can look like:

41414242434344444545464647474848c83c3e40007f0f4e024f32d00080b0121000

Microcorruption - REYKEYAVIC


In the end, one line of code shows you how to open the lock. Security through obscurity ... isn't. Sure don't be the tallest nail near the hammer, but that shouldn't be your entire game plan.

What follows is my thought process while analyzing the code, scroll to the end for the facepalm. 

do_clear – writes 00 to x100 bytes starting at x247c to initialize that portion of memory to x0 values. While I personally feel that initializing things like variables and pointers is good, safe practice in coding, it does serve to highlight that this area of memory may be important to the encryption/ decryption/ password recognition process.

Main – puts x4520 into r14 and then into r15. If this is meant as an address it puts you halfway into “do_nothing”. Then promptly overwrites r14 with xf8 and r15 with 2400. Then calls ENC.

ENC – begins by writing values 0 to x100 in sequential order to bytes starting at x247C and rising. Given that we just spent all that time writing zeros to them, only to then re-initialize them all again with specific values is … uh … part of the game I guess. Moving along then....

44a4: R8 = 0
… an algorithm?
44b0: references troll text: “ThisIsSecureRight?” and puts “T” (x54) in R10
44b4: sign extend R10 … this shouldn't produce any result on an ascii character as the highest is x7f. However if a non ascii character is entered there may be things.
44b6: R10+R13->R13 (54, 54)
44b8: Set high order bits to zero, resulting in new byte. So if we sign extend, then add, then overflow the register and set the high order bits back to zero, we can get a new ascii character. Adding xffff to x53, then anding with xff yields x52.

x247c: There appears to be something being put starting here again...

444a: call 2400 program is now executing code that it appears to have generated in the previous portions.

Then I see it, the snippet of code that says: Compare d7c5 <---- this is the password for opening the door. 

Face, palm.

Wednesday, September 10, 2014

Microcorruption - Cusco

As before we should go on the assumption that we aren't going to get the password - and so we don't concern ourselves with what the actual password is but only with details about how the program processes the password that you give it.

The kind of things that we might want to consider are:
* how long of a password can we put in there?
   - does a long password blow out of the stack?
   - what is the starting address of the password relative to the code?
* how does the program handle special characters?
   - unicode?
   - special delimiters?
* what functions does the program use to deal with the input that you provide it?
* are there any data structures being used to store that data that we can exploit to our advantage?
* does register under/overflow have a use?

These are just a few of the kinds of things we can begin to think about. For this level we will really only need to consider the first couple involving length of the password - more on that in a minute.

We have to have a good understanding of the code to see where the weakness is. Since this level represents an incremental update from the previous version, it seems that a reasonable place to start looking is where we looked last time... in login:


4520:  b012 5244      call #0x4452 <test_password_valid>
4524:  0f93           tst r15
4526:  0524           jz #0x4532 <login+0x32>
4528:  b012 4644      call #0x4446 <unlock_door>
452c:  3f40 d144      mov #0x44d1 "Access granted.", r15
4530:  023c           jmp #0x4536 <login+0x36>
4532:  3f40 e144      mov #0x44e1 "That password is not correct.", r15
4536:  b012 a645      call #0x45a6 <puts>
453a:  3150 1000      add #0x10, sp
453e:  3041           ret


At line 4520 the program calls "test_password_valid". It might seem like looking in test_password_valid is a good idea - after all we have previously found the password or some variant of it there. No such luck this time, there is a hardware call to do that comparison and that hardware black box puts some value into memory and program flow eventually looks at that value.

That value ends up in R15 and is then examined and if the zero bit is set based on the results of the test in line 4524 (meaning the password was wrong) then we jump to 4532 where we get the address of a string and at 4536, we 'puts' that message to stdout add 10 to the stack pointer and get out.

It merits looking at program flow for a right password also.  If the zero bit is not set when we get to 4526 (meaning the password was right) we fall through to unlock_door get the address of a message and JMP to 4536 where we 'puts' that message to stdout, add 10 to the stack pointer and get out.

In both cases, success or fail, the stack pointer is incremented by 10 to 0x43FE whereupon the instruction pointer returns to that address and executes WHATEVER CODE IS THERE...

The idea is of course that the stack pointer is incremented beyond the user password to an address for program execution which in both cases is 0x443C which is stop_prog_execution.

But what if some other address was inserted into 0x43FE? Well, the instruction pointer would return to that address and start executing that code instead. What if someone put the starting address for unlock_door instead of stop_prog_execution into 0x43FE? Then, whether or not the password was right the door would be unlocked.

It is a simple matter to find the starting address of unlock_door and (remembering that we are little endian) fill the password with 16 characters of garbage and overwrite memory location 0x43FE with 4446. It is also convenient that 44 corresponds to ascii D and 46 to ascii F.

Our winning entry is then:

1234567890abcdefFD

Friday, September 5, 2014

Microcorruption - Hanoi

These next few levels, if you aren't familiar with delving into assembly code, are a great place to start stepping through the code to get an understanding of program flow.

From looking at the code we can see that there are some basic structures that we will see over and over again in the coming levels.

trap


The trap interrupt is a software call to a hardware interrupt that results in some action being taken based on the status of certain registers - in this case the contents of the status register are used. The action taken is either to unlock the lock or set some value in another register (like r15) indicating that the supplied password was correct.

We will use this trap interrupt whenever we can. Page 8 of the manual starts the listing of valid status register contents. While some of the beginning entries seem unusable, the last entry is clearly gold: "interface with deadbolt trigger to unlock door..."

If you can set sr to 0x7F and call the trap, you win.

low level init, do copy data, do clear bss

These are some housekeeping routines called at the start of the program that aren't useful for our purposes.

main


Mostly we can expect that this is where the action would begin. Throughout the various levels we will see a variety of program styles. Some will have main filled and very few function calls, whereas this particular level the only purpose of main is to call login and then drop through to:

stop_prog_exec


Terminal point for program execution. If you get here, you failed.

unlock_door


As you can see from the code the action of unlocking the door is exactly as described above: Get 0x7F into the sr and (eventually via INT) call the trap. This doesn't always occur - hardware implementations generally don't have this function in any meaningful fashion.  But if it exists and you can get the code to call it, you win.

INT


Putting this out of order because it goes with unlock door nicely, this performs some housekeeping of preserving register state and calling the trap.

**note** As I mentioned in another posting the game changes over time to prevent people from cutting and pasting entries. In the version I played, 0x7F isn't actually the status that needs to be in the sr. I needed 0xFF to be in the sr - even though the manual said 0x7F. Generally I will refer to 0x7F as being required, but my code will always change to 0xFF.

putchar, getchar, getsn, puts


assembly implementation of C standard io lib functions. Used for user i/o. We will take advantage of their weaknesses and the code that uses them unwisely. There will come a time when the program asks for a 16 character limit password, but will ultimately accept any length which allows us to overflow the buffer. The combination of that limited expectation without following through on i/o limitations allows this kind of buffer overflow exploit. This is how we will be getting our desired value into the sr.


test_password_valid


we can expect to have to endure this function every time, but nothing of any real note happens in here.

login


The start and end of the action generally speaking. There is some point usually in this function where a branch is taken or not the ultimately allows the weakness. It varies by level, but ultimately occurs here - not in test_password as one might expect.

Having an understanding of program flow and the parts each of these functions is important. Knowing that login generally contains the meat allows us to focus on that for our weakness. Let's look at the code:We see that the true comparison for whether or not the door will be unlocked happens at line 455a and has nothing to do with test_password_valid function. The true comparison checks for a hardcoded value (0x9B) at a fixed address (0x2410). If that value is at that address code execution falls through the jne branch to "access granted" followed by a call to the unlock_door function.

4544:  b012 5444      call #0x4454 <test_password_valid>
4548:  0f93           tst r15
454a:  0324           jz $+0x8
454c:  f240 6100 1024 mov.b #0x61, &0x2410
4552:  3f40 d344      mov #0x44d3 "Testing if password is valid.", r15
4556:  b012 de45      call #0x45de <puts>
455a:  f290 9b00 1024 cmp.b #0x9b, &0x2410
4560:  0720           jne #0x4570 <login+0x50>
4562:  3f40 f144      mov #0x44f1 "Access granted.", r15
4566:  b012 de45      call #0x45de <puts>
456a:  b012 4844      call #0x4448 <unlock_door>


We also know that the starting address of where our input string occurs is 2400. Because the code doesn't actually prevent us from entering more than 16 characters (despite using getsn which can take a limiting size) we can fill addresses 2400-240F with garbage and put 9b at 2410, which will result in unlock door being called.

Here is a sample winning string (don't forget to check the box 'hex encoded') which does exactly that.


414243444546474849505152535455569b

Monday, August 4, 2014

Microcorruption - Overview, level 1, level 2


Overview


This is a war game where you are tasked with defeating a lock - it's a computerized lock that sounds really forbidding but ultimately turns out to have more holes than a sieve. The game does a good job of staying playable for new people as it has several versions that are all pretty much the same but the minor differences prevent cut and paste jobs.

Additionally, the makers of the game do a nice job of leading the player down different paths to explore not only different attack vectors but also prevent the same one from working over and over again.

As a side note, I originally started this game with the intention that my son would learn a little about computing. He didn't make it much past the first few levels - apparently prying locks open to steal imaginary bearer bonds isn't exciting enough. I suppose that is a good thing on some levels. But he did learn about the binary, octal and hexadecimal number system - which is a solid start. You can view our (my, at this point) progress as "SamnDad" on the website.

Some notes about the environment:

<action src dest>

This is the format for the assembly language for the game. This style is generally considered the reverse of Intel x86 assembly language which  puts the destination before the source.

little endian

0x1234 goes into the registers as 3412

Despite not having intel style syntax for the language the processor is little endian like many Intel processors.

Thanks Texas Instruments for being weird.
 
cmp a b yields flags based on result of: b-a ...  Good to remember for flags.

Useful websites for delving into the particulars of the processor:



New Orleans – level 1


I set a breakpoint at main and again at create_password. Create_password seemed like a good place to start, and I thought it was odd that it ran before the getsn() was called and as I watched the memory it filled in a string of letters as a I stepped it through. Naturally I tried that string, and it worked.

Interestingly the game appears to be designed for there to be a preferred solution because when I tried to overflow the buffer and trample the code, it cut me off at 100 characters despite that I entered 300 characters. This overflow works in later levels but not earlier levels. And so the game appears to be designed to train you to look for certain things.

Key learning elements: how the interface works, stepping through code and using the tools and understanding the user interface.

Sydney – level 2


The program stores the incoming password and puts it at 43a0, above which starting at 4400 is the code itself.  
Sets SP to point at 43a0 (first letters of incoming _password) and preserves SP in r15 where the incoming pass starts.
Compares a literal (0x4624 - F$) to 0x00(r15) which means r15+0 offset. As it turns out that literal is part of the password.

Jumps to (44ac) if not zero.
Whereupon it clears r14 and puts r14 into r15 and returns...
r15 has 0.
r15 is tested for 0, and if not zero goes to unlock door.
R15 0 goes to fail.

This repeats 4 times basically, so the password is hard coded not in memory but in the code itself in the form of looking for things to test against.

So: 4624 6a70, 574c, 5554
or: F$jpWLUT

EXCEPT that endian-ness counts:

2446706a4c575455
$FpjLWTU

Key learning elements: endian-ness, identifying key components of the code and stepping through those parts, flags and comparison.


Notably, buffer overflow is prevented at these early levels.