Red Team Project

From CyberSecurity
Jump to: navigation, search

Groups of 5-10 Students Will Search Attack a Simulated Financial Sector Target and write a 2-5 page report summarizing weaknesses identified, estimating potential damage from an attack, and recommending solutions (if any).

Programming Component

Instructions for the programming part of the Red Team project are available at:

Note that Kiran Tati (ktati@cs.ucsd.edu) is serving as the TA for the programming aspect of the project.

Apologies for being a day late; I decided that the framework for doing it entirely as a networking exploit was getting in the way of the core process of implementing the exploit itself. So I reverted to a simpler form of the project.

Some things to keep in mind:

  • We have yet to finalize group membership.
  • We have created accounts on the machines at the granularity of

groups. Since we don't have groups yet, though, you cannot login. But you should still be able to make substantial progress on the project, particularly if you already have an account on some other Linux machine. In reality, you only need our machines to do the very last step (and the last step is the easy one). And you should be reading the background material before you do any programming.

  • If you want to go solo on the project, let us know and we can give

you your own account.

  • With the background reading and the tutorial slides, implementing

the exploit should not take much time. If you find yourself spending more than a day without making substantial progress, send mail to me and Kiran.

Let us know if you have any questions or encounter difficulties.

Our hope is that you'll find the project to be an enjoyable one, and a useful learning experience.

Thanks, -geoff

Address Space Layout Randomization

--Voelker 14:17, 11 October 2005 (PDT)

some folks who have been experimenting with the programming project on their own have encountered defenses against the kind of buffer overflow attacks that we are using in the course. (we have the defenses disabled on the class machines so that this is not an issue.)

for those who are interested in the defenses, read on...otherwise you can hit the 'd' key now :-)

> i've noticed on the linux i'm using (2.4.27), the stack address keeps
> changing for where things start, making it impossible to hard code the
> address of the buffer (so i can make the program jump to it). kiran said
> that this is a new protection mechanism.

the defense here is called address space layout randomization (ASLR). the idea is that, whenever the OS creates a new process, it randomizes where it places memory regions (stack, heap, libraries, etc.). this prevents exploits that depend upon fixed addresses and/or offsets between regions.

very recent versions of Linux use it by default; for older versions of Linux, you had to apply a patch. so, depending on what Linux distribution you used and when you installed, you might or might not have had it installed. it is part of a larger package for preventing more general classes of exploits.

for one approach and how it works, see:

 http://en.wikipedia.org/wiki/PaX

also look at the History, and note vulnerabilities even in the defense.

fwiw, controlling the functionality is not very user friendly. if you're curious for your own machine, I'll add some info to the project web page.

> i was wondering, how people are
> getting around this today? (that is if its possible at all).

good question. two kinds of people have been asking this question as well. researchers have analyzed its effectiveness from a security standpoint:

 On the Effectiveness of Address-Space Randomization
 http://www.stanford.edu/~blp/papers/asrandom.pdf

and hackers have been developing mechanisms for bypassing it:

 Bypassing PaX ASLR protection
 http://www.phrack.org/show.php?p=59&a=9

> also what
> version of linux did this change? and is windows also doing this?

for a brief history and related Linux projects, see:

 http://en.wikipedia.org/wiki/PaX#History

but, basically, it's now in the default Linux kernel.

for Windows, as far as I know, no...but others offer packages for doing it. see, e.g.,

 http://www.wehnus.com/technology.pl

-geoff

How Windows Does It

Rob Nash

I'm gonna butcher stuff, so I hope someone else adds to this...I think one problem with ASLR protection is that older software that relies on assumptions about the addressing space being fixed can intermittently crash using ASLR, and microsoft puts a premium on backwards compatibility. My understanding is that microsoft advocates a competing scheme (built into the compiler) that encodes a random number just before the return address on the stack, and when it's time to jump/return, the runtime first verifies the random number and crashes if the number differs from what was seeded there (as this implies the random number and/or jump address has been overwritten). This, in turn, retains the backwards compatibility, but must be enabled at compile-time, since this is a feature of the compiler and, as a result, benefits only new programs compiled with this protection. Question: is one approach significantly better or more exploitable than the other?


-Rob

Drew Hoskins Circumventing either protection relies on the programmer bypassing something that is generated at runtime. In the case of ASLR, this is an offset, and for buffer overrun, it's the value of a dynamic "cookie" on the stack. I think ASLR will probably protect against attacks that rely on knowing a fixed address, whereas the cookie will only protected against buffer overrun.

One really cool thing about the stack cookie check is that it combines with Windows Error Reporting quite well. Microsoft can collect data from programs that had buffer overruns because they all go through the same bail-out mechanism. It can use that data to find and fix the exploitable code!

How does ASLR get away with loading a program at a random address? It seems like it would have to fix up all the pointers based on a dynamic offset. Presumably, the program would have had to be linked with a function that runs all these fixups at load time. Maybe not, maybe there's some other way?