The De-ICE pentest LiveCDs 1.120a and 1.120b were released quite a while ago. I tried them out yesterday and managed to successfully work through both of them.
As a few people (e.g. g0tmi1k) have already put up excellent walkthroughs for them, I won't be doing so. Here, I will just mention a way to cut out part of the merry goose chase in 1.120b. This will allow you to skip the part on using cupp, but you would still need to repair and combine the java file.
Basically, after you manage to get a non-root user account on the box, take a look at the kernel version. It is 2.6.16. This box is vulnerable to the Linux Kernel 'udp_sendmsg()' MSG_MORE Flag Local Privilege Escalation Vulnerability. As gcc is not installed on the box, compile statically the publicly-available exploit on your attacking box. Then transfer the resulting executable onto the box and run it to get root. This should cut out the hassle of having to compromise the other 2 user accounts. Unfortunately, to achieve the goal of this pentest, you would still need to put the java file together to get the password to decrypt the accounts file. g0tmi1k has already covered this last part in good detail.
Wednesday, April 18, 2012
Wednesday, March 7, 2012
NULL
I have been reading up on linux device drivers recently and decided to write a simple device driver for fun. To make things more interesting, I included a blatantly obvious null pointer dereference vulnerability in the driver. And of course, I wrote an exploit for it as well, taking reference from the various exploits that can be found online. Note that this is purely an exercise and the code will not be very useful in real-world applications.
I will broadly explain how it works below. But a thorough explanation would probably require multiple pages, so I will leave it to the reader to search and read through the relevant information in books, manuals and online articles.
In C, a pointer is an integer that refers to a location in memory. When you want to load (or write to) the value that exists at this location via the pointer, you would be dereferencing the pointer. In C, a NULL pointer is a pointer with the value 0. This NULL pointer does not correspond to any valid memory by default - trying to dereference it will lead to a segmentation fault.
However, due to how virtual memory is implemented in linux (where the kernel space and user space share the same virtual address space), we can actually map NULL to a valid address. This can be done via mmap(). If done correctly, dereferencing the NULL pointer would then no longer crash the system. In fact, if we place our own function pointer at this valid address, the kernel will execute our code in kernel mode.
In a nutshell, this is what I have done in the exploit for my basic device driver. If you want, you can download dearmo-driver1.zip here. As there is a chance that the code will screw up your system, you probably should run this in a non-critical virtual machine. I wrote and ran the code on Fedora 14 with kernel 2.6.35.6-45.fc14.i686, but it should work for all kernel versions 2.6.29 and up.
3 files are included in the download: dearmo-driver1.c, Makefile and rootnull.c. To set up the system, and to compile and load the device driver, execute the commands below.
#echo 0 > /proc/sys/vm/mmap_min_addr
#echo 0 > /selinux/enforce
$make
#insmod dearmo-driver1.ko
There are still a few more steps to take after this. Refer to the comments/information in the dearmo-driver1.c file. After that, compile the exploit rootnull.c, then execute it.
$gcc rootnull.c -o rootnull.out
$./rootnull.out
And we have root.
I will broadly explain how it works below. But a thorough explanation would probably require multiple pages, so I will leave it to the reader to search and read through the relevant information in books, manuals and online articles.
In C, a pointer is an integer that refers to a location in memory. When you want to load (or write to) the value that exists at this location via the pointer, you would be dereferencing the pointer. In C, a NULL pointer is a pointer with the value 0. This NULL pointer does not correspond to any valid memory by default - trying to dereference it will lead to a segmentation fault.
However, due to how virtual memory is implemented in linux (where the kernel space and user space share the same virtual address space), we can actually map NULL to a valid address. This can be done via mmap(). If done correctly, dereferencing the NULL pointer would then no longer crash the system. In fact, if we place our own function pointer at this valid address, the kernel will execute our code in kernel mode.
In a nutshell, this is what I have done in the exploit for my basic device driver. If you want, you can download dearmo-driver1.zip here. As there is a chance that the code will screw up your system, you probably should run this in a non-critical virtual machine. I wrote and ran the code on Fedora 14 with kernel 2.6.35.6-45.fc14.i686, but it should work for all kernel versions 2.6.29 and up.
3 files are included in the download: dearmo-driver1.c, Makefile and rootnull.c. To set up the system, and to compile and load the device driver, execute the commands below.
#echo 0 > /proc/sys/vm/mmap_min_addr
#echo 0 > /selinux/enforce
$make
#insmod dearmo-driver1.ko
There are still a few more steps to take after this. Refer to the comments/information in the dearmo-driver1.c file. After that, compile the exploit rootnull.c, then execute it.
$gcc rootnull.c -o rootnull.out
$./rootnull.out
Wednesday, February 15, 2012
Reflections and a brief review of OSCE
Wow. I am still in awe right now.
I enjoyed the OSCE exam and the CTP course immensely. The Offsec folks have done a great job of putting the CTP course together. It is by no means an easy course, and much more complex than PWB. Of course just like PWB, no spoon-feeding is involved. Instead, the course materials equip you with the essential concepts and the knowledge to use various techniques.
Finding out when and why to apply the concepts and techniques however, is entirely up to your own study, research, practice, practice and practice.
And that, I believe, is the way it should be. That is what hacking (in the strictest positive sense of the word) is all about.
I studied really intensely for this course, way more than PWB. Part of the reason is that there's hardly any information online about what the OSCE certification exam would entail. All I knew was that there would be a few challenges, and that I needed to complete them within 48 hours. Hence, I wanted to cover all bases. The main reason however, was that I simply could not stop learning. Studying for CTP opened a door where a new and wondrous world awaits. In fact, I learnt so much that I found myself deep in AWE territory. Still, it was all good.
Having already gotten a sense of how an Offsec exam works from OSCP, I felt little stress going into the OSCE exam. I won't elaborate on the exam, but well, if you understand the concepts taught in CTP, you should do fine. 48 hours will be more than sufficient - I was jumping around with elation by the 30th hour. But if you haven't fully grasped the concepts, I would venture to say that you won't be able to crack the more difficult challenges even if you have a week.
All in all, it was one of the most satisfying experiences of my life. Looking back, I am quite overwhelmed by my journey from PWB to OSCE in the past half-year. It's as if I have completed a long and rewarding trek up a mountain. Yet, at the end of the trek, I discovered that I have not reached the peak. I have reached something even better. I stand only at the foot of Mount Everest. And a new journey awaits.
As Buzz Lightyear would say - To infinity and beyond!
Add.: I can't believe I quoted Buzz Lightyear.
I enjoyed the OSCE exam and the CTP course immensely. The Offsec folks have done a great job of putting the CTP course together. It is by no means an easy course, and much more complex than PWB. Of course just like PWB, no spoon-feeding is involved. Instead, the course materials equip you with the essential concepts and the knowledge to use various techniques.
Finding out when and why to apply the concepts and techniques however, is entirely up to your own study, research, practice, practice and practice.
And that, I believe, is the way it should be. That is what hacking (in the strictest positive sense of the word) is all about.
I studied really intensely for this course, way more than PWB. Part of the reason is that there's hardly any information online about what the OSCE certification exam would entail. All I knew was that there would be a few challenges, and that I needed to complete them within 48 hours. Hence, I wanted to cover all bases. The main reason however, was that I simply could not stop learning. Studying for CTP opened a door where a new and wondrous world awaits. In fact, I learnt so much that I found myself deep in AWE territory. Still, it was all good.
Having already gotten a sense of how an Offsec exam works from OSCP, I felt little stress going into the OSCE exam. I won't elaborate on the exam, but well, if you understand the concepts taught in CTP, you should do fine. 48 hours will be more than sufficient - I was jumping around with elation by the 30th hour. But if you haven't fully grasped the concepts, I would venture to say that you won't be able to crack the more difficult challenges even if you have a week.
All in all, it was one of the most satisfying experiences of my life. Looking back, I am quite overwhelmed by my journey from PWB to OSCE in the past half-year. It's as if I have completed a long and rewarding trek up a mountain. Yet, at the end of the trek, I discovered that I have not reached the peak. I have reached something even better. I stand only at the foot of Mount Everest. And a new journey awaits.
As Buzz Lightyear would say - To infinity and beyond!
Add.: I can't believe I quoted Buzz Lightyear.
Tuesday, February 14, 2012
Offensive Security Certified Expert
After one month plus of intensive study and practice, I have passed my CTP (Cracking the Perimeter) Certification Exam! I am now an OSCE.
Saturday, February 4, 2012
Fuzzy Fuzzing
You know you have been doing too much fuzzing when you see "%%%%%..." and think that it is a string of "/////...".
Anyway, I have been fuzzing stuff the whole day, without much success. Taking a break, I coded a basic fuzzer, which provides me with good control over the length of the fuzzing strings. It can be found here: http://code.google.com/p/dearmo-projects/downloads/list. Or this older page.
dearmo-fuzzer.py is also a billion times easier to install than Sulley...
Still, if you need a more comprehensive scanner, try out Dave Aitel's SPIKE, or Pedram Amini's Sulley instead.
Anyway, I have been fuzzing stuff the whole day, without much success. Taking a break, I coded a basic fuzzer, which provides me with good control over the length of the fuzzing strings. It can be found here: http://code.google.com/p/dearmo-projects/downloads/list. Or this older page.
dearmo-fuzzer.py is also a billion times easier to install than Sulley...
Still, if you need a more comprehensive scanner, try out Dave Aitel's SPIKE, or Pedram Amini's Sulley instead.
Wednesday, January 18, 2012
Finding ROP Gadgets
I have been having fun with ROP (Return Oriented Programming) based exploits recently. I used to use the pvefindaddr plugin by Corelan for Immunity Debugger to hunt for ROP gadgets.
Lately though, the search functions of Immunity Debugger have really grown on me, so much so that I don't use the pvefindaddr plugin anymore. (I haven't tried out the capabilities of the mona.py plugin in this area though.)
Anyway, if you want to give the search functions in Immunity a go, try out the keywords CONST, ANY, R32, JCC, etc. You may be surprised at the flexibility offered.
Lately though, the search functions of Immunity Debugger have really grown on me, so much so that I don't use the pvefindaddr plugin anymore. (I haven't tried out the capabilities of the mona.py plugin in this area though.)
Anyway, if you want to give the search functions in Immunity a go, try out the keywords CONST, ANY, R32, JCC, etc. You may be surprised at the flexibility offered.
Thursday, January 5, 2012
Subscribe to:
Posts (Atom)