Linux 3.2 - 4.9 Exploit
Su Strawderman
The Exploit Database is maintained by OffSec, an information security training company that provides various Information Security Certifications as well as high end penetration testing services. The Exploit Database is a non-profit project that is provided as a public service by OffSec.
The Exploit Database is a CVE compliant archive of public exploits and corresponding vulnerable software, developed for use by penetration testers and vulnerability researchers. Our aim is to serve the most comprehensive collection of exploits gathered through direct submissions, mailing lists, as well as other public sources, and present them in a freely-available and easy-to-navigate database. The Exploit Database is a repository for exploits and proof-of-concepts rather than advisories, making it a valuable resource for those who need actionable data right away.
The Google Hacking Database (GHDB) is a categorized index of Internet search engine queries designed to uncover interesting, and usually sensitive, information made publicly available on the Internet. In most cases, this information was never meant to be made public but due to any number of factors this information was linked in a web document that was crawled by a search engine that subsequently followed that link and indexed the sensitive information.
After nearly a decade of hard work by the community, Johnny turned the GHDB over to OffSec in November 2010, and it is now maintained as an extension of the Exploit Database. Today, the GHDB includes searches for other online search engines such as Bing, and other online repositories like GitHub, producing different, yet equally valuable results.
Hi folks, in this post I'm going to walk through how to setup the linux kernel for debugging. I will also demonstrate that the setup works by setting a break-point to a test driver I wrote myself. All the code will be available from my gitlab, all the links to my gitlab will be re-posted at the end.
The setup I describe here re-uses some parts of the syzkaller setup, and for good reason later on in the post series I will break into a tutorial for the syzkaller tool as well. So lets get on with it.
Okay so we want to study kernel exploitation but given that the kernel isn't something totally accessible in userspace, its not as convenient to debug as userpace stuff, we need a bit of a run up before we can actually poke and prod the kernel to figure out how to write our exploits. So there's a number of important steps to how we get this done, here's what we're going to do:
We also need to be able to build our kernel because there may be build options that are important to configure in order to control exploit protection or include modules and functionality to the kernel when needed.
Okay so before we get going with launching our Qemu instances and debugging modules we need an environment. For convenience sake I'm working off of a fresh Ubuntu 18.04.5 LTS machine. I'll document the processes from fresh install to first successful kernel build.
We're just a couple steps from sending the final build commands, before we get to that lets make sure the kernel config is ready to rock. Because we're working on a Linux host we can simply swipe the .config for the virtual machine's Ubuntu kernel like so:
Great, now we need to enable some options for debug symbols, kaslr and other awesome things. So open the .config somewhere in a text editor and make sure you either add or modify the file so these options are set:
Once you're kernel is build we need to start thinking about how to build a file system for this. Here I'm going to cheat and steal some tips from the syzkaller folks. We need to first download syzkaller, as follows:
The -s is a shorthand for -gdb tcp::1234, which means the gdbserver will be hosted at port 1234. -S tells qemu not to start the cpu automatically, this gives us a chance to set a breakpoint before the kernel starts executing.
We give the "c" command to continue execution. We can now set some of our own breakpoints. As part of the tutorial I've included a custom IOCTL driver and app code (code that invokes the ioctl from userspace), i thought this would be nifty since it shows full ability to develope and debug a driver, something crucial to hunting down modern bugs and exploit development. Anyway lets code and build our own module.
The code for debug_driver.c and debug_driver_app.c as we well as the Makefile are available at this repo -kernel-exploit-development. All you need to do is download the repo and stick this in its own folder under [kernel_dir]/drivers/. To build the module the we need to set the "M" variable in the kernel make script:
Now we need to get this module on our qemu host somehow, I do this the hard way, I'm sure there's all sorts of nifty ways to scp files onto the qemu host but I actually just re-create the image after copying the drivers to a folder to be baked into the start up filesystem. First we need to edit create-image.sh so it includes everything in a folder we specify, that way we can just dump stuff in the folder and run create-image.sh whenever we want those files on a live instance.
Okay so we have a module, we have a symbol file debug_driver.ko, with stuff we need to set breakpoints. Lets load the module into the kernel, then check where it gets loaded before we actually set the breakpoint:
So thats the breakpoint hit! We achived our goal for this post, if you'd like to explore more try setting more breakpoints and before moving on to the next post make sure to get your gdb foo up. Next post is going to look at exploitation of stack vulnerabilities.
I keep getting this when I start to exploit, trying to exploit my xp machine but this keeps happening, I can not find the fix anywhere, I don't believe I am the only one getting this..I am a beginner, just putting it out there.
You asked this question and it was downvoted before. There could be a lot of reasons for this happening, your question is too broad, and lacks a lot of relevant information. For example, can you ping that host, is it running a firewall, it is vulnerable to that exploit. What you are experiencing is the host not responding back after it is exploited. This could be because of a firewall on either end (the attacking machine, the exploited machine). I would start with firewalls since the connection is timing out. From there I would move and set a different "LPORT" since metasploit tends to act quirky at times. E.g., set LPORT 2468. If that doesn't work, then jump on the metasploit forum and ask there, you'll likely get an accurate explanation.
I am currently attempting Blue and it seems to successfully establish connection and send the payload (ETERNALBLUE overwrite completed successfully). But instead of a WIN I get a FAIL, and it restarts the process twice more. My process for debugging has been:
I uninstalled metasploit ( sudo apt-get remove --auto-remove metasploit-framework ) and then re-installed the new build from their github repo. Installed it in my /opt folder and then installed all the dependencies (a bunch of ruby gems that will probably need some manual dpkg installs themselves) and now it works.
I ran into this problem just now on Lame as well and was able to figure it out. My guess is the actual exploit itself has changed since the walkthroughs were written, or else maybe my metasploit somehow was different.
Hey I just want to say thank you for the help. I was having the same issue with Metasploit as the members above, in that it was not giving me a session. I had to change the payload and it worked perfectly. I was working on Blunder for 3 days and could not figure out what I was doing wrong. Thanks for tip of changing the Payload.
I am having a similar issue with Lame. Everyone keeps saying make sure to set the payload within the exploit which I keep trying to do, there are quite a few meterpreter payloads and ive tried most of the Linux meterpreter payloads but it is not letting me set it as there is a some sort of error I get when I try to set it.
this you it helped me, the error was that I was configuring LHOST with my wlan0 ip instead of the ip that the vpn assigned me (in my case was tun1). Once i changed the parameter i was able to use the reverse_tcp without problem
Then go back into the extracted folder and use this command to get all the gems for metasploit: bundle install
**Keep in mind you might have to do bundle install a few times later on so make sure you go into the metasploit extracted folder before you do bundle install
Nice. I thought about doing this and may still downgrade. I found another way around my problem using a different problem but still a bit worried about the transition between python2/msf5 and python3/msf6 as someone new trying to follow tutorials
Cybersecurity researchers have disclosed what they say is the "first native Spectre v2 exploit" against the Linux kernel on Intel systems that could be exploited to read sensitive data from the memory.
93ddb68554