Tag Archive for 'hacking'
Barcamp Rochester 3 was Saturday, and it turned out to be an *amazing* event. The idea behind Barcamp is that it is an informal conference where there are no spectators, only participants. This means that everyone who attends gives a talk on something, ranging from programming languages to intellectual property to enacting political change through technology.
The talks ran from 10:00am to 10:00pm in three separate rooms, and given that multiple talks were going on at the same time it was impossible to see everything. I did attend Google employee Jordan Sissel’s “cool stuff I’ve worked on” presentation, jquery creator John Resig’s jquery presentation, frequency ninja Andrew Potter’s wireless and spectrum lecture, and a round-table discussion on politics. Needless to say, it was a very full day.
I personally gave an hour lecture on the same material as my most recent Society of Lectors lecture, covering hacking through exploitation and shellcode. The turnout for my talk was great, and for anyone who attended that is now reading this, thanks for being part of such a great audience! I really enjoy giving this lecture – I get excited about the topic, and it is great to see other people getting excited about it too. The questions at the end are always my favorite part, and given more time, I could have talked forever about some of the topics that were brought up because of them.
The biggest event of the day for me was a talk on how we can use technology to inform people, with a special focus on the US political system. It started as a round table discussion led by Remy D of the NYPIRG and James Turk of the Sunlight Foundation labs, with Dave, Heewa, and myself attending. It moved from ideas to implementable actions, and while I entered the discussion skeptic, I left with the feeling that it is possible for individuals to make a difference in a system that is much larger than themselves. I hope to engage in future work that will spread the same kind of hope to other individuals, because the opportunity exists to shake the popular apathy for our communities – and knowing it is somehow comforting.
On top of everything else, I’m helping Dave and Heewa with the One Laptop Per Child program at RIT. The organization is sound, and their ideas are worth pushing forward. I’m particularly interested in the mesh networking capabilities of the XO laptop, and my contributions will most likely be related to software that takes advantage of it. The reason I’m bringing this up in a post on Barcamp is because Dave and Heewa gave a couple talks on the initiative and their plans for it at RIT, and having finally obtained an XO laptop, I got to play with it! John Resig also had one, so we messed around with chat and video feeds. It was pretty cool, even though the size of the XO makes it kind of difficult to work with.
The event overall is just something you have to experience. There is nothing quite like a gathering of a bunch of smart people talking about what interests them. With few exceptions, everyone is really friendly and down to earth, which makes it really easy to just focus on the goal of the day: to share ideas, meet new people, and leave just a bit better than you were when you came.
Here’s looking forward to Barcamp Rochester 4!
Yesterday I gave the second lecture in my “hacking” series. We’ve progressed beyond general descriptions and terminology and moved into the technical aspects of the stack, vulnerable code, and crafting exploits. The lecture ran about 45 minutes, and was accompanied by a live demonstration of exploiting vulnerable code.
For those that came late or missed it, the slides are available here (pdf format), although once again the real content was in the accompanying talk.
The demonstration used three source files. The shellcode was written by BreeZe of binbash.org, while the other two are my own. They are:
Running the Exploit
First, I only tested the exploit running on Debian Linux, running a 2.6.23 kernel on a 32bit x86 machine. It probably won’t work on Windows or a Mac, and it definitely won’t run on your SPARC.
Second, I used version 3.3 of gcc’s compiler. Newer versions contain checks to make stack smashing harder, but 3.3 is free of any of these security features. You’ll have to use it when compiling these, which can be done by issuing gcc-3.3 -o <name> <name.c>, like:
gcc-3.3 -o exploit exploit.c
Third, Linux kernels after 2.6.12 do virtual address space randomization, which will prevent the exploit from running successfully after being compiled. To disable this, issue (as root):
sysctl -w kernel.randomize_va_space = 0
Fourth and finally, if you want to trigger a core dump in the vuln program, you have to lift any restrictions on dumping core files. Something like the following should work:
ulimit -c 100000
Note that the shellcode file is superfluous, I only included it as an example and guide.
Next Time
At this point, I’m not sure what I’ll be covering next week. There is a lot I could do – writing shellcode, showcase more advanced shellcode, demonstrate gaining a remote shell (remote exploitation is a whole other beast), secure coding, polymorphic and self-modifying shellcode… there are a lot of topics, and only one lecture left before the end of the series.
Regardless, it will be fun, and we’ll all learn a hell of a lot.
I’ll be at Barcamp Rochester 3 this Saturday in GCCIS, and more likely than not I’ll be talking about anything and everything computer security. If you have any questions anything or find something I’ve said interesting, hit me up! I’m friendly, and always up for talking about computer security :)
When targeting an individual host, the first step most attackers take is to scan and probe the system in order to gather information about it. Most generally this means scanning the system with nmap, determining open ports to find what the machine is serving, identifying the version of each service available, and then attacking the vulnerable ones.
The game changes when the attacks are automated, such as when they originate from a worm. Worms rely on only a select number of attack vectors, and without being artificially intelligent, are not capable of identifying and attacking new vulnerabilities. This means that when a worm scans, it is probing machines to determine whether they susceptible to a specific set of attacks.
But scanning is hard. It is slow. With the 2^32 addresses that exist within the IPV4 space alone, scanning with only one host can take an incredible amount of time. IPV6 is even worse. With a 64 bit address space and thus 2^64 addresses, the conventional means of scanning are extremely inefficient – a fact the IETF is well aware of. So now attackers and worm writers are faced with a new problem: how can we make this process faster?
I have an idea for a solution, and a proof-of-concept in the works to demonstrate it. Why not use IANA themselves to help? My solution involves not increasing the speed of the actual scanning, but by increasing the intelligence with which hosts are chosen to be scanned. The allocated IP blocks are published by IANA and made publicly available. Take a look at it: 41 /8 blocks are unallocated and 36 are reserved, dropping our problem space down by 77 /8 blocks. If the scanner was particularly stupid and was previously scanning the full range of IPs, this would result in 1,296,908,325 less addresses to scan, increasing our theoretical speed for a complete scan by 30%. When you are talking performance in computer science, a 30% speed increase is a big deal, and to a worm author, that relates directly to faster propagation.
The improvements are even more drastic for IPV6. Blocks of IPs cost money, so they won’t be snatched up immediately. Scanning only the allocated blocks of IPs means that the 64 bit problem space becomes less ominous. If we consider that the transition to IPV6 will occur when most addresses in the IPV4 space are used, then intelligently scanning only those addresses results in a 1.84×10^19 reduction in hosts to scan.
The long and short of it is that scanning isn’t likely to get much faster, but intelligently choosing what is scanned can produce real results that only lose effectiveness as the number of actual hosts increases. I’ll post a POC in some time that will showcase this methodology, so keep your eyes locked ;)
On Tuesday I gave the first of a series of lectures following the “hacking” track. I’m staying far, far away from an IT perspective – I’m not teaching nmap or how to use wireshark, nor am I discussing web vulnerabilities. No – I strive for a higher path, focusing the audience on dodging the skiddie [1] bullet and pointing them toward the real stuff. The talk went well, the audience was very engaged, asked great questions, and had good ideas when I asked for them. 98% of the content was in the talk, but as promised, the slides are now available for your viewing pleasure.
View the presentation here (Google docs, no download necessary).
There are varying requests for where to go next in the series. I had originally planned on gradually introducing more complex topics over a set of three lectures, hence the very general nature of the first. However, the group that came seems more interested in jumping directly to application, requesting a live demo of an exploit and accompanied explanation. When this idea was first presented I was a little hesitant – I was hoping to give people the knowledge necessary to be a jumping point, this is a little more direct. While it will take a lot more preparation, I think I’m going to end up using a demonstration to fuel my next lecture, conflating theory and practice.
A couple questions were asked that I think deserve more attention than I could give them on Tuesday:
Q: Are people who use Gentoo and compile everything more secure than someone who uses prepackaged binaries?
A: Absolutely not. The argument provided in conjunction with the question was that some compiler flags may change the layout of the program in memory, thus making new exploits developed for common versions of programs ineffective against the customized versions. Yes, there are a number of cases where this may be true, but that number is likely negligible. Compilers modify logic, unroll loops, and handle other things that have to do with instructions – rarely do they modify data, which is what we care about in the track we are following. Because the stack isn’t modified so heavily that the vulnerable components are removed, a bigger NOP [2] sled is often all that is required to have the same exploit work on your optimized code.
There are exceptions to this, but not in optimization flags. Introducing canaries is an option that is available to use when compiling with certain versions of GCC [3]. Canaries are simply two modifications: the first is introducing a random integer to a variable that gets placed between the rest of the stack frame’s variables and return address, and the second is a simple conditional that checks the value of that number. If the number is overwritten by whatever data we used in overwriting the return address of the stack frame, the conditional check will fail, and the program will exit with an error indicating a failed canary check (usually a reason for an admin to show concern). This is the only current compiler flag option I know of that will stop non-specialized exploits from delivering their payloads to your box.
More important however is the need to address the question’s ignorance. The short and correct answer to the question is “no, in fact you are less secure.” Feeling invulnerable is the most dangerous thing you can do for the security of your systems. It doesn’t matter how your binaries are obtained and compiled – if a vulnerability exists for the version of the program you are using, you are vulnerable. Your intermediate steps may have bought you time, but feeling safe causes complacency, and the second you feel complacent is the same second the security of your system is philosophically compromised.
Q: Isn’t it true that operating systems are running most programs in ring0?
A: No; in fact, the opposite is true. The full question was posed using language and concepts that hadn’t been introduced yet, so for those that were just being introduced to the field it was a bit foreign. Ring0 and Ring1 respectively refer to kernel and user space, which are concepts in operating system design that separate the operating system’s running components from programs the user runs. Without a separation, a user would have the ability to modify the kernel’s components which is a Bad Thing ™.
From the definition above, it should be obvious why the answer to the question is no. It is true that all programs make calls to kernel space functions exposed through an operating system’s API, but at no point does the user’s program enter the kernel itself to execute code. This was not always the case, but it has been for the last several years, and the separation only grows more defined with each new generation of operating systems. Note that there are ways to get code running in kernel space through drivers or kernel hooking (check out rootkits if this line of research interests you), but it requires some trickery and administrative access on the machine – no normal program does it.
And with that, I’ll close. The next couple days will be spent in part preparing the next lecture in the series, where we’ll see a demonstration, some actual shellcode, and a dive into further understanding memory and the mindset of the innovative hackers that develop these techniques.
[1] Script kiddie, a wanna-be hacker that uses the tools and work of others without producing anything of their own.
[2] No operation. Just burns a CPU cycle and increments EIP, the pointer that tells the processor which instruction to execute next.
[3] The GNU C compiler.
I’ve been seeing a lot of sites throwing around a “how to reset BIOS passwords” tip that revolve around using the DOS/Windows DEBUG tool. In case you haven’t seen it, it goes a little like this:
- Create a boot floppy/disc with the debug tool on it
- Type -o 70 2e
- Type -o 71 FF
- Type quit
- Reboot
Curious as to why this works? So was I, but none of the sites I saw included an explanation. So after some googling, I uncovered the nitty-gritty details.
The CMOS memory is actually accessible to the user for reading and writing. I’m not aware of a recent operating system that doesn’t restrict write access to the administrator/super user, but it is there nontheless. It contains a lot of information, such as the system time (direct access to the real-time clock), BIOS information, and CMOS data. With this knowledge, I would suggest taking a look at this link, which is a reference to how the CMOS memory is laid out. It is what I used to determine what the hex values being output were doing.
The -o option of debug just outputs a value to an io port. The CMOS memory is accessed through ports 70 and 71, which explains the first parameter of the steps above. The second part can be seen from the CMOS reference I linked to above – by latching the address 0×2e for writing, and then setting its value to 0xff, we are manually telling the CMOS that it has an invalid checksum. The behavior when this occurs is to revert to the default BIOS, a feature which is supported independent of operating system or processor architecture – ie, any AT/ATX motherboard will do this.
None of the sites list instructions for if you are a Linux user, and assume you’ll have access to the debug program. So, now understanding how this specific utilization of debug worked, I wrote my own version in C. It can be compiled using gcc, and is compatible with all *nix distributions – so add it to your rescue LiveCD toolkit, you never know when you’ll need it :)
Here is the source:
resetBIOS.c
#include <stdio.h >
#include <stdlib.h>
#include <unistd.h>
#include <sys/io.h>
/* Written by Robert Peaslee - www.robertpeaslee.com */
/* compile: gcc -o resetBIOS resetBIOS.c */
/* Run as superuser. */
int main() {
/* Allow writing to ports 70 and 71 */
if( ioperm(0x70, 1, 1) || ioperm(0x71, 1, 1) ) {
perror("Error setting write permissions");
printf("\n");
exit(1);
}
/* output 0x2e to port 70, which is the address where the
* CMOS checksum is stored */
outb(0x2e, 0x70);
/* Small sleep to allow the changes to take effect. */
usleep(100000);
/* Tell the CMOS that the checksum is bad, forcing it to
* load the default BIOS on reboot. */
outb(0xff, 0x71);
/* Reset the port permissions to not be writeable */
if( ioperm(0x70, 3, 0)) {
perror("Error restoring permissions");
printf("\n");
exit(2);
}
exit(0);
}
And if you only want the assembly specific portions without relying on external libraries:
out 70, 0x2e
out 71, 0xff
…but note you’ll have to add your own data/text sections and a main: entry point if you want to actually assemble it. Additionally, you’ll have to convert this to at&t syntax if you want to inline it in C code using the gcc compiler.
So there you have it – a full explanation of why it works, an example in C, and a complete reference of the layout of CMOS memory. If you still have questions, leave them in the comments!
