ret2libc Attack | Smashing Stack for Root Shell

Hello guys,

From last couple of days, I was solving some buffer overflow challenges in protostar, and the last two challenges of stack buffer overflow, was stack6 and stack7, and literally I spent about 3 days in solving stack6.

And stack6 and stack7 are pretty much same, so I solved stack7 within 10 minutes.

During solving stack6, I was stuck at a point, which took me about 3 days to solve. Maybe I am a loser that's why.

But I thought to share what was the problem and what is the solution of this thing.

So I made a video on this thing,

Hope you'll like this video, and If you have any queries you can ask me through comments, or on twitter.

Changing code flow in Protostar | Stack 3

Hello guys,

So today I'll be talking a li'l bit about how I solved Stack 3 challenge in Protostar, which was to change the code flow of the program.

If you're wondering what is protostar, it is an OS based on linux. Designed just to practice your binary hacking skills.

You can download protostar from here : https://exploit-exercise.com

So first, I looked at the code of the vulnerable program which is available on the website itself.

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

void win()
{
  printf("code flow successfully changed\n");
}

int main(int argc, char **argv)
{
  volatile int (*fp)();
  char buffer[64];

  fp = 0;

  gets(buffer);

  if(fp) {
      printf("calling function pointer, jumping to 0x%08x\n", fp);
      fp();
 }

}

So this is the code on the website.

Now if, you look at the code, you'll notice that, this program will never go to void win() function.
It will jump to memory address fo fp(), which will never be equal to win().

If you know li'l bit of C language then it's easy for you, to understand.

Now, if you notice there is one more interesting thing in this code i.e. it is using gets() function, which is vulnerable to buffer overflow vulnerability.

And now we have one way to exploit this vulnerability but for me that's a li'l bit tough, so I decided to choose the easy way, i.e. using gdb modify the address of fp() to win().

Then it will jump to win() function right.

So let's do this.

I made a video on it for better understanding here it is

 

Drop your comments in the videos, if something is weird for you.

24kpwn - 0x24000 Segment Overflow

Hello guys,

In 2k16 I got my first iPhone, and introduced myself to iOS platform. And after some months I jailbroke my device. After iOS 9.3 jailbreak by Pangu Team, it was tough for hackers to develop a jailbreak for iOS 10, but in the last months of 2k16, Google's Project Zero team released a 0-day vulnerability in iOS platform, through which Luca Todesco developed a jailbreak for iOS 10. And since then I got attracted towards jailbreaking and iOS kernel hacking.

But it was not easy, I first learned ObjC, then developed some useless tweaks and learned from other developers, but the main problem was to gather information about iOS kernel hacking. Everyone was giving me information about iOS App Hacking. Then I found a 16-year old guy (Billy Ellis), he is also a iOS hacker but he claims himself as a beginner, but he is actually a beast. He showed me right direction towards it and all.

So today I'll be sharing a little introduction to the first jailbreak in iOS history i.e. 24kpwn - 0x24000 Segment Overflow. So I was reading about this exploit and I learned that hacking is not just about hacking into web applications, wordpress, unprotected cams, defacing websites and all.

So let's get started, before starting let me introduce you with some term so that you don't get confuse.

LLB         - Low Level BootLoader
SRAM     - Static Random Access Memory
IMG3      - New version of IMG2 used during iOS boot.
S5L8720 -  Application Processor
S5L8920 - Application Processor
NOR       - NOR flash memory(memory that can be erased and reprogrammed electrically)
IDB         - Debugging Process
SoC         - System on Chip

I think I introduced all the terms which I'll be using in this post.

What is 24kpwn? 

24kpwn is also known as 0x24000 Segment Overflow, which was found by some researchers in first iPod Touch 2G, which allowed to bypass the bootrom signature checks on LLB and finally getting the untethered jailbreak. And after that in October 2009 Apple patched this vulnerability.

Background :-

When the device boot up, the S5L8720 and S5L8920 have MIU configuration which maps the Secure ROM to 0x0 address, providing the newly turned on device with an ARM exception vector and the first code to execute. This MIU configuration also maps out some SRAM to 0x22000000 for the S5L8720 and 0x84000000 for the S5L8920. And the statically allocated variable, heap and stack must use SRAM, as Secure ROM is unwriteable. A region of memory starting from (SRAM Start)+0x24000 used as a buffer for loading the next stage of bootloader, which is simply some LLB code stored in NOR. And this NOR is stored with LLB code along with other bootstages codes such as boot logos and all, which is provided to the XNU Kernel. Now the first portion of 0x160 bytes of memory at (SRAM Start)+0x24000 is used for initialized statically allocated variables. And after the boot, values for that region are initialized from Secure ROM.

Vulnerability :- 

Now nothing looks fishy here, then where is the vulnerability. The vulnerability was in the code which copies the LLB IMG3 file from NOR into the memory, but it doesn't checks the size of the LLB image being loaded, instead of it it takes the whole size from the non-signatured portion of the IMG3 header of the NOR (ROM Offset 0x2178). Any image greater than 0x24000 bytes in length will begin overwriting the portion of memory used to store Secure ROM statically allocated variables.
And this vulnerable data includes USB data structures for DFU mode, a pointer to the bdev list structures for the Secure ROM's scheduler, as well as the addresses of the hardware SHA1 registers. All of these are potential avenues for exploitation.

Exploit :-

The goal of the exploit was gain the arbitary code execution capability.
The exploit uses the overflow to overwrite one of the address in SHA1 registers which is the only one responsible for copying the hash code into hardware. Code execution is achieved by specifically by overwriting the LR of the function performing the write to the "SHA1 register" so that instead of returning to the main SHA1 routine it will return to a chosen location in the memory which contains the payload code. And the location chosen is within the memory filled with the LLB's IMG3, so that payload can be placed with LLB's IMG3.
The challenge is to determine where to put in as the SHA1 register location so that the right portion of stack can be overwritten with the payload LR. This was tough without having access to any sort of exception dump & Apple already disabled the crash register dumps in bootrom. And finally after performing the static analysis of a very detailed IDB and theoretically call stack for both the invocations of SHA1 hardware within the bootrom code, they discovered a way to alter IMG3 DER so that the second invocation of the SHA1 hardware was not performed without affecting the first.
The final SHA1 register address was chosen so the first dword of the DATA tag of the LLB IMG3 would replace sub_5E54's LR. This is because the first dword of the IMG3 that can be altered without changing the IMG3's structure. The LR replacement must be done the first time the exploit is triggered, or else the bootrom will crash. Since sub_5E54 takes first 0x40 bytes of data at a time, the replaced LR should be within 0x40 bytes of data to be hashed. Data be hashed starts at 0xC bytes from the start of IMG3, and the first dword of the DATA tag id 0x20 bytes the start of IMG3. Thus the chosen SHA1 register address was 0x20-0xC = 0x14 bytes before sub_5E54's LR. So it must be 0x2202FE24. Note that the exploit will also be trash up 0x2202FE24 + 0x40 = 0x2202FE64. So the sizable portion of doComputeSHA1's stack will be trashed as well.
So the final exploit IMG3 was a regular IMG3 with padding up to 0x24000 bytes. The next 0x100 bytes were taken from the original initialization values for 0x22024000. However 0x240FC, the offset of SHA1 register address was altered to 0x22023000. Payload code was placed at 0x23000.

Payload :-

Now we know how it will exploit, now what is the payload.
So the goal to the payload was to allow unsigned LLB to be loaded.
There are several ways to do this, one of them was to simply use JumpToMemory function which is designed to prepare SoC and invoke the LLB code. However it is designed to be used on decrypted code and the LLB code is currently resides in the encrypted form within IMG3 DATA tag. The simple solution for this on ewas to simply use Apple's own bootrom machinery to decrypt and execute the code.
Then the final payload was to return past the verification of epoch and other tags in the LLB's IMG3 to a spot right before the DATA tag was loaded from the memory and decrypted. R5 was to set to 0, to ensure decryption would not be skipped. And then the original value of DATA dword is written back to 0x22000020 by the payload , and the original SHA1 register value was written back to 0x2202FE24 to ensure that it will only activate once.


I know this is pretty confusing, I read this thing over and over to understand what's happening.
Hope this will help you in your hacking career. For any queries drop a comment, I'll try my best to clear those.

Thanks

How to add auto-update feature in Python

Hello guys!

It is a bit different topic, I am discussing on my blog.

When I was developing BruteXSS, I faced some difficulties, as I am new to GUI development and don't know how to do all these things. During mobile app development, we don't need to worry about Auto-Update and all, because Play Store do this on its own.

During developing BruteXSS, I wanted to add auto-update feature in python but their was no such library or pre-written code, or simply can't find any python tools out to copy and paste their code.

So I did one thing, I added a line in my tools " __version__ = '1.0' " to know which version is this tool running.

Then on my github page I added a simple txt file written "1.0".
Simple
Now whenever I need to send an OTA update to all my users, I simply change the version to "1.1" or so on on my github page and everytime the tool launches it retrives that data from my github page and check whether it is same or changed. If it is changed then show an Update Alert else continue.

Here is a sample code, that I added in my BruteXSS tool :


        versionfile = urllib2.urlopen('https://raw.githubusercontent.com/rajeshmajumdar/BruteXSS  
                                                        /master/version.txt').read()
        if float(versionfile) > float(__version__):
            updatefunc()
        else:
            print 'Already a updated version'
            start()

These five lines of code added an awesome feature in my tool.

Hope these lines will help you in building your new tool.

BruteXSS - A Cross Site Scripting Bruteforcer

 

 BruteXSS - A cross site script bruteforcing tool.

Hello guys, You all must have heard about XSS vulnerability and most of you must know about this vulnerability. This vulnerability has a high severity, you can pretty much do anything with this vulnerability. 

Either play with it, through showing alerts, prompts or get a shell. Basically this was "Shawar Khan's" idea, he designed the original version of this tool i.e. in CLI (Command Line Interface), and it got a pretty good success.

Therefore I just redesigned it into GUI (Graphical User Interface), and all the python programmers out there, you pretty much know that coding in CLI and GUI are different, we can't just copy and paste the code.

You can grab this tool from my Github. 

I added some additional features with this tool like Auto-Update, Threading (for faster result) and much more.

 

iOS Sensitive Information Dislosure Vulnerability

Hello guys,

Today I'll share my second PoC in iOS app, this vulnerability was not too tough to find so I think that's why it got duplicate. You just need to have some patience, and you too can find this vulnerability. 
But to exploit this vulnerability the victim device should be jailbroken that's the only problem.

I found this vulnerability in an instant messaging app, which has a public program on Hackerone.

iOS is pretty secure, it uses many techniques such as sandboxing most common to prevent to be hacked, I think that's why developers don't care about these little things.

As this vulnerability got duplicate but the bug is not patched, so I am not gonna tell it's name.

The vulnerability was I could get the whole user's database saved into the user;s device without any encryption. Whatsapp also uses this technique to save backup, but it uses encryption so that no-one can see it.
 .
Here I'll show you some images, in which you can see that what's I found there. 

 

 

 As you can see in the images, I didn't only got the database also my private keys and pretty much everything.

So basically I just found this thing just by diving into the filesystem, that's not a rocket science. Anyone could find these vulnerabilities.

Now the intresting part how you can exploit this vulnerability.

First thing you can do, simply unlock the user's device and go into filesystem, to get all those juicy informations.

Second using SSH, if the user have OpenSSH installed, and didn't changed his/her default password "alpine".

Third thing, you can do this by developing tweak. I am not gonna develop tweak here, but I'll tell you how the tweak will work.

To develop tweak to exploit this vulnerability, you don't need to hook into any application and run anything, but as every tweak needs to hook into something, so just hook into SpringBoard.

Now if you have developed it's pretty easy, put the Tweak.xm file in folder like 

/Library/mobile/Data/Bundle/Application/3HD7348HD7823-324UR2Y/Tweak.xm 

This is the same folder in which that application stored all it's info. Now just copy those db files and upload somewhere, simple right, or simply backdoor.

The intresting thing about tweaks is that they can don't care about sandboxing or any other rules.

But within 6 hours it got duplicate, LOW HANGING FRUITS

Sensitive Information in Buffer (iOS Application)

Hello guys, 

Today I wanna share one of my interesting PoC I ever found. First of all it is related to iOS application, secondly it needs more manual work rather then using tools and BOOM found.

In the starting of 2017, I started to learn about jailbreaking, and thought to contribute something to the jailbreaking world. Till now I developed some useless tweaks and I learned about how to read an iOS app, how it works and finding intresting things into.

Testing iOS applications is much more intresting than testing android application, because first of all Android is cross-platform, can be develop or read on any platform, but iOS is different you need a Mac OS to perform actions, and if you're like me, who don't have a Macbook, then it's pretty difficult.

There are some simple vulnerabilities like intercepting the ongoing requests and finding vulnerabilities in HTTP requests and responses, but thats too simple and chances are too low to find a vulnerability there. Then there is reverse engineering and finding vulnerabilities, that part is complicated. I already made a video on youtube showing reverse engineering a simple iOS application without Apple's DRM fairplay protection one.

Some days ago I got a invitation from a private website to test there iOS or Android application, as I was new and little bit confident in iOS application I chose to hunt for iOS application. Using the first method i.e. burpsuite I found banner disclosing, but that has low impacct and no complication at all, so I thought to find another vulnerability. Then I decided to reverse engineer that iOS app, using clutch &  IDA Pro. And started to see all the headers, and there I found something intresting.

Now in this image, as you can see there is header file called "logPreviousSessionCrashedOnDate", it shows that session is being destroyed by the app itself, not by the server, and if you look at the other part you'll see it is doing some calculations and all, to destroy that session, all that implies that session is stores somewhere in iOS, which would later destroy by the app.

Now I started digging into the filesystem, but there was nothing there, I was confused where the f*** it is storing that session, then I thought that cookies and session could be stored it memory using "NSHTTPCookies", I started finding that session in the buffer of the app, and not only I found sessionID in buffer also cookies in the buffer. Here is the screenshot

Well now how to exploit it, to get both fun & profit.

You could use cycript or just develop a tweak to get those sensitive information.

OK so after some finding I found a class which don't know do what, but it does something with the session IDs as per my understanding it is checking something in cookies or might be something else i.e. -[ANSUploader session]

Here are cycript commands to get those tasty cookies and session IDs.

cy# sessions = choose(session)

cy# sessions[0]

cy# sessions[0] -> isa.messages

Well after you could see the stored cookies and sensitive info, but I am little bit lazy to run all the commands again and again, that's why I simply developed a tweak to show that juicy info on the screen, as you can see in the above image.

Hope you'll also like this PoC as much I like this.