Wednesday, 10 April 2013

Finding Publicly Readable Files in your Amazon S3 Account

Amazon S3 is a cloud storage service which is used by thousands of Enterprises worldwide. The most common use case is data backups. Before going into the specifics, lets try and understand how Amazon S3 organizes data. A registered Amazon S3 user can organize his data (files) into Buckets. A file can be fetched using its unique key. The user can access his file using the full path 


In the above example is the bucket name and IP-Packet-Injection.c is the Key.

The service is great but is prone to easy misconfiguration by Sys Admins who may be new to the cloud. As lame as it might sound, the most common mistake seems to be to make your S3 data publicly readable. Robin Wood (@digininja) was the first to point this out and wrote a tool called Bucket Finder. Buckets with public-read have directory indexing enabled as an XML listing. The tool can try and download files from the bucket using the listing. Below is an example:

If a Bucket is private, we cannot fetch the listing:

However, interestingly files inside a private bucket could be mistakenly have public-read enabled on them.

What this means is that you could use tools which try to find "Hidden" files and directories on Web Servers in this scenario once you are aware that the Bucket exists but is private.

Recently the Metasploit team did some analysis on a larger sample of S3 buckets and published an article which confirmed that many Enterprises have misconfigured their S3 buckets to be publicly readable.

Now coming to the goal of this post: If you use Amazon S3 what should you do? Immediately check your S3 buckets for files and make any world readable files private, if you accidentally have them public right now.

If you have thousands of files, how would you check and do this? Definitely not manually :) In this post, I will show you how to trivially automate the process using a Python library called Boto.

Let us first try and understand how the permission sets look like from a programmer's perspective. Below is a simple script to learn about permissions:

Let us set the permission set to "private" on the bucket "hackoftheday" and see the response:

Let us now set the permission to "public-read" on the bucket "hackoftheday":

Fantastic! So we basically note that "READ" is set whenever "public-read" is there on the bucket. Please note that if you go through the documentation in detail, READ can also be set when you do not make the bucket publicly readable, but readable to an authenticated user on Amazon S3. This is unsafe as well as this could pretty much be ANY other S3 user.

Now, all we have to do is check for READ on every file our bucket to check if any of them were supposed to be private. Here is the code to do it:

Let us run this against "hackoftheday" now. The bucket itself is private but a file inside is public readable:

Lets check now:

Awesome! So you see how just a few lines of Python can allow you to create your own S3 scanner to ensure your S3 files are safe :) 

If you like Video Demos, please checkout my explanation here

If you are interested in learning how to use Python for Pentesting then please have a look at our SecurityTube Python Scripting Expert course. This course is ideal for penetration testers, security enthusiasts and network administrators who want to learn to automate tasks or go beyond just using ready made tools. We will be covering topics in system security, network security, attacking web applications and services, exploitation techniques, malware and binary analysis and task automation.We have students from 73+ countries taking this course already!

Friday, 5 April 2013

My Code made it to a Hollywood Movie

One of the first things I do every morning is check the Twitter chatter about my website (@SecurityTube) . I was pleasantly surprised to see this:

I've embedded the image from the tweet:


I've verified that this really is from the movie White House Down due for release in 2013 from their YouTube trailer at 1:39

The code is question seems to be from multiple programs which I had written way back in 2007-2008 to demonstrate the use of Raw Sockets in writing Packet Injection programs. Here is a list of the code files (GIST embeds at the end of the post) :

I know most of code snippet in the image could have been pretty much from any low level networking tool, so I am just going to focus on the comments :)  which are almost like a programmer's signature.

/* First Get the Interface Index */  and "Error getting Interface index !\n" code is there in all the files:

 Here is the next couple of lines in the screenshot:

Most of the files listed above, contain the "Bind our raw socket to this interface */" as well followed by the sockaddr_ll structure fill:

The next part of the screenshot is partially cut:

So, I used the YouTube video to take a better shot:

"A simple write on the socket ..thats all it takes ! */" is the partial comment, which many of you may agree is an unconventional comment :)  There is there in almost all the code files as well:

The last part of the screenshot is below:

Looks like this was from the Generic Packet Injection program, if you look closely:

The special effects guys seem to have removed most of the whitespace, so you see longer lines but it is clear to identify the code if you look close enough.

[Update Added Later] More Proof that the code is mine

The original code was posted on 2 of my sites: and then later on I eventually discontinued  . A quick whois search will tell you both the sites belong to me.

I used the WayBack Machine as 3rd party validation. Here is the exact code link mined from my site on June 29th 2007 by the wayback machine's spiders:

The original Packet Injection basics page where this and the other code presented here are linked. The wayback machine has a copy dating back to July 9th 2007:

During the same time, I had even announced that I had made some free videos on Packet Sniffing, Packet Injection (this is where all the code is form) etc. and sent an email to the mailing list.

Original email:

A few google searches led me to open source projects and even Wiki pages who have used my code. Some cited the original site ( while others did not.

How do I feel about this? Great :) If not me, at least my code made it to a 3 second clip in a Hollywood Movie :)  Also, the character in front of the computer seems quite excited (hands raised) as he is downloading / viewing / running my code :) What could make a developer more happy than to see his code inciting such thrill! :)


  • I hope the code would be compiled before use! :) 
  • The source / destination MAC, IP, etc. are hardcoded in most of the scripts so hopefully the hacker in the movie changed them before using :)
  • The Generic Packet Injection program just sends "A"* 1024 times onto the wire. This was just to demonstrate it's possible to send arbitrary data on the wire with raw sockets, even total garbage :)

The only thing I felt a bit dissapointed about was to see a couple of open source projects use snippets of my code without any form of acknowledgement.

OK, finally here are all the Code Snippets if you want to play with them. They are pretty old so some of the #includes may have to be changed based on the platform you are using. Note that the original links on the Internet have been posted above, the Gists were created today to embed them here.

Demystifying the Execve Shellcode (Stack Method)

We launched the SecurityTube Linux Assembly and Shellcoding Expert course recently. The course introduces the student to the basics of Assembly Language, Shellcoding, Encoders, Crypters and Polymorphism. I've decided to take up some of the course material and write posts about them. Even if you are not a student of the course, you should be able to follow these posts. Hopefully, this will be a lot of fun for both of us! :)

In this first post, I am going to take a look at probably the most popular shellcode - Execve! There are multiple ways to write shellcode but the most popular implementations use the Stack and the JMP-CALL-POP method. The subject of this post is creating Execve shellcode using the Stack method.

If you have no clue what Shellcode is, then have a look at the explanation on Wikipedia.  I will assume that you understand the basics of IA-32 assembly language and at least know what Shellcode is.

OK, let the games begin! 

Objective: To create an Execve Shellcode which can launch /bin/sh

Lab Setup I am using is Ubuntu 12.04 32-bit Desktop Edition. Most of the steps would remain the same even if you use other flavors of Linux.

Let's look at the whole process in a step-by-step way:

Step 1: Find the system call number for Execve

As you can see from the image above, Execve has system call number 11.

Step 2: We need to call Execve in our shellcode, so we would need to know the arguments it takes as input. Man pages to our rescue!

The 3 arguments must contain the following:

  • filename must point to a string containing the path of the binary we want to execute. In our case, this would be the string "/bin/sh". If you are not from the C world, "point" means the address of the string, and not the string itself.
  • argv[] is the list of arguments to the program. Most programs will use mandatory / option arguments to run e.g. telnet The argument here is "". In our case, we only want to execute "/bin/sh" without any more arguments, so the argument list is just a NULL pointer (0x00000000 address). However, there is a twist :) by convention, the first argument is the filename we want executed. So, argv[] would really be ['/bin/sh'. 0x00000000]
  • envp[] is the list of any additional environment options you want to pass to the program in key:value format. This will be NULL pointer / 0x00000000 for our purpose

 Step 3: Lets map the CPU Registers for the Execve call. The following registers will be used for the system call using INT 0x80

 This would be the mapping then. EAX would contain "11" which is the system call number for Execve as found in Step 1

 Step 4: Let the coding begin! I am using the below skeleton code for our program


I've only defined the TEXT section and the entry point into this executable would be _start. 

Step 5: We will now setup the Stack with all the arguments required for Execve as discussed in Step 3. Remind yourself that the stack for IA-32 grows from High Memory to Low Memory.

Step 6: Let us setup the EBX register first. EBX needs to point to "/bin/sh" in memory. Now the string would have to be '\x0' terminated. Let us setup the NULL first by pushing a 0x00000000 onto the stack. Now we cannot do a "PUSH 0x00000000" because Shellcode cannot contain NULLs as this is the most common bad character. Hence we will have to create 0x00000000 in one of the registers and PUSH the register on the stack. We will use the XOR operation to zero out EAX and then PUSH EAX on the stack:

The stack should look like this right now:

We now need to PUSH "/bin/sh" on the Stack. As the Stack grows from High Memory to Low Memory in x86 we will need to push "/bin/sh" in reverse order :) Also, it would be easier to push data which is a multiple of 4 with the least number of instructions. This is desirable as the smaller the shellcode, the greater the number of scenarios where we can use it. 

Now, "/bin/sh" is 7 bytes and we need to convert it to 8 bytes without messing up the filename. On Linux this is easy to do because "/bin/sh" invokes the same program as "//bin/sh".  Multiple "/" in succession does not cause any problems as you can see below:

Awesome! Now we need to PUSH "//bin/sh" (8 bytes) in reverse on the Stack i.e. "hs/nib//" Here is a quick way in Python to generate the value in hex:

Don't we all just LOVE Python :) Let's add the PUSH in the code now with the hex values above.

After the 2 PUSH instructions, this is how the Stack should look like:

Awesome! Now let us make EBX point to the top of the Stack! This would really mean EBX is now contains the address of "//bin/sh" in memory. This can be easily done by copying ESP into EBX

Step 7: Let us now setup EDX which if you remember should point to a NULL pointer. This can be easily achieved by a PUSH EAX (remember EAX contains 0x00000000) and copying ESP into EDX.

The Stack looks like this right now:

Step 8: The last piece of the puzzle ECX still remains! ECX needs to contain the address of [Address of //bin/sh in memory, 0x0000000] as discussed previously. Currently EBX contains the address of "//bin/sh" in memory so let's PUSH EBX on the Stack

If you notice, the top of the Stack now points to [Address of //bin/sh in memory, 0x00000000] This is exactly what we wanted! So let's write out the code to copy ESP into ECX

Step 9: All the arguments for Execve are now setup on the Stack and EBX, ECX and EDX are pointing to them. The Stack looks like this right now:

Step 10: Let us now call Execve! We setup EAX to contain "11" and invoke Interrupt 0x80

The code for Execve-Stack.nasm is available below for copying:

Now let us Assembly, Link and Test the code:

Let us look at the binary using Objdump (we could also use the .o file) The highlighted hex values are the actual IA-32 opcodes.

We need to extract all the opcodes to create our shellcode. As cumbersome as this looks, I am happy to report there is a shortcut available:

Here is the final extracted Shellcode - pretty much looks like ... any other piece of Shellcode :)

Step 11: I am going to use the following C program to test the shellcode to ensure we have not mistakenly used any hardcoded address and anything else which would disallow this shellcode from running inside another process.

Let us now compile shellcode.c and run it to test!

Fantastic! So our Execve Shellcode is working great! In the next post we will look at automating Shellcode generation for Execve using N arguments using Python. Stay tuned!

If you've never done Assembly Language / Shellcoding etc. before then please checkout my SecurityTube Linux Assembly and Shellcoding course which aims to teach the basics of assembly language on the Linux platform from a security perspective and its application to writing shellcode, encoders, decoders and crypters, among other things. The course material is over 9 hours of HD videos!

Thursday, 4 April 2013

Simulating an SSH Worm using Python

The topic of SSH Worms came up when I was speaking with a couple of students attending my workshop at Blackhat Europe in Amsterdam last month. One of the students was curious about the iPhone SSH Worm which has been around since 2009 and the technical complexity of writing a worm for academic and research purposes. 

After explaining to him how the worm worked I realized that many think "network worms" are really complex digital beasts and only the super elite blackhats can write them. In reality, nothing could be further away from the truth. The only complex part in most worms is the exploits they use for breaking in (which in most cases might be ripped from sites like exploitdb). The network propagation and replication aspects are quite simple.

I decided to create a "simple worm" demo in Python for demonstration purposes. Why Python? HLLs like Python are easy to understand even by non-programmers as they are very readable by design. 

The SSH worm in question was really using the default password "alpine" on jailbroken phones to break in and propagate. We will take a short detour and instead Bruteforce the SSH password using a word list.

So, if I were to breakup our "demo worm" functionality wise, it would do the following:

1. Scan a new IP address and if SSH is running try and bruteforce the login / password 
2. If the worm succeeds, then upload a copy of itself to the host
3. Run the copy, so it can now scan and do (1)-(3) 

Important: I am not going to give out the whole source code, rather will look at components separately. This is to prevent script kiddies from using the code as is. The video at the end of this post shows a full demo on my lab setup with a couple of victim machines. 

The above steps (1)-(3) can be broken down into just 2 functions:

1. SSHDictionaryAttack()
2. UploadAndExecute()

Now SSH is a complicated protocol and to write the low level transport encryption code will be a pain :) This is where Python is gonna be of help to us. We will be using Paramiko as our SSH Library.

Below is the code for a Dictionary based attack on SSH:

The sample username:password file would be in the following format:

A sample run of the script against a vulnerable SSH installation:

Awesome! Now lets look at once you have a valid SSH username:password, how we would go about implementing UploadAndExecute()

Lets do a quick run of the UploadAndExecute() code:

Awesome! We can see that was upload and executed. This end up creating the directory hacked.

Now, one of the issues with Python and using 3rd Party Libraries like Paramiko is that if the worm were to run in the "Python" form then the victim's would need to have Python + Paramiko installed. This is not a very practical expectation. So what do we do? PyInstaller to the rescue!

According to their website: PyInstaller is a program that converts (packages) Python programs into stand-alone executables, under Windows, Linux, Mac OS X, Solaris and AIX. Its main advantages over similar tools are that PyInstaller works with any version of Python since 2.3, it builds smaller executables thanks to transparent compression, it is fully multi-platform, and use the OS support to load the dynamic libraries, thus ensuring full compatibility.

This is exactly what we need! Lets convert both the above scripts to stand-alone executables using Pyinstaller as below:

Fantastic! Remember to use the "--onefile" option!  Now let me bring together the above components into one script and call it! Sorry I cannot share the source code for fear of abuse, but if you've understood the above code samples, I am sure you understand how the code works. Basically does the following:

  • Figures out the subnet IP addresses and scans for SSH services
  • Launched the Dictionary Attack on an SSH Service
  • Uploads and Executes a copy on the victim if it manages to break in
  • All files are created in the /tmp/ folder by the worm
  • It calls "wall" with the word "hacked" so that it can be displayed on the terminal
  • I've used Pyinstaller to convert into a single executable file ssh-worm

I've setup 4 Ubuntu 12.04 Server machines as victims. Before I run the worm, this is how the /tmp looks like on each of them:

I run the worm from Victim-1 and very soon you see  the "Hacked" messages appear on all terminals:

As this is a simple demo code, I am not checking if the worm has already infected the machine and hence we are having duplicate infections :) Below is a screenshot of the /tmp as the infection spreads:

As you can see, every new infection creates a new executable file (the green ones with random names) and *.wall file.

Below is a short video demo of the same:

Awesome! Worm behavior simulated with Python!

If you are interested in learning how to use Python for Pentesting then please have a look at our SecurityTube Python Scripting Expert course. This course is ideal for penetration testers, security enthusiasts and network administrators who want to learn to automate tasks or go beyond just using ready made tools. We will be covering topics in system security, network security, attacking web applications and services, exploitation techniques, malware and binary analysis and task automation.We have students from 73+ countries taking this course already!