Tag Archive for 'society-of-lectors'
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 :)
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.
More updates for the Society of Lectors!
The next group of lectures is occurring tomorrow, Tuesday March 24th, 2008 in the first floor auditorium (room 1400) of GCCIS (building 70) at RIT. We are meeting at 8:00PM, and this new day and time has been settled on for the near future.
The reason I’m especially excited about tomorrow is that I am lecturing! I’ve been given the go-ahead to give a series of lectures on shellcode, a fairly heady computer security topic that is never taught in classes. Part one of the series is a very general, non-technical overview and topic introduction that is accessible to those of all backgrounds. After building a solid base of understanding, we’ll really dive into things with later lectures. Afterward, I’ll post the slides here and to the Society of Lectors group, as well as publish a corollary technical component for those that didn’t have their appetites whetted by the presentation. My blurb:
Computer hackers continue to be the bane of the networked computer – but have you ever wondered exactly how they strike? In part one of this series, we will dive into a very accessible view of how they gain control of computers they do not possess.
Heewa Barfchin is also presenting on neural networks from biological and computer model perspectives. Tomorrow should be great!
The Society of Lectors is a new group at RIT with the goal of enriching participants through lecture and discussion. Founded as an idea by Heewa Barfchin and further realized with help from David Brenner, the group promises to deliver an education beyond what can be taught in the classroom.
The first lectures will be this Wednesday, March 19th, in one of the labs on floor three of GCCIS (building 70) at RIT. It is open to all people from all backgrounds, as a diverse group of people only stands to enrich the experience for everyone. Heewa and Dave will be the featured lecturers, with things kicking off at 8:00pm.
The full details are in this post. I’m personally looking forward to it, and encourage everyone in the area to come check it out!
