Jailbreaking iOS iphone 4s with Home Depot jailbreak

When analyzing iOS applications it is important to have an unrestricted environment to be able to fully analyze all the aspects related to that application and determine if it shows malicious behavior, decrypt the app to analyze strings and headers and even analyze the assembly code of the app, if time permits. When we are talking about overcoming restrictions on an iphone device, it means jailbreaking it. In this article, I will show the steps that I followed to jailbreak an old iphone 4s that I have.

Verify that there is an existing jailbreak for the iphone model and iOS version that you have.
In my case, there were several candidates but the jailbreak known as Home Depot seemed like a good option.
https://yalujailbreak.net/home-depot-jailbreak-offsets/
https://cydiainstaller.net/home-depot-jailbreak/


It is not a good idea to jailbreak your production device, because jailbreaking reduce the security posture of your device, making it easier for someone to get access to your data, therefore ideally you should this device for testing only. You should also create an apple account to be used only for this device, not your production account.

Download the Home Depot IPA file, version R3 worked for me
http://wall.supplies/MixtapePlayerRC3.ipa
If you are paranoid, like me, it is a good idea to download all the required software from a virtual machine, so you don't risk downloading and running potentially malicious programs.

Download and install iTunes

Create a new apple account for this process

Download Cydia Impactor
https://cydia.saurik.com/api/latest/2

Finally, run Cydia Impactor and drag and drop MixtapePlayerRC3.ipa file into it. It will ask for your apple account credentials, provide the credentials of the account you created. This will install the Home Depot jailbreak app.

In the iphone go to Settings > General > Device Management > Select the user used to sign the application and Trust It.

Open the Home Depot app, select Prepare for Jailbreak  > Accept > Dismiss > Proceed with Jailbreak > Begin Installation.

Once it is completed Cydia is installed. Open Cydia and delete the repo  repo666 by sliding it to the left as it causes an error. Update all the packages.

Install BigBoss Recommended Tools, as it has several command line useful tools, such as git, curl, etc.

Video where I found most of the instructions (in Spanish)
https://www.youtube.com/watch?v=qZeiW3Cyx1Y

Install OpenSSH in Cydia
This will allow you to access your device through SSH, the default password is alpine, you have access it and change it to prevent unauthorized use. Use the command passwd to change root and mobile accounts passwords.

That's it, enjoy it!

Enabling Windows Firewall log

One of the key evidence items to acquire and analyze in a security incident is information about network connections established on the device that is being investigated. Unfortunately, not on every situation this information will be available, because if the device was powered off, the network connections are lost, as it is volatile information that resides in the RAM memory of the computer. In this case, we would try to locate and analyze hibernation files (extremely valuable, but not always available) or offline files trying to identify any remnant of a network connection, such as the pagefile.sys or service specific logs, but this information would be very limited and incomplete as compared to the information that could have been displayed by the command netstat. We could also try to obtain logs from any firewalls available on the organization, but we would depend on logging being enabled and that the network traffic of the device under investigation had passed through the specific network path where the firewall is located. Finally, network activity could also happen when the device is not at the enterprise, common for laptops, in that case obviously the firewall would have no relevant logs for that specific investigation.

Modern OS have host-based firewalls which can be easily configured to store logs about the network connections, providing a valuable source of information in case of a security incident. Regarding the Windows operating system, it is very easy to enable logging of the network connections through the integrated Windows Firewall. If the log is enabled, it will require administrator privileges to delete it, which will not always be the case if the attacker cannot achieve admin rights on the compromised host. Even if the attacker achieves admin rights, not all of them will be aware of the log so there will be a good chance that it will be available for collection and analysis.

Windows Firewall log can be enabled extremely easy, both through command line interface and through GUI and it allows the user to determine what kind of network connections should be logged (failed or successful). I will show how to enable it using the command line interface. We can log both allowed and dropped connections, but I recommend doing it only for allowed connections, as dropped connections would log lots of noise, especially related to the UPnP protocol.

netsh advfirewall set allprofiles logging allowedconnections enable

netsh advfirewall set allprofiles logging droppedconnections disable

We can also increase the size of the log, the acceptable range is 1-32767 kilobytes.

netsh advfirewall set allprofiles logging maxfilesize 32767

The window Firewall will be created by default on C:\Windows\System32\LogFiles\Firewall, although it can be configured to a different location. If you try to open the active file, you will get an error. To solve this problem, simply create a copy of the file and open it. The structure of the log is very simple and straightforward to read, it is in clear text and stores the following fields:

Since it is generated by the host, it will be synced with other logs generated on the same computer, allowing for quick correlation. If the logs were generated by a network firewall, we would first have to check if it is synced to the same NTP server or otherwise calculate the time skew and adjust the timestamps, which is not always a fun or easy task to do.

You can determine if logging is enabled for a given Windows computer by running the following command:

netsh advfirewall show allprofiles




The relevant parameters for every profile are LogAllowedConnection, LogDroppedConnection FileName and MaxFileSize.

Enabling the Windows Firewall log is a quick win, as it is very simple to do and can provide extremely valuable information during a DFIR investigation. Because of its small size, it can be used for triage and rapidly search a given IP address or uncommon port that has been previously identified as malicious or suspicious. In the following article, I will show several use cases for this information, and I will share a useful script to extract information from the log to make it more actionable.

If you disabled Windows Firewall because you use a third-party host firewall, make sure that you have logging enabled in the third-party firewall, determine the retention time and make sure it meets your requirements. 

Detecting lsass Acess with Sysmon Process Access

Local Security Authority Subsystem Service process (lsass.exe) is responsible for enforcing the security policy on the system and handling password operations. Therefore, it contains user passwords.  One of the things that attackers do when they have gained access to a system is to inject code into that process to obtain clear text passwords, from the attacker’s perspective this is great as they won’t have to consume precious time trying to attack password hashes, as opposed as accessing password hashes from the SAM Windows registry hive.

Sysmon is a useful and free tool created by Mark Russinovich y Thomas Garnier  from Microsoft that can audit processes among many other things. One of the things that can be audited on the most recent version is Process Access, which can detect any tools that have accessed lsass process and that could have potentially dumped credentials. By default process access audit is disabled, so it is required to tune Sysmon to audit this event, which can be done with the following xml configuration file.

<Sysmon schemaversion="3.2">

  <HashAlgorithms>*</HashAlgorithms>

  <EventFiltering>

    <!-- Log all drivers except if the signature -->

    <!-- contains Microsoft or Windows -->

    <ProcessAccess onmatch="include">

                <TargetImage condition="contains">lsass.exe</TargetImage>

    </ProcessAccess>

    <!-- Enable Network Connections -->

    <NetworkConnect onmatch="exclude"/>

  </EventFiltering>

</Sysmon>

Next we update sysmon configuration by using –c flag and passing the xml file as parameter.

To test the configuration, I used mimikatz, which is a (in)famous tool used to get clear text credentials from lsass process. I set up a meterpreter listener and created a reverse meterpreter tcp executable called lolm.exe, which I executed on the test Windows computer. As expected, I was able to load mimimkatz plugin and dump clear text credentials using kerberos command.

Sysmon was able to successfully log the event, it traced time and date, full path of the meterpreter executable and the call trace. It is important to notice that Sysmon will not only detect Mimikatz, but any tool that access lsass process, therefore other tools used to dump credentials from lsass would be detected as well.

In the following articles we will see how we can tune sysmon configuration to detect other attacks.

Collecting locked files from Windows hosts with sleuthkit

Collecting locked files from Windows hosts with sleuthkit

When performing triage forensics in Windows computers full hard drive images are not obtained, instead only a small subset of files that can potentially have critical information are collected in addition to other volatile evidence. Triage analysis is much faster than collecting and analyzing a full forensic image and in many cases it allows to determine which hosts require a full forensic investigation and provide input for a deeper analysis. 

Unfortunately on Windows several files that contain critical evidence are locked by the operating system and cannot be copied through Windows API as most of the files on the computer. This is also true for some malware that implement the same mechanism. One of the options to copy such files is to power off the computer and boot it with a LiveCD/LiveDVD, or remove the hard drive of the computer and connect it to a write blocker to extract the files form other computer. But in many cases powering off the computer is not an option, such as when the computer is mission critical, or when encryption is used that would render the files inaccessible. To be able to collect these files while the computer is on, it is required access the files via raw instead of Windows API.

One of the tools that allows raw access to copy locked files is sleuthkit, as it is free to use and flexible. To copy the locked files we will first use ifind to determine the metadata address of the file to be copied and then run icat to dump the file. Make sure to include all sleuthkit dll files on the same folder that sleuthkit executables and to run it with elevated privileges. The syntax to run ifind and icat command is included below.

ifind.exe -n <file path> \\.\ <logical drive>

ifind will return the metadataAddress to be used in icat command

icat \\.\ <logical drive> metadataAddress

In the following example I show how to collect the system registry hive with this method.

Since sleuthkit does not use graphical user interface, it can be used in wrapper scripts in vbscript, powershell or any other language. With some automation you can collect all the files that you require, such as Window registry files, amcache and NTFS MFT files.

Generating Snort rules to prevent Apache Struts CVE-2017-5638 exploit

Generating Snort rules to prevent Apache Struts CVE-2017-5638 exploit

Attackers usually exploit vulnerabilities in software to achieve code execution or gain more privileges on already compromised system. The most severe vulnerabilities are those that allow remote code execution without requiring elevated privileges, the situation is even worse when the exploit is easy to run. This is the case of Apache Struts CVE-2017-5638 which allows remote code execution due to poor validation of input parameters. As defenders, it is important to detect and prevent such vulnerabilities as soon as possible. 

In the ideal world every system should apply the software updates to fix the vulnerabilities, but in reality it is common that not all systems are patched due to various reasons. Therefore it is useful to have compensating controls that will allow detection and/or prevention of the attack. Even if all the best patching practices are followed, these rules can be used to generate intelligence about our adversaries, that can be used to enhance existing defenses or develop new ones. In this article we will explore how to test this vulnerability in a lab environment in order to develop a snort rule to detect and prevent attempts to exploit it. As a second goal we improve the rule to not only log the exploit attempt web request but also the response sent by the server, which will allow to know if the exploit attempt was successful or not and assign the proper priority for response and containment.

Lab setup and install

The first step will be to get the required software mentioned below to setup the vulnerable lab system. I decided to install it on a Windows host, although it can also be installed on a Linux system if you prefer.

• Java Runtime Environment 8u121
• Apache Tomcat 8.5.13
• Apache Struts vulnerable version, lower than a 2.3.32 or 2.5.10.1. 

Create the environment variable JRE_HOME and assign it to JRE install Path, in my case it was “C:\Program Files\Java\jre1.8.0_121”

Start tomcat web server by running startup.bat script within bin subfolder on tomcat folder.

Check that java.exe is running on port TCP 8080.

Access website http://IPaddress:8080/webapp-name/index.html, default tomcat website must be displayed.

Exploit test

Download and run the exploit from http://www.hackplayers.com/2017/03/exploit-rce-para-apache-struts-cve-2017-5638.html. We can see that the exploit works correctly without any additional modifications; however it returns the HTML code after the executed command, which is not desired.

Exploit improvement

By removing everything after the string “<!DOCTYPE>” we can improve the output.

We run the exploit again and now we only get the result of the command sent.

Snort rule creation

Now that we can successfully exploit the vulnerability in a lab system, we can develop and test the snort rule to prevent the attack. By analyzing the exploit, we can see that the vulnerable header is Content-Type. On normal web requests this header, as its name suggest, is used to indicate the media type of the resource, valid examples of it are “application”, “audio”, “image”, “multipart” or similar, as defined on the following RFC document: https://www.w3.org/Protocols/rfc1341/4_Content-Type.html

The exploit assigns this header to an abnormal value "@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS)." With this information we can create a detection rule.

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (sid:900009; rev:1; msg: "Apache-CVE-2017-563-exploitation-attempt-request";content:"Content-Type"; http_header; content:"@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS)."; content:"com.opensymphony.xwork2.ActionContext.container"; flow:established,to_server; priority:80;)

Snort rule

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (sid:900009; rev:1; msg: "Apache-CVE-2017-563-exploitation-attempt-request";content:"Content-Type"; http_header; content:"@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS)."; content:"com.opensymphony.xwork2.ActionContext.container"; flow:established,to_server; priority:80;)

Run snort

snort -c C:\Snort\etc\snortmin.conf -k none -A console -i 1 -q

Snort detection

Run the exploit again and snort should detect it.

If we open the generated pcap with Wireshark we can see the command that the remote attacker attempted to run, in this case the command whoami.

Snort rule improvement

We have successfully detected the attack attempt, but the response is not captured only the request, therefore only based on the generated pcap by Snort, we cannot know if it was successful. So we will improve the rule to capture the response sent by the struts web server. To achieve this, we will set a condition using flowbits option in  the first rule and will create a second rule that will log the response if that variable is set.

Improved rule with flowbits arguments

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (sid:900009; rev:1; msg: "Apache-CVE-2017-563-exploitation-attempt-request";content:"Content-Type"; http_header; content:"@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS)."; content:"com.opensymphony.xwork2.ActionContext.container";flowbits:set,struts_exploit_attempt; flow:established,to_server; priority:80;)

Rule to log the response

alert tcp $HTTP_SERVERS $HTTP_PORTS -> any any  (msg:"SCILabs-Apache-CVE-2017-563-exploitation-attempt-response"; flowbits:isset,struts_exploit_attempt; flowbits:unset,struts_exploit_attempt;sid:900010; rev:1; priority:80;)

Snort detection of both request and response

We open the generated pcap in Wireshark and we can verify that the output generated by the victim web server has been logged, in this case it is the hostname of the victim computer.

In case that the answer is very large, only the first part of the output will be shown, but that will be enough to determine that the attack has been successful and the nature of the extracted information. Below you can see the results when the attacker ran tasklist command.

Finally to prevent the attack and not just detect it, change “alert” for “drop” on the first rule in case that an IPS device is available and inline mode is setup.