Bypass Antivirus with Meterpreter as the Payload & Hyperion Fun

Note: Check the tool I work on with a great team, Veil.  It is designed to generate payloads for bypassing Antivirus.  This is more up-to-date than this post.


On any pen test, you will discover a number of hosts that are vulnerable to a variety of exploits. So after gathering all the information we can about our target(s), one of the next few steps may be to exploit the system.  Typically, I love using meterpreter as my payload because of the functionality that it offers.  Our team would then fire up Metasploit, configure our exploit for our target, exploit the box, see us uploading the payload, only to have nothing happen.

So what’s the problem?  Well, obviously it could be a number of things, versions are wrong, exploit just didn’t work, etc.  It’s also very possible that everything is working correctly, except the host-based anti-virus caught your meterpreter payload, and won’t let you get on the box.  I’ve come across this problem multiple times, and would love to share a technique that I use to try to circumvent the anti-virus installed on a machine.

First, I’m happy to give credit to two great writeups here and here that I looked up and incorporated into this attack.  I saw a few things that needed to be edited and tried to compile what I did (based off those two articles) into this post.

One of the methods of bypassing anti-virus is to create a “custom” executable template for meterpreter.  As a starting point, you can use the following as a base to your source code (go ahead and open your favorite text editor, lets call the file “base.c”, and add the following):


// This should be random padding
unsigned char padding[]=


// Our Meterpreter code goes here
unsigned char payload[]=


// Push Meterpreter into memory
int main(void) { ((void (*)())payload)();}


With the rough outline of our code down, the first thing we will want to do is create the random padding we want to put at the beginning of our file.  You can easily change the size of your random padding by deleting the “1028” from the following command, and replacing it with the size you want to use.

Our command and its output should look similar to the following:

Go ahead and paste the random padding into our base.c file into the appropriate section at the top (in between double quotes).  Our code should now look similar to the following:


// This should be random padding
unsigned char padding[]=

// Our Meterpreter code goes here
unsigned char payload[]=


// Push Meterpreter into memory
int main(void) { ((void (*)())payload)();}

Now that we have the padding in our base file, we can create our meterpreter shellcode.  I find it easiest to create the shellcode with msfvenom.  You can go ahead and create your shellcode using nearly the same command I am using here, just be sure to change your payload option values:

With our meterpreter shellcode generated, go ahead and copy just the shellcode and paste it into the appropriate section within our base.c file.  Once you’ve done that, our base.c file should look similar to the following:

// This should be random padding
unsigned char padding[]=

// Our Meterpreter code goes here
unsigned char payload[]=


// Push Meterpreter into memory
int main(void) { ((void (*)())payload)();}


Congrats, you’ve made a pretty decent template file which includes our payload.  Now, all that you need to do is compile it.  I like to use gcc.exe within Backtrack with wine. So, you can navigate to the compiler (it’s at /root/.wine/drive_c/MinGW/bin/gcc.exe), call the compiler through wine, provide it our source file, and specify the output file. Your command should look similar to the following:

Congrats again.  You now have an executable that you should be able to drop on a windows machine that doesn’t get flagged by Microsoft Security Essentials in addition to a variety of anti-virus programs.

So now what?

There’s an additional step we can take to try to further prevent detection of our executable, and it’s with a packer & encrypting tool called hyperion.  Hyperion is a tool that encrypts the executable you provide it with 5 rounds of AES encryption by default and outputs an executable.  The executable file that is produced by hyperion can then be ran on a windows machine.  The executable will brute force its own AES keys and then execute the payload you originally provided it.  It’s a sweet tool that does a really good job at hiding the payload you are encrypting.  The only problem with hyperion at times is that it can be detected as a packer by certain anti-virus programs.  However, it still is not recognized by a majority of AV solutions.

This is a quick article introducing Hyperion, a sweet tool I found after listening to Dave Kennedy talk, and how it can be compiled.

First, while researching how to use the tool, I came across this resource which helped me to write this article.

Hyperion is a tool that can be used to help prevent your payload from being detected by antivirus.  It works by encrypting your payload via AES encryption, and essentially throwing away the keys.  It’s output is an encrypted executable.  When the output file is ran, the executable brute forces the encryption keys, and then runs the previously encrypted executable (meterpreter payload :)).

So where do you get it and how can you compile it?  Hyperion can be found for download at this location.

Once downloaded and unzipped, you can easily compile the tool with g++.exe on Backtrack.  To compile it, point g++.exe to the .cpp files within the “Crypter” directory under “Src”.  Your command may look similar to the following:

wine g++.exe Hyperion-1.0/Src/Crypter/*.cpp -o hyperion.exe

Your command should have completed without any errors, and now you have compiled hyperion for use.

So all we need to do is call hyperion, provide it our executable that we want it to hide, and then give it the name of the executable to output.  Once compiled, hyperion can be run through wine or from the Windows command line.  Our commands and their output should look similar to the following:

root@bt:~/.wine/drive_c/MinGW/bin/Hyperion-1.0# wine hyperion.exe metexecutable.exe encryptedmet.exe
Opening metexecutable.exe
Copied file to memory: 0x115868
Found valid MZ signature
Found pointer to PE Header: 0x80
Found valid PE signature
Found a PE32 file
Number of Data Directories: 16
Image Base: 0x400000

Found Section: .text
VSize: 0x924, VAddress: 0x1000, RawSize: 0xa00, RawAddress: 0x400

Found Section: .data
VSize: 0x5f0, VAddress: 0x2000, RawSize: 0x600, RawAddress: 0xe00

Found Section: .rdata
VSize: 0xc0, VAddress: 0x3000, RawSize: 0x200, RawAddress: 0x1400

Found Section: .bss
VSize: 0xe0, VAddress: 0x4000, RawSize: 0x0, RawAddress: 0x0

Found Section: .idata
VSize: 0x268, VAddress: 0x5000, RawSize: 0x400, RawAddress: 0x1600

Input file size + Checksum: 0x4140
Rounded up to a multiple of key size: 0x4150
Generated Checksum: 0xcf0cc
Generated Encryption Key: 0x0 0x2 0x1 0x2 0x3 0x3 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

Written encrypted input file as fasm array to:
-> Src\FasmContainer32\infile.asm

Written input file’s image base to:
-> Src\FasmContainer32\imagebase.asm

Written input file’s image size to:
-> Src\FasmContainer32\sizeofimage.asm

Written keysize to:
-> Src\FasmContainer32\

Starting FASM with the following parameters:
Commandline: Fasm\FASM.EXE Src\FasmContainer32\main.asm encryptedmet.exe
FASM Working Directory: C:\MinGW\bin\Hyperion-1.0

Executing fasm.exe

flat assembler version 1.69.31 (1020166 kilobytes memory)
5 passes, 0.1 seconds, 35328 bytes.

And that’s it.  Hopefully either or a combination of both of these techniques have helped you to bypass the antivirus product you are going against.

Good luck, and let me know if you have any questions!

SQLMap –data trick

I’ve recently learned a new trick about sqlmap that I think is worth sharing.  If you already know this, power to you, if not, hope that this helps you out.

The scenario where I learned this trick was as follows: I was trying to run sqlmap against a web form that I identified as being vulnerable to a SQL injection attack.  I ran sqlmap with the usual “–forms” after providing it the web address of the form, and off sqlmap went.  However, as the tool started parsing the code, I immediately kept receiving errors about mal-formed HTML code which would cause sqlmap to error out and quit immediately.   I attempted running the same command a couple more times, all with the same result, and was therefore unable to have sqlmap run against the form field.

Needless to say, I was pretty disappointed because I know the form had an injection flaw.  It was obviously posible to to manually exploit the injection flaw to dump the data out of the DBMS behind the form, but an automated tool such as sqlmap would be able to get the job done much quicker, so I set out on researching how to fix this.  Within about 30 minutes, I found my answer.

I discovered that instead of giving sqlmap the -u URL of the form web page, I should actually give it the URL of the form processing page.  Next, since the information is passed via a POST request, I need to copy the variables and the values sent in the post request, and input that into sqlmap.  To gather all this information, I turned on Burp Suite, navigated to the form processing page, ensured intercept was on, and then submitted data through the form.  Burp suite caught the form processing URL and all data being sent via a POST request.  I copied the URL and set the URL as the -u value for sqlmap.  I also copied the data that was being sent in the POST request, and set the data as the –data value within the sqlmap command.  The last piece of data I used within the sqlmap command (before I gave what I wanted out of the DBMS such as –dbs, or –tables) was the -p switch.  This switch lets me identify specifically which parameter I wan sqlmap to target.  Since I already identified the injection flaw within the form, I just found the variable name that was given to the specific form field which was injectable, and provided it within the sqlmap command.

Edit: Want to be able to just give the request in a single file?  Easily copied from Burp Suite?  Just save the request that burp intercepted in a txt file, and then call sqlmap and pass it the text file using the -r switch.  This will tell sqlmap to read the url and variables from the request file.

To help show what I mean, I’ll use my web page’s login form as a sample target.  If I had to perform the exact steps above in relation to my login page, the sqlmap command would look like (the “-” should actually be a double dash for the dbs and data switch, however it is being filtered at the moment):

 ./ -u –data=”log=TestUserAccount&pwd=TestUserPassword&wp-submit=Log+In&″ -p pwd –dbs

In the command above, I am giving it the login.php page as the page to target.  This is the page the processes the data sent in the POST request made by a browser (in this case, it’s also the page where the form is stored).  The information in the –data switch is the information sent in the POST request to the form processing page.  The -p parameter is the variable that I am having sqlmap target, which in this case is the password field.  Finally, the –dbs switch is given to tell sqlmap once I have injected into the form, return all database names stored on the backend database server.

Once I set the above commands, I ran the sqlmap statement, received no errors, and was able to automate gathering all the data I needed/wanted from the backend database.

Hope this helps in the event anyone comes across a mal-formed html code error within sqlmap!

Certifications – Don’t blame them! Change the hiring process.

Before I begin with this post, it should be obviously known that I hold a number of certifications.  However, I do feel that I can write this article without any bias.  However, take from this what you want.

For the past few months now, I’ve seen a constant, if not increasing, number of anti-certification and anti-certification body posts, tweets, etc.  This has come from a wide variety of various individuals, to (if memory serves me correct) even some articles on IT related websites.  However, one thing that you almost, if not always, see in common with these certification rants is that no other alternative is provided.

So what’s the point of IT certifications?  The reason we have certifications is to try to provide some sort of standardized method of testing individuals and demonstrating the level of knowledge that an individual has.  While IT professionals can use certifications as a method of ranking one’s knowledge of different concepts, IT professionals, seeing as they work in the field themselves, are generally capable of judging another person’s level of knowledge through interaction with one another, typically better than any certification can.

So what about those that don’t work in IT?  IT “outsiders” typically don’t have the same skill set as those that work in IT, therefore, they are usually unable to make a judgement on the level of knowledge required for a position in relation to a potential job candidate.  As a result, the certifications an individual holds is what is typically turned to in the early stages of an interview.

The complaints that I have seen lately stem from the fact how certain certifications are useless, how a certification doesn’t mean that an individual knows anything, or how anyone can learn something to pass a test.

All of these are valid points.

I am in no way arguing against these points.  However, if there is a failure within the hiring process while also using certifications as a metric, I would argue that the bigger problem is in your candidate vetting process.  Almost all HR/Recruiting departments (except for those that specialize in IT recruiting) need some sort of metric to measure a candidate to determine if they are worth passing on to a hiring manager.  IT professionals cannot expect any recruiter to be able to make a solid judgement of the level of knowledge that a job candidate has.  Recruiters simply do not have the background that IT professionals do, so it is not realistically possible for a recruiter to pass judgement.

This is where certifications come in.  Recruiters rely on the hiring manager to provide some sort of base requirements for jobs.  A hiring manager can provide certifications as a way to establish some base level of knowledge that a recruiter can use.  However, this should quite obviously not be the only roadblock simply because (as pointed out earlier) almost anyone can learn to pass a test.  At this point, a technical interview should be performed to assess a candidates true level of knowledge and experience.  This should be the most important part of the candidate vetting process, as this will be the only time to get the best picture of what a potential hire knows before bringing them on and working full time with them.

Another point might be that people “hate” certifications so much that they will purposefully not be tested for any of them (or any specific ones), and then valid candidates could be “skipped over”.  While this cannot obviously backed up with fact, I believe the number of candidates that fall into this category is far smaller than the number of candidates who may still dislike certifications, but still obtained some as a result of job requirements.  Those that do not obtain certifications due to their lack of respect for certs knowingly limit themselves for career opportunities, and I think this is almost a disservice to that individual.

In all the anti-certification posts that I have seen, I have yet to see anyone provide another usable metric that can be used by non-IT people to attempt to measure where a candidate stands in what they know.  To declare a problem, and not provide a solution, not even an idea, is not an answer.  Anyone can say any system is broken/flawed, a lot of systems far beyond the realm of IT are, but they just might be the best system out there at the moment.  Just claiming something doesn’t work provides a service to no one.

I’m challenging the anti-certification crowd to step up and provide the industry with a viable alternative.  I agree the certification route isn’t perfect, but it’s the best thing we have out there at the moment, which is why you won’t see any anti-certification posts come from me.  Provide the industry with a better, realistic, alternative than certifications, and I will be among the first to hop on that bandwagon.

However, I’m still waiting.

How Did I Figure Out I Wanted to Work in IT Security?

Randomly, I’ve been asked by people how I got started in the security world, specifically within IT.  To be honest, it’s a little amusing to me seeing as I know there is so much more out there I still have to learn.  But looking back, I can see that I have come quite a ways, and I have loved every step along the way.  I figured it might be worthwhile for me to post my thoughts, and the path that I took about how I really started working in this great industry, and give my thoughts on what a successful security person might be (by no means can I provide the all-encompassing list, but it’s just my thoughts).  This will be broken up into numerous blog posts on here.

My first exposure into security probably came at college, I know significantly later than probably many others out there.  I took my first security class at a school which barely offered any, and I could not wait for it to begin.  Throughout the course, I realized it wasn’t going to be all that intensive, I found the material easy and very logical to understand, which resulted in great grades for the class.  However, the real learning came to me when I began talking to the teacher, and meeting up with him after class.  Through this one on one time, I was exposed to the first hacking tool I’ve ever seen, Metasploit.  I still remember him saying, “Hey, see that server over there?  Watch this.”.  He then fired up Metasploit on his computer, typed in all of his commands, and boom, a shell popped up.  When I saw him make a folder via the shell, and then it pop up on the desktop of the server, it was like this black magic to me.  At the time, I felt like people always heard about hacking attacks, network infiltrations, but it’s just some news story far away, and it doesn’t really happen.  When I saw it happen right in front of my eyes, it’s like my whole world opened up.

I went home that very same day, installed Auditor (pre-backtrack days) and fired up metasploit.  This was my very first interaction with not only metasploit, but linux also.  I had never used linux, knew of it, but just never tried it before.  I can’t tell you the number of times I lost my documents (until I finally started saving them on a usb drive) when trying to learn how to setup dual partitions on a single hard drive to run linux and windows.  I finally settled on Kubuntu at the time, and started trying to learn the OS.

At the same time, I was lucky enough to have a roommate who told me, “Yeah, you can try hacking into my computer”.  So I did.  It took quite some time, as I never really knew what I was doing.  But, like the security class, I still remember the first time I was able to break into his system.  It was some basic remote code execution that he hadn’t patched on his XP computer, and I setup to do a VNC injection as the payload.  I just couldn’t believe my eyes when I saw it successfully worked, and then when his actual desktop showed up on my computer, and that I could actually move his mouse on his computer with my computer.

It was right then and there, that I knew exactly what I wanted to do as my job.

Shmoocon 2012 Recap

I was one of the lucky few to bypass the crowd inflicted DOS attack and get a barcode to Shmoocon.  It was a nerve-wracking experience where all I, and my coworkers did, was press F5 as fast as we could, but it paid off and we were able to attend.

Being my first Shmoocon, I didn’t know what to expect.  Registration looked like it was going to be a nightmare, but it was an extremely fast process seeing that all they needed to do was scan our barcode.  The talks that were presented were great.  In my opinion among the most interesting was a talk on NFC by Kristin Paget and the different talks by the EFF.  Kristin Paget showed that with a quick read of a credit card via NFC, anyone can easily reprogram a mag stripe with the information read from the NFC transaction and charge the credit card like normal.  Marcia Hoffman gave a great presentation on the disclosure of passwords, and when the government can force you to disclose your password.  Hanni Fakhoury also gave a presentation essentially on anticipatory obstruction of justice when it comes to deleting/destroying evidence.  These were probably among my favorite talks.

Also, I participated in Hack Fortress during Shmoocon.  I played with Pwn State on their hacking team.  It was a really interesting blend of Team Fortress 2 and Capture the Flag.  As players on the hacking team solved challenges, the opposing Team Fortress 2 team would be penalized, possibly by being set on fire for 30 seconds.  As the Team Fortress team had flag captures, the hacking team would be given hints.  After three rounds, our team won the competition.

Overall, it was a great conference.  I was able to meet some extremely intelligent people, attend some great talks, and play in a pretty fun game.  It’s definitely a con I’m going to try to attend again next year.


Stratfor Hack and Password Analysis

UPDATE: Stats have been updated down below based off of my latest findings from 2/6/2012.  I’ve also posted a video from my talk I gave on Stratfor and a GPU cracking method from Shmoocon Epilogue.

Ever since CarolinaCon of last year, it has become a hobby of mine to crack password hashes.  When a company needs to store user passwords, the plain text password is not stored, but typically rather a hash of the password is what is actually stored.  Hash cracking is the process of taking a cryptographic hash (MD5, SHA-1, SHA-2, etc.) and using multiple techniques to discover the word that was used to create the hash.  Hash cracking can provide educational value because it can allow developers/security architects discover the amount of time it can take for an attacker to discover the plain text password from a hash, and adjust their hashing algorithm accordingly to ensure it is secure.  Additionally, hash cracking can be used as a method of auditing passwords employed by users to ensure that they meet specific password requirements.

Hash cracking has become significantly easier to perform because of the capability to offload the processing required to crack a hash onto a GPU.  GPU based cracking has significantly increased the speeds at which hashes are able to be cracked either via dictionary file word mutations or the tried and true brute force method.

So, as I’m sure many of you know, Stratfor (a company which provides independent analysis on world events/trends) was hacked over the winter holiday season.  When Stratfor was hacked, the attackers were able to dump a significant portion of their database.  Unfortunately, Stratfor actually used very few industry best practices when it came to securing customer data.  For example, all customer credit card data was stored without being encrypted in any format.  This included name, address, credit card number, expiration, and CVV code.  Additionally, the attackers were able to dump other customer information such as full name, e-mail address, username, password, etc.

Since the password hashes were released and made public, I gathered them and began the process of cracking them. I did this not because I had any malicious intentions or plans to harm anyone, but because I think it’s interesting to understand how people choose passwords, and to discover any security lessons that can be uncovered via cracking a group of hashes.

Over a process of several days, I’ve been able to discover a significant amount of the passwords that were being used (which I later discarded), and here’s some notes:

  • Customers did not want to change the default password that was given to them.  It appears that when a customer signs up, Stratfor assigns them an alphanumeric password that is 8 characters long.  It is composed only of lower case characters, upper case characters, or numerical digits.  Probably 70% of Stratfor’s customers did not change this password.
  • A other users did change their passwords, however they were unfortunately easily discovered.  The passwords used were primarily dictionary based with small (if any) mutations implemented.  For example, someone might have use p@ssword instead of password.
  • Unfortunately, there were users who changed their password from the 8 character alphanumeric password down to a single letter.

After I was able to crack a portion of the hashes, I ran a tool against the passwords that were found called Pipal.  Pipal is a great tool that is capable of analyzing passwords in a list and producing useful statistics about the discovered passwords for the researcher to discover trends that might be in use.  The following excerpts are some statistics that have been found after running Pipal on the passwords I have cracked so far:

Total entries = 815147
Total unique entries = 701257

Top 10 passwords
David = 4 (0.0%)
22 = 4 (0.0%)
bill = 4 (0.0%)
John3 = 4 (0.0%)
Brendan1 = 4 (0.0%)
Patches1 = 4 (0.0%)
Christina = 4 (0.0%)
Romans8 = 3 (0.0%)
Romans1 = 3 (0.0%)
Joseph = 3 (0.0%)

Top 10 base words
stratfor = 347 (0.04%)
strat = 201 (0.02%)
password = 137 (0.02%)
intel = 118 (0.01%)
mike = 116 (0.01%)
alex = 112 (0.01%)
john = 107 (0.01%)
blue = 100 (0.01%)
ranger = 89 (0.01%)
qwerty = 87 (0.01%)

Password length (length ordered)
1 = 51 (0.01%)
2 = 72 (0.01%)
3 = 395 (0.05%)
4 = 4619 (0.57%)
5 = 5943 (0.73%)
6 = 48052 (5.89%)
7 = 35238 (4.32%)
8 = 682603 (83.74%)
9 = 19870 (2.44%)
10 = 10817 (1.33%)
11 = 4172 (0.51%)
12 = 2041 (0.25%)
13 = 648 (0.08%)
14 = 410 (0.05%)
15 = 231 (0.03%)

Password length (count ordered)
8 = 682603 (83.74%)
6 = 48052 (5.89%)
7 = 35238 (4.32%)
9 = 19870 (2.44%)
10 = 10817 (1.33%)
5 = 5943 (0.73%)
4 = 4619 (0.57%)
11 = 4172 (0.51%)
12 = 2041 (0.25%)
13 = 648 (0.08%)
14 = 410 (0.05%)
3 = 395 (0.05%)
15 = 231 (0.03%)
2 = 72 (0.01%)
1 = 51 (0.01%)

      | |

One to six characters = 59126 (7.25%)
One to eight characters = 776965 (95.32%)
More than eight characters = 38182 (4.68%)

Only lowercase alpha = 59099 (7.25%)
Only uppercase alpha = 2119 (0.26%)
Only alpha = 61218 (7.51%)
Only numeric = 14019 (1.72%)

First capital last symbol = 3162 (0.39%)
First capital last number = 53073 (6.51%)

january = 23 (0.0%)
february = 4 (0.0%)
march = 69 (0.01%)
april = 80 (0.01%)
may = 401 (0.05%)
june = 107 (0.01%)
july = 91 (0.01%)
august = 56 (0.01%)
september = 15 (0.0%)
october = 30 (0.0%)
november = 17 (0.0%)
december = 22 (0.0%)

monday = 24 (0.0%)
tuesday = 5 (0.0%)
wednesday = 4 (0.0%)
thursday = 2 (0.0%)
friday = 33 (0.0%)
saturday = 4 (0.0%)
sunday = 13 (0.0%)

Months (Abreviated)
jan = 613 (0.08%)
feb = 204 (0.03%)
mar = 2291 (0.28%)
apr = 327 (0.04%)
may = 401 (0.05%)
jun = 426 (0.05%)
jul = 362 (0.04%)
aug = 314 (0.04%)
sept = 63 (0.01%)
oct = 243 (0.03%)
nov = 273 (0.03%)
dec = 323 (0.04%)

Days (Abreviated)
mon = 1125 (0.14%)
tues = 6 (0.0%)
wed = 233 (0.03%)
thurs = 8 (0.0%)
fri = 328 (0.04%)
sat = 354 (0.04%)
sun = 518 (0.06%)

Includes years
1975 = 122 (0.01%)
1976 = 105 (0.01%)
1977 = 106 (0.01%)
1978 = 105 (0.01%)
1979 = 88 (0.01%)
1980 = 106 (0.01%)
1981 = 127 (0.02%)
1982 = 131 (0.02%)
1983 = 111 (0.01%)
1984 = 153 (0.02%)
1985 = 129 (0.02%)
1986 = 102 (0.01%)
1987 = 96 (0.01%)
1988 = 113 (0.01%)
1989 = 75 (0.01%)
1990 = 90 (0.01%)
1991 = 77 (0.01%)
1992 = 68 (0.01%)
1993 = 55 (0.01%)
1994 = 39 (0.0%)
1995 = 72 (0.01%)
1996 = 60 (0.01%)
1997 = 69 (0.01%)
1998 = 62 (0.01%)
1999 = 89 (0.01%)
2000 = 368 (0.05%)
2001 = 219 (0.03%)
2002 = 150 (0.02%)
2003 = 140 (0.02%)
2004 = 166 (0.02%)
2005 = 207 (0.03%)
2006 = 199 (0.02%)
2007 = 197 (0.02%)
2008 = 234 (0.03%)
2009 = 343 (0.04%)
2010 = 464 (0.06%)
2011 = 336 (0.04%)
2012 = 67 (0.01%)
2013 = 17 (0.0%)
2014 = 20 (0.0%)
2015 = 13 (0.0%)
2016 = 23 (0.0%)
2017 = 16 (0.0%)
2018 = 10 (0.0%)
2019 = 23 (0.0%)
2020 = 70 (0.01%)

Years (Top 10)
2010 = 464 (0.06%)
2000 = 368 (0.05%)
2009 = 343 (0.04%)
2011 = 336 (0.04%)
2008 = 234 (0.03%)
2001 = 219 (0.03%)
2005 = 207 (0.03%)
2006 = 199 (0.02%)
2007 = 197 (0.02%)
2004 = 166 (0.02%)

Single digit on the end = 94421 (11.58%)
Two digits on the end = 39271 (4.82%)
Three digits on the end = 12636 (1.55%)

Last number
0 = 9243 (1.13%)
1 = 23350 (2.86%)
2 = 21082 (2.59%)
3 = 21283 (2.61%)
4 = 17841 (2.19%)
5 = 18162 (2.23%)
6 = 17410 (2.14%)
7 = 18677 (2.29%)
8 = 17503 (2.15%)
9 = 18617 (2.28%)

 ||||| | |

Last digit
1 = 23350 (2.86%)
3 = 21283 (2.61%)
2 = 21082 (2.59%)
7 = 18677 (2.29%)
9 = 18617 (2.28%)
5 = 18162 (2.23%)
4 = 17841 (2.19%)
8 = 17503 (2.15%)
6 = 17410 (2.14%)
0 = 9243 (1.13%)

Last 2 digits (Top 10)
23 = 3833 (0.47%)
11 = 3086 (0.38%)
01 = 3064 (0.38%)
12 = 2413 (0.3%)
00 = 2371 (0.29%)
10 = 1859 (0.23%)
99 = 1802 (0.22%)
77 = 1540 (0.19%)
22 = 1478 (0.18%)
34 = 1400 (0.17%)

Last 3 digits (Top 10)
123 = 2798 (0.34%)
000 = 753 (0.09%)
234 = 748 (0.09%)
007 = 612 (0.08%)
111 = 573 (0.07%)
001 = 532 (0.07%)
010 = 461 (0.06%)
777 = 404 (0.05%)
009 = 358 (0.04%)
999 = 332 (0.04%)

Last 4 digits (Top 10)
1234 = 669 (0.08%)
2010 = 366 (0.04%)
2000 = 323 (0.04%)
2009 = 305 (0.04%)
2011 = 257 (0.03%)
2008 = 196 (0.02%)
2001 = 181 (0.02%)
2345 = 179 (0.02%)
2005 = 173 (0.02%)
2006 = 172 (0.02%)

Last 5 digits (Top 10)
12345 = 162 (0.02%)
23456 = 84 (0.01%)
54321 = 37 (0.0%)
00000 = 31 (0.0%)
11111 = 26 (0.0%)
99999 = 17 (0.0%)
77777 = 16 (0.0%)
33333 = 16 (0.0%)
45678 = 15 (0.0%)
20000 = 14 (0.0%)

Character sets
mixedalphanum: 438261 (53.76%)
mixedalpha: 192042 (23.56%)
loweralphanum: 90324 (11.08%)
loweralpha: 59099 (7.25%)
numeric: 14019 (1.72%)
upperalphanum: 9986 (1.23%)
mixedalphaspecialnum: 6362 (0.78%)
upperalpha: 2119 (0.26%)
loweralphaspecialnum: 1427 (0.18%)
loweralphaspecial: 947 (0.12%)
mixedalphaspecial: 265 (0.03%)
specialnum: 116 (0.01%)
upperalphaspecialnum: 50 (0.01%)
special: 24 (0.0%)
upperalphaspecial: 22 (0.0%)

Character set ordering
allstring: 253260 (31.07%)
stringdigitstring: 221613 (27.19%)
othermask: 156529 (19.2%)
stringdigit: 112163 (13.76%)
digitstring: 45284 (5.56%)
alldigit: 14019 (1.72%)
digitstringdigit: 9106 (1.12%)
stringspecialdigit: 2254 (0.28%)
stringspecial: 440 (0.05%)
stringspecialstring: 329 (0.04%)
specialstring: 80 (0.01%)
specialstringspecial: 46 (0.01%)
allspecial: 24 (0.0%)

Hashcat masks (Top 10)
?l?l?l?l?l?l: 18062 (2.22%)
?l?l?l?l?l?l?l?l: 14903 (1.83%)
?l?l?l?l?l?l?l: 10863 (1.33%)
?l?l?l?l?l?l?d?d: 9241 (1.13%)
?d?d?d?d?d?d: 6106 (0.75%)
?l?l?l?l?d?d?d?d: 5063 (0.62%)
?l?l?l?l?l?l?l?l?l: 5063 (0.62%)
?l?l?l?l?l?l?l?d: 4549 (0.56%)
?l?l?l?l?l?d?d: 3868 (0.47%)
?l?l?l?l?l?d: 3846 (0.47%)

iPhone’s Theme It Store – How Not to Implement Security

Hello all,

In this writeup, I will be providing proof that the owner/developer(s)/company that runs Theme It has developed an insecure iPhone and web application.  The only reason I am releasing this information before a fix has been made is because the owner/developer(s)/company has ignored repeated attempts to get into contact with them.

A while ago I wrote about the web front end to the jailbroken iPhone’s theme store.  There were a number of issues that I pointed out, and some issues have been fixed.  Unfortunately, not all have, and the issues that have been still leaves your account vulnerable.

When first talking with the Theme It team, their reason for not securing their application was because “we are not a bank“.  Any business/store that performs financial transactions should ensure its customer data is secured, both at rest and in transit.

While I obviously do not have access to Theme It’s back-end database to view how records are stored, we all have access to information sent to Theme It, and I can show you how Theme It does not protect user information.  In fact, it is left clear-text for any person to sniff and steal user login information.

The Theme It team previously mentioned that “96% of its users don’t use the website” implying that they use the Theme It iPhone application.  After reviewing the information transmitted from the Theme It app to its servers, it can be said that the application has not taken any steps to secure customer data (at the time of this writing).

To test, I simply had my iPhone join a network, and then had the iPhone open up the Theme It app, and connect with my account.  What you see below is what any person sniffing traffic can see:

If you look at the information captured, you can see that nothing has been encrypted.  The “pseudo” variable is your username, “password” is the password for your account, “device_id” is the UDID for your iPhone, “device_type” would be the type of iPhone you have, and “device_os” is what version of iOS you are running on your iPhone.

Any person on the network that the iPhone is transmitting on can sniff, intercept this traffic, and use its information to take over the customers account. Point being, the Theme It app does not take any steps to secure your personal information as it is being sent.

The Theme It Store also has a website that they allow users to connect to, purchase themes, administer their account, etc.  I wrote about their website a few months ago informing users how all information that is transmitted to their server is in clear-text and can be sniffed by an attacker (this included username and password).  The web site still transmits information in clear-text that can be sniffed.  With the information that is sent to the Theme It website, any attacker is able to perform what is called a replay attack.  What this means is that I can use the information I just sniffed from a customer logging in, send the exact same information to the Theme It server, and then be logged in with full control of the customers account.  The picture below shows a successful replay of captured information on the test account I created:

To fix this issue, the easiest thing that the Theme It company can do is get a certificate which will allow a secure/encrypted connection directly to the server Theme It uses.  If the company were to purchase a certificate, it would mitigate all attacks I have shown in this writeup.

I stated in multiple messages to both @fif7y and the official Theme It twitter account that I found their application is sending everything in clear-text, and that their web application is still vulnerable due to a lack of security.  I have yet to see a fix or hear back from either.  Hopefully we can see some security updates to their applications soon.

IP Board Vulnerabilities

Good Morning all,

It’s been a busy past month for me, but I did happen to find a new vulnerability that exists in IP.Board.  IP.Board is basically a web application that allows you to run a forum, with the option to purchase additional functionality, like blogs, a store, etc.

While I was looking into how IP.Board works, and running some tests and scans against it, I’ve discovered a couple of vulnerabilities in the application.  At the moment, it seems to largely be information disclosure and XSRF vulnerabilities, but I am in the process of seeing if it is capable of further development  into something a little more dangerous.

I’ve already reported some of the  vulnerabilities to the developers of IP.Board, and they said that a fix has been created for their next update.  I’ll be sure to let you know once it is released if it fixes the issue.  The other outstanding vulnerabilities I want to look into as much as I can to see if it can result in a dangerous attack.  As I find out more information, and understand how it works, I will then be able to provide a better report to the developers of IP.Board (Invision Services) about the vulnerability.

I am also currently working to get a CVE number reserved for the issue for proper tracking of the vulnerability.