10/10/18

Introduction to Internet of Things (IoT)

Information security, often referred to as InfoSec, is a set of strategies to protect sensitive business information from unauthorised use, modification, disruption, destruction, recording or inspection. InfoSec does not only protect information in transit but also at rest in storage.

InfoSec programs are built around the core objectives of the CIA triad and its primary focus is on sustaining the balance between Confidentiality, Integrity and Availability of business data. This triad ensures that sensitive information is only disclosed to authorized parties (confidentiality), prevent unauthorized modification of data (integrity) and guarantee the data can be accessed by authorized parties when requested (availability).

Is there any difference between cyber security and information security?

Yes! They are both different. Although they are used interchangeably and they both deal with security and protection of information from breaches (information being stolen) and threats but cyber security deals with protecting data in cyber space whereas information security protects data in general.

As it is well known:

“Physical data is often easier to protect in locked filing cabinets, but electronic data requires greater protection”

The field is of growing importance due to increasing dependency on computer systems, the Internet and wireless networks such as Bluetooth and Wi-Fi, and due to the growth of “smart” devices, including smartphones, televisions and the various other small devices that constitute the Internet of Things.

What exactly is Internet of Things?

Internet of Things (IoT) basically includes anything and everything connected to the internet or to each other. These things are always connected, communicate with each other, swapping data with devices and finally uploading it all to the cloud based server. With an increasing pressure in terms of competition to deliver better and fast services, there is a need for the data to travel from any device in the world to provide more perception and control over the elements in our connected lives.

Doesn’t it make one’s life easy? What can one do using a normal alarm clock apart from setting alarm? Snooze time, set multiple alarms etc. With IoT based alarm clocks, if a user sets alarm at 8 am to go to work, this alarm would fetch real time weather and traffic data in order to calculate time required to commute to work and automatically ring some time prior to what is set to compensate for the time delay. The benefits of IoT include efficient resource utilization, reduced human efforts, reduced costs and increasing productivity, real-time marketing, decision analytics, better customer experiences, high-quality data, to name a few. But nothing comes easy! Along with all the comfort it provides, we all should not ignore the risks it brings with it.

IoT security testing is considered less complex and has not been given importance that it deserves, considering it has no human intervention there will be no human error. Human error is the major cause of security breaches, for example a user clicking on a malicious link in an email or is lured into sending their personal details. All this needs human intervention. Therefore, in IoT environment, as there is no one to lure and hence less security challenges or breaches. This supposition is totally deceptive. According to recent research on IoT breaches, it was found that 84% of companies have already experienced some sort of IoT breach in a study involving over 3,000 companies across 20 countries. In fact, in an IoT environment, intruders have more opportunities to breach as its architecture comprises a number of elements that become potential hacker’s targets.

How IoT Evolved?

Chart: Number of IoT connected devices worldwide

IoT is one of the trending topics in the field of Information Technology but let’s also have a quick review of its background and existence.

The term IoT was first coined by Kevin Ashton in 1999 and since then it has come a long way.

A few decades ago people were connected to the outside world in a very limited way which included radios and televisions. Besides, it provided one-way communication experience i.e. one couldn’t talk, interact with it. This slowly changed with the arrival of home computers like the one made by Atari and Commodore in the 1980s and later by the IBM PC. Now users could connect to the outside world but connectivity was still in its infancy. But assisted by Moore’s Law, technology become available, compact and more affordable every year. This is when security and privacy issues made their way into the user’s consciousness. By late 1990s much had changed, people started using mobiles phones over landlines resulting in more and more compact devices every passing year. The market for online commerce boomed as most people were now connected to the internet. By middle of the 20th century, there were rapid changes and advancement in technology.  For instance, the only security concerns of having a watch was it could be physically stolen but nowadays it is about if the watch is disclosing personal information that could enable identity theft or fraud.

The reason IoT is trending is because various IoT products have gained popularity in the market; including smart refrigerators, home thermostats and door locks controlled by smartphones. Let’s take an example of a smart home, a smart home is full of products that understand your preferences, foresee your everyday needs so that you spend less time managing or supervising your house and more time living in it.

What are the security challenges in IoT?

IoT is already trending all over the Information Technology Domain. With this popularity it becomes harder to secure IoT System. There are many vectors a developer has to focus on in order to secure the IoT environment such as:

1.Default credentials & Configuration
2.Ensure high availability
3.Secure web, mobile, and cloud applications
4.Secure communication
5.Authorize and authenticate devices
6.Security Patches
7.Detect vulnerabilities and incidents
8.Manage vulnerabilities

IoT Security is being taken even more seriously due to the past Cryto Mining and DDoS attacks like Mirai Botnet, Stuxnet, Cold in Finland, Brickerbot, Botnet Barrage, etc

Mirai Botnet:
Mirai (Japanese for “the future”) is a self-propagating botnet virus which infects poorly protected Internet connected devices by using telnet service to find devices using factory default username and password. The effectiveness of Mirai is due to its ability to reach other insecure devices and co-ordinate with them to perform DDoS attack against the target. Mirai was used, along with BASHLITE, in the DDoS attack on 20 September 2016 on the “Krebs on Security” site which reached 620 Gbit/s. “Ars Technica” also reported a 1 Tbit/s attack on French web host.

How to address security issues in IoT environment?

IoT Penetration testing is not widely followed because IoT development itself is not yet entirely evolved. In the field of IT many organizations from small-scale to large-scale MNCs are developing IoT related products without expertise and security awareness.

IoT Pentesting should be conducted on all products in UAT environment before deploying it in production. Upon mapping the attacking surface of IoT, we can categorize it as follows:

Hardware Hacking

Hardware hacking consists of analysing internal architecture of the device including internal components to determine attacking surface, firmware extraction, identification of test points, reconfiguring the device’s hardware to bypass authentication and intercept traffic.

Network Testing

Network testing consists of identifying security flaws in the services running on a network or in a cloud server. An attacker can gain access to sensitive information and with readily available exploits, she/he can successfully compromise servers and further compromising entire IoT infrastructure.

Software Hacking

Software hacking consists of penetration testing of Web Application and Mobile Application.

Communication Protocol

IoT devices often use non-standard communication protocols (MQTT, CoAP) and radio waves (BLE, Zigbee) which can be tested for cryptographic security, ability to sniff traffic and modify it from an attacker’s perspective.

What are the common security concerns missed out by developers?

With the growth of new and advanced frameworks for IoT development, developers don’t really need to think about configurations of servers, devices, encryption,etc which makes it efficient and faster to develop an IoT product within given limited time frame. With all these advantages come few of the security flaws which every developer needs to keep in mind before deploying an IoT product. Most common security mistakes which developers make while developing IoT products are:

Default Credentials

Most of the IoT devices in use have default credentials enabled which can be easily found in the documentation section of the corresponding product.

Storing Sensitive Data

Most of the developers might store sensitive data like API Keys, Encryption Keys, FTP Credentials on the devices. (i.e. in mobile devices via Mobile application or IoT devices via firmware.)

Debugging Services Not Disabled

On hardware level, developers often debug the hardware in order to find any flaws so as to minimize it. Usually it is conducted with the help of debugging pins like UART, JTAG, Serial, USB, SWD which are not disabled after the deployment of the devices in an IoT infrastructure. Using these debugging ports an attacker can successfully gain root/shell access to system, dump firmware or flash data from the device and successfully compromise the device.

Missing Patches

Upon deploying devices in an IoT Infrastructure, developers often run the devices with the older firmware and operating system without checking it for software updates and security patches regularly. This might leave a loophole for an attacker to compromise the system.

Services with no Encryption

Often times developers take extra efforts to make the product efficient, which mostly aggrandize the overall user experience. But due to lack of security awareness a developer might disable many crucial security features like Encryption. As IoT devices need to be low power consuming they are configured to use few protocols without encryption which can lead to theft of credentials. For example, Unencrypted MQTT service might lead an attacker to sniff entire traffic transmitted by IoT devices.

What are the best security practices for developers to follow?

Best security practices suggest a developer to avoid exposing any sort of sensitive information on a device, network or application level. It is advised to avoid all common security mistakes to ensure a secure IoT environment.

Here, we are done with the basics of IoT security testing. It basically can be performed by pentester who has proper understanding of IoT architecture and expertise in black box and white box penetration testing.

In further blogs we will discuss all vectors included in IoT Pentesting in detail which would also consist of in-depth impact analysis of most common IoT vulnerabilities. These IoT devices are an integral part of our lives and to secure them you all have got Varutra Consulting to happily assist you.

Author,

Shreeya Patewadiyar

Attack & PenTest Team

Varutra Consulting

09/8/18

Case Study – New way to Exploit Java Deserialization Vulnerability

Introduction

In this case study, we will not focus on how serialization vulnerabilities and how they work because there are plenty of articles on this subject. Instead, we will focus on how to reliably detect and exploit these issues. For this task, all we need to know is that the vulnerability depends on how Java deserializes serialized objects. Default Java classes responsible for the deserialization task first deserialize each serialized object and then try to cast the object to the expected Java class. So, all the received objects are deserialized, even if they are not instances of the expected types; in this case, after deserialization an exception arises when trying to cast the object to the expected type. What makes the issue so critical is the fact that the Java language offers the possibility to add custom code to the class definition that is executed upon deserialization.

For this reason, to be able to achieve Remote Command Execution (RCE) it is necessary to find a “chain” to an object that, once deserialized, allows the attacker to execute arbitrary Java code. Obviously, the class of the chosen object must be loaded in the ClassLoader of the target system. For this reason, usually some “vulnerable” libraries are needed to exploit this issue. These libraries expose the objects used for the exploitation, but the vulnerability itself lies in how Java deserializes the objects, and not in the libraries used for the exploitation. Removing only the “vulnerable” libraries does not protect completely against this issue, because new chains could be discovered and the vulnerability could be triggered anyway.

Once a deserialization issue is discovered, the ysoserial tool can be used for exploitation. This tool generates custom exploitation vectors, based on the “vulnerable” libraries loaded in the target system. In this article we will analyze how to discover and exploit Java deserialization vulnerabilities using a Burp Suite plugin we developed based on ysoserial: the Java Deserialization Scanner.

Installation

The Java Deserialization Scanner plugin can be installed in two ways:

  • Download it directly in Burp Suite from the BApp Store (Extender -> BApp Store). This is the easiest way to get the plugin, but the downloaded version may not be the latest one. At the moment, for example, the latest version (0.5 pre-release) is available only from GitHub (see next method). When the release version will be published, we will submit it to the BApp Store.
  • Download the latest release from GitHub and manually install the JAR from the Burp Suite Extender tab (Extender -> Extensions -> Add)

Serialization

Serialization is the process of converting a complex object into a representation that can more easily be transmitted.

  1. To transfer over a network or write to a persistent store
  2. AKA “marshalling” or “pickling”

Deserialization is the process of recreating the object from that representation.

  1. As when receiving data over a network
  2. AKA “unmarshalling” or “unpickling”

Several Java technologies are layered over serialization:

  • Remote Method Invocation (RMI)
  • Java Management Extensions (JMX)

PoC: Serialization Process

Trust Boundaries

Web Application often contains multiple components & libraries each component may operate in one or more trusted domains.

  • Details of trusted domains driven by architecture, security policy, required resources, functionality, etc.

Examples:

  1. Component A can access file system, but lacks any network access.
  2. Component B has general network access, but lacks access to the file system and the secure network.
  3. Component C can access a secure network, but lacks access to the file system and the general network.

Deserialization of Untrusted Data

In Java, reading a Data object from a serialized stream is as simple as:

ObjectInputStream in = new ObjectInputStream( inputStream );

return (Data)in.readObject();

The problem is that there’s no way to know what object Deserializing before it gets decoded.  So an attacker can serialize a bunch of malicious objects and send them to web application. Hence, the call of readObject (), it gets too late. The attacker’s malicious objects have already been instantiated, and have taken over entire server.

Detection

The detection of deserialization vulnerabilities is not always a simple task. By generating a payload with ysoserial and sending it to the target application, usually we may either get a Java Stack Trace (and if we are lucky we can discover the presence of the issue, but only with a knowledge of the vulnerable library targeted) or no verbose output at all.

Therefore, in order to reliably detect the presence of the vulnerability, we modified ysoserial to generate Java native sleep payloads instead of RCE payloads and we added these payloads to the Java Deserialization Scanner. For this task it is necessary to use Java native sleep payloads, because the Java sleep call is synchronous; executing a system sleep using the default RCE payloads generated by ysoserial would be useless, because they are asynchronous and we would get the response from the server before the end of the sleep command, regardless of the presence or the absence of the issue.

In the latest version of the plugin, we added two new methods to further improve detection:

  • DNS
  • CPU

In order to generate payloads that execute native Java DNS resolution, we modified ysoserial again. Usually, DNS resolution requests are the ones that are most likely to bypass corporate firewalls and consequently are a quite good detection method. In general, the timing method is more reliable and preferable, but the DNS method can be useful on unstable systems or highly delayed networks. Thanks to Burp Suite Collaborator, it is not necessary to have authority on a DNS zone, and everything can be done within the Burp Suite pro tool.

The CPU detection method is based on Wouter Coekaerts’ SerialDOS work: it is able to detect deserialization issues without the presence of any vulnerable library. The payload is based on a system object (java.util.HashSet) that employs many CPU cycles for the deserialization task. SerialDOS was created as a PoC of a Denial of Service (DoS) attack, but by decreasing the CPU cycles necessary for deserialization it can also be used as a detection method. This payload is very useful to detect if the application endpoint actually performs Java deserialization and if it implements a strict whitelist.

approach. If this check gives a positive result there is also the possibility that the target application implements a whitelist approach that permits HashSet class of java.util package. In this case the application is still vulnerable to DoS attacks (using full-power SerialDOS payloads).

Demonstration

Now, let’s demonstrate how to use desearlization plugin for detection. The detection is integrated in Burp Suite Active and Passive Scanner. By default, Time and DNS checks are added to Burp Suite scanner, but they can be disabled from the Configurations panel of the plugin, in the section “Automatic scanner configurations”:

In order to reduce the number of requests executed by the Active Scanner, the checks added by the plugin are executed only if a serialized object is present in the original request. The payload is encoded with the same encoding found in the original request (for instance, if the serialized object is encoded in BASE64, the exploit vector will be encoded in BASE64 and so on). The currently supported encoding formats are:

  • Raw
  • BASE64
  • ASCII HEX
  • GZIP
  • BASE64 GZIP

The CPU detection method is not included by default in the active scan checks, because it must be used with caution: sending a huge number of “light” SerialDOS payloads may still cause problems on old or highly-loaded systems. In order to execute checks with custom insertion points or use the CPU payload, the plugin provides the “Manual Testing” tab, in which the user can select the insertion point (currently only one at a time is supported) like in the Burp Suite Intruder, choose the check type (DNS, Time, or CPU), choose the preferred encoding and test the parameter. By selecting Sleep or DNS checks, the plugin tests all the supported vulnerable libraries, while with the CPU check the plugin will use a library-independent CPU payload. By default, detected issues are automatically added to the global issues of the host, but this behavior can be disabled in the “Configurations” tab. In the same tab it is possible to enable verbose mode, in order to inspect the requests and their responses in the results pane.

The requests to test can be manually inserted in the Manual Testing tab or can be sent from other Burp Suite tabs using the contextual menu that opens with the right button of the mouse:

PoC: Menu for exploitation

The configuration of the Manual Testing tool is explained in the following PoC:

PoC: Steps for Detection of Serialization Vulnerability

Exploitation

The “Exploiting” tab offers a comfortable interface to exploit deserialization vulnerabilities. This tab uses the ysoserial tool to generate exploitation vectors and includes the generated payload in a HTTP request. ysoserial takes as argument a vulnerable library and a command and generates a serialized object in binary form that can be sent to the vulnerable application to execute the command on the target system (obviously if the target application is vulnerable). The Exploiting tab supports the same encoding formats as the detection sections of the plugin.

Now, let’s demonstrate how to use the plugin for exploitation. First, we need to open the “Configuration” tab and insert the path where we have a copy of the ysoserial tool (ysoserial is necessary only for exploitation; detection payloads are already included in the plugin):

PoC: Configuration Tab

Step: 1 – Then, as we saw for manual testing, it is possible to insert the request manually or to send it from other Burp Suite tabs using the contextual menu that opens with the right button of the mouse. The user can then select the insertion point (currently only one at a time is supported) like in the Burp Suite Intruder, insert the ysoserial command (refer to the ysoserial manual for syntax) and click the correct “Attack” button, based on the desired encoding. The configuration of the “Exploiting” tool is explained in the following PoC:

PoC: Steps to Perform Manual Exploitation

Step: 2 – As shown in above PoC, we have used burp collaborator to check whether it is exploitable with the help of ping command. Burp Suite Collaborator is an external server added to Burp Suite in order to discover out-of-band vulnerabilities and issues that can be found only from external service interaction. It is a great tool and increases the power of Burp Suite Scanner a lot. However, a simple ping payload that does a DNS query confirmed that the system is indeed vulnerable.

PoC: DNS Query to Burp Collaborator Server

Step: 3 – For further exploitation, we can use windows commands like nslookup to check if any DNS query is received, so that we can confirm the vulnerability as shown in following PoC.

PoC: Nslookup

Step: 4 – As we know that, it is vulnerable for serialization attack so that we can craft our payload as harmful as possible and we have clue about that it is using windows server. Hence, we can craft the payload accordingly like we will send the command restart to server. Payload as motioned in the following PoC.

PoC: Restart Command sent to Windows Server

Step: 5 – After the command execution server will get restart and it will show service unavailable error. Our exploitation part will get successful. Attacker can do remote code execution (RCE) by using serialization vulnerability.

PoC: Server gets restart and it will display “Service Unavailable”

Additional considerations

Once the vulnerability is confirmed, the PenTester may need to do some trial and error of commands to execute in order to get a shell. Here are a few useful tips getting that working:

  • Make sure to test various reverse shell commands (see Reverse Shell Cheat-Sheet)
  • Common collection payload may fail on certain JVM (IBM J9 for example). Mathias Kaiser made a payload specifically to support less common JVM: see CommonsCollections6.
  • If a security manager is enforced, may need to craft a custom payloads. One prevalent approach is to find the path to the web root directory and write a web shell that could be later executed.

 

Author,

Tanmay Nashte
Attack & PenTest Team

Varutra Consulting

09/4/18

Advisory | Microsoft Zero Day Vulnerability – Windows Task Scheduler Local Privilege Escalation Vulnerability

Introduction

A previously unknown zero-day vulnerability has been disclosed in the Microsoft’s Windows operating system that could help a local user or malicious program to obtain system privileges on the targeted machine.

The vulnerability is a privilege escalation issue which resides in the Windows’ task scheduler program and occurred due to errors in the handling of Advanced Local Procedure Call (ALPC) systems.

Advanced local procedure call (ALPC) is an internal mechanism, available only to Windows operating system components, that facilitates high-speed and secure data transfer between one or more processes in the user mode.

Exploit for this vulnerability has been shared by a hacker named “SandboxEscaper” and the exploit code is currently available on public repositories like GitHub. However the current exploit works only in windows 64 bit operating systems. For a complete solution, we have to wait for Microsoft to respond until the scheduled September 11 Patch.

Affected Versions

1) Windows 10

2) Windows Server 2016

The exploit would need modifications to work on operating systems other than 64-bit (i.e., 32-bit OS). Also it hard codes prnms003 driver, which doesn’t exist in certain versions (e.g. on Windows 7 it can be prnms001). Compatibility with other windows versions may be possible with modification of the publicly available exploit source code.

How to Detect?

It is possible that the original windows processes can be replaced with the malicious program shared by the hacker. So we can detect those exploits by checking whether the original windows processes have been replaced.

  1. Look for spoolsv.exe under abnormal processes (or another Spooler exploit).
  2. Look for connhost.exe under abnormal processes (e.g. the Print Spooler).

Spoolsv.exe:

It is called Windows Print Spooler. This service spools print jobs and handles interaction with the printer. By disabling the Windows Print Spooler service you wouldn’t be able to print more than one document at a time, and any documents not immediately sent to the printer wouldn’t print.

Risk: If you turn off this service, you won’t be able to print or see your printers.

Fig: Checking for suspicious processes

Connhost.exe:

It is called Console Windows Host. This service is present in Windows 10 and using this, windows command prompt can show the same window frame like the other programs. It also allows you to operate the cmd prompt and users to drag and drop a file directly into it. This Microsoft Console Host program resides in “C:\Windows\System32” and should not be removed.

This process is closely related to windows CSRSS(Client Server Runtime System Service) a protected process you can’t terminate, which is responsible for console windows and the shutdown process, which are critical functions in Windows.

Risk: If you turn off this service, windows CSRSS service will also crash because conhost.exe runs under csrss.exe, so there is a high chance for the system to become unusable or shutdown.

Fig: Checking for suspicious processes

Recommendations

  1. Do not remove/disable any original system processes without confirmation.
  2. Monitor and block any local users from gaining administrator privileges by using SIEM tools.
  3. Detect all the malicious processes by the name of genuine ones by using Behavioral Analysis.
  4. Network traffic analytics should continue to be used to detect anomalous traffic going across the network and to spot where users are behaving in a way that they historically don’t.

References

  1. https://www.kb.cert.org/vuls/id/906424
  2. https://doublepulsar.com/task-scheduler-alpc-exploit-high-level-analysis-ff08cda6ad4f
  3. https://threatpost.com/microsoft-windows-zero-day-found-in-task-scheduler/136977/

 

Author,
Jinto T.K.

SOC Team

Varutra Consulting Pvt. Ltd.

11/21/17

Thick Client Penetration Testing – Exploiting JAVA Deserialization Vulnerability for Remote Code Execution

Thick Client? What do you mean by that?

Thick client is the kind of application which is installed on the client side and major of its processing is done at the client side only which is independent of the server. Like we installed some players or .EXE files in our windows system.

Main difference between Thin Client and Thick Client

Thin client is the browser based application which is having database (server) only in the back end & there is no need to install thin client applications at the client side. Also they are lightweight and do not occupy more space at the client system, whereas Thick client needs more storage space in order to install it on client side.

What is Java Serialization?

Java serialization offers an object to convert itself into a stream of bytes that includes object data to store it into the file systems or to transfer it to another remote system.

After serialize input (stream of bytes) is written to a file, it can be read from the file after deserialization process like stream of bytes then converted to the object again into the memory.

Classes ObjectInputStream and ObjectOutputStream are high level streams that contain the methods of serialization and deserialization.

Why it is vulnerable?

The Apache Commons Collection (ACC) Library is the main reason behind the successful RCE attack. This library has the dangerous class InvokerTransformer which an attacker abused to gain access to remote system.

The InvokerTransformer’s goal is to transform objects in a collection by invoking a method. Attackers take advantage of this functionality and manage to call any method they want.

To create malicious method attacker uses readily available tool called ysoserial

Here is the link to the tool: https://github.com/frohoff/ysoserial

The attack can be summarized as:

  1. A vulnerable application(Thick Client) accepts user supplied serialized objects
  2. An attacker creates malicious payload into stream of bytes (serialization process) to invoke any class/method they want and sends it to application.
  3. Then the application reads the stream of bytes and tries to construct the object from it(Deserialization process)
  4. During deserialization the malicious payload gets executed on target system resulting into compromised system.

 

How to Perform this Attack?

Step 1: First we should know what is the IP and Port the Thick client is communicating to, in order to intercept the request/response using burp suite.

In cmd ping the thick client URL to know the IP.

In our case lets the assume the URL for thick client is http://thickclient:8081 and after pinging this URL we got the IP 192.168.0.1 and port is 8081

Make the changes in the burp proxy

 

Step 2: Edit the host file in your system so that the server host (http://thickclient:8081 in our case) points to local host and our burp proxy can intercept the request.

 

Step 3: Run the thick client and intercept the request in burp

 

Step 4: Now, we will replace this serialized data with our malicious serialized data, which will be de serialized server side and our command will be executed. For this purpose we will use a tool called ysoserial (download: https://github.com/frohoff/ysoserial)

Run this tool with following syntax and create our malicious serialized payload (the IP should be your system IP and port I am using here is 4444)

The output will be somewhat like below

 

Step 5: Now on another side listen to incoming connection from server where our malicious data will get execute. We are using netcat tool for this. You can get this tool here: https://nmap.org/download.html

 

Step 6: Now our payload is created in a file (test.out in my case), we will use Burps ‘paste from file’ option to paste our malicious payload in the intercepted login request as follows and will then execute our malicious data.

 

Step 7: Now to check whether our command got executed or not on the server, netcat to the connection and you can see in below screenshot that we got incoming connection form the server, meaning our malicious code get executed on the server.

 

Further Reading:

  1. https://www.owasp.org/index.php/Deserialization_of_untrusted_data
  2. https://dzone.com/articles/why-runtime-compartmentalization-is-the-most-compr
  3. https://www.synopsys.com/content/dam/synopsys/sig-assets/whitepapers/exploiting-the-java-deserialization-vulnerability.pdf

 

Author
Pranav Jagtap.

Attack & PenTest Team,

Varutra Consulting

11/6/17

What Makes Penetration Testing Impactful – Post Exploitation

As a penetration tester, we often come across this riddle – What Makes Penetration Testing Really Impactful. As per penetration testing methodology – we identify vulnerability, prioritize the vulnerability considering the criticality of impacted assets, we obtain/modify/create an exploit, compromise the target system and we are all excited and happy. BUT, ‘whoami’ command output in a black screen may not mean anything to C-Suite executives, who have never opened the command prompt, or rather not need to.

So how do you explain C-suite executives the consequences/impact of the exploit which you just performed?

Here comes a skillset to our rescue – Relevant Post Exploitation.

  • First understand your client, their nature of the business, their clients and criticality of data etc.
  • Prioritize identified vulnerabilities and exploits to target important assets
  • Obtain/ex-filtrate the information which matters to them most
  • And they will be like WOW

To explain my point, I will walk you through some of my personal experiences in my journey as a penetration tester.

Example 1. 

TL;DR: Test Server -> Apache Exploit -> In-House App  -> Hardcoded DB Credentials -> Central Database Compromise

In one of my earlier engagement, automated scanner identified an instance of open apache manager console and I tried Metasploit for exploitation but observed that anti-virus installed in target machine was deleting Metasploit payload. So I switched to manual method and successfully compromised the server. Hence concluded that engagement is successful, until, client destroyed my enthusiasm saying that it’s a test machine with not much of IMPORTANCE.

Open Apache Tomcat Manager Console

Upload Of Backdoor JSP File

Code for Backdoor JSP

Proof-of-Concept of Exploitation

I had no intention of letting that issue go, so I attacked that machine again with a very definitive purpose – Obtain something critical and/or sensitive.

I created a dummy user with LOCAL ADMINISTRATIVE privileges, started the RDP and logged in using RDP just to make my life easy, relatively

Creation of Dummy User – TestUser

RDP Connection To Target System

I realised there is an in-house application in documents directory (.jar file). Out of curiosity, I just ran it, and it seemed to be data entry application. While I was doing a blind exploration in the application, a message box popped up stating that ‘Read all the entries from database successfully’. Interestingly, the application didn’t ask for any DB credentials at all.

Then, naturally, I opened the application in jd-gui and DB credentials were hard-coded in the application and to my utmost surprise, it was the credentials for central DB of the organization.

Hard-Coded DB Credentials

I used that credentials to login into DB and I was able to access almost all (read all) information about the organization, details of which I can’t mention here for obvious reasons.

Bottom line – Engagement become successful then, from client point-of-view and it made the life of developer of mentioned application [very] difficult.

 

Example 2.

TL;DR: Kiosk Device ->Windows XP -> MS08-067 -> Pass-the-Hash -> Entire Network -> (Very) Important Person Desktop Screenshot

In another one of my engagement, automated scanner identified that Windows XP machine is running in client environment and our favourite MS08-067 popped me a reverse Meterpreter shell with relative ease, but again, it turns out to be Kiosk Device and client were not very interested in the compromise

Proof-of-Concept of Exploitation

This time I explored the entire system but didn’t identify anything significant. Then I took a different route – Pass-the-Hash attack. I dumped the password hashes using Meterpreter and used smbexec (awesome tool) to escalate/replicate my attack to the entire network.

Identification of Domain Admin User

Replicate of Attack to Entire Network

Example 3.

TL;DR: McAfee ePO Server -> JBoss JMX Console Deployer Upload and Execute -> Combined with McAfee Weak Encryption Vulnerability -> McAfee ePO Server Password Compromised

This compromise was relatively simple. First automated scanner identified an open JBoss JMX console and then, I was able to obtain a Meterpreter reverse shell using the Metasploit exploit module – JBoss JMX Deployer Upload and Execute.

Proof-of-Concept of Exploitation

 

After a bit of reconnaissance, I realized it was an ePO server installed with vulnerable version – ePO 4.6. A ready to use post exploitation module of Metasploit – epo_sql, fetched the ePO server credentials for me.

epo_sql Metasploit Module in Action

So, in above scenarios, by aligning post-exploitation techniques to client requirement and with a ‘dig deeper’ approach, I represented technical vulnerabilities into the form of business risk. Effective post exploitation makes the client understand the implications from the business perspective and helps them to prioritize the mitigation strategy.

In conclusion, I would like to say that relevant post exploitation is very crucial for a penetration testing engagement, especially when the client is more emphasizing on measuring the risk not counting the vulnerabilities. There are numerous other ways and tools for making post exploitation a real fun.

Further reading

 

Author
Pramod Rana

Attack & PenTest Team,

Varutra Consulting

06/2/17

Beware Android Users – CLOAK AND DAGGER is here to exploit you

The WORLD has still not got over with the WannaCry ransomware menace and here comes one more!

People have been debating for years over Android V/s iPhone.  It’s the ultimate battle. And it’s not ending anytime soon. But there is something Android users would not like to hear and iPhone users would rejoice about their choice– Android users are not safe!

Yes, the Android OS which you and I are using (even the latest Android 7.1.2) is not safe, all your credentials, data are at major risk.

Android users all over the world have always been a very popular target for criminals. It’s not even a month researchers uncovered several malicious Android applications masqueraded as “Funny Videos” on Play Store which had over 5000 downloads; it did not only provide users with “Funny Videos”, but had ‘BankBot banking Trojan’ which also stole victim’s banking password.

Till now everyone thought that malware requires user interaction in order to get installed on any device or click on a link in a phishing email, or the installation of software from an unverified source. But Researchers now have discovered a new attack, called “Cloak and Dagger”, that works against all versions of Android. Yes, even the latest version of Android isn’t safe from this attack.

It allows an attacker aka hackers to smoothly and silently take complete control of your device and steal private data of the device user like login credentials, using key logger and also by analyzing the keystrokes, personal chats, contacts without the users concern.

This stealthy attack was first discovered researchers at the Georgia Institute of Technology in Atlanta last August. They were in discussion with Google and some vulnerabilities were fixed over months with updates, but some of them are still present in the latest version of the platform.

How does the attack take place?

Cloak and Dagger attack is caused by 2 specific permissions the SYSTEM ALERT WINDOW and the BIND ACCESSIBILITY SERVICE.

What makes it even more dangerous is the fact that the SYSTEM ALERT WINDOW permission is automatically granted for applications installed from Play Store, and it can easily trick the user into granting the BIND ACCESSIBILITY SERVICE permission and bootstrap the whole attack.

This means, all you have to do is download an application (malicious) from the Android play store and rest will be taken care by the malicious code.

Let’s know more about the permissions

SYSTEM ALERT WINDOW

This System alert window is nothing but “Draw over other apps”, used to draw overlays on top of other applications. According to the official documentation, “Very few applications should use this permission; these windows are intended for system-level interaction with the user.” Despite this warning, the SYSTEM ALERT WINDOW is used by popular applications such as Facebook, LastPass, Twitter, and Skype. Furthermore, it is found that about 10.2% (454 out of 4,455) of top applications on Google Play Store require this permission.

This means that, since the SYSTEM ALERT WINDOW permission is automatically granted, the user will not be notified at any point.

BIND ACCESSIBILITY SERVICE

This permission is accessible for the Android users with disabilities. It can discover UI widgets displayed on the screen, query the content of these widgets, and interact with them programmatically. This permission is less popular than the previous permission. Among the top 4,455 applications on the Play Store, it is found that 24 applications use this service. It is worth noting that none of them are purely designed for people with disabilities! In fact, most of them are security applications such as password managers (e.g., app lockers, desk launchers, and antivirus applications. It is also found that 17 of these applications require both permissions.

The combination of these two permissions leads to a stealthy, very popular attacks, called “Cloak and Dagger”. It is called so as they take place undercover without user’s knowledge.

Conceptually, Cloak and Dagger is the first class of attacks that has successfully and completely compromise the UI feedback loop. It can modify what the user sees, detect the input/reaction to the modified display and update the display to meet user expectations. Similarly, the user can fake input, and it still manages to display to the user what they expect to see, instead of showing them the system responding to the injected input.

This sharply contradicts the existing attacks that utilized either SYSTEM ALERT WINDOW or the BIND ACCESSIBILITY SERVICE permissions. With the use of only SYSTEM ALERT WINDOW permission (e.g., GUI confusion attacks), the attacker can modify what the user sees, but cannot anticipate how/when the user reacts to the modified display, and hence fails to change the modified displayed content accordingly. Similarly, by using BIND ACCESSIBILITY SERVICE permission alone, the attacker can inject fake user inputs, but the attacker here cannot prevent the user from seeing the results of these fake inputs displayed on the screen. As a result, in both cases, with only one of the two permissions, the user can very quickly discover the attack.

On the contrary, in Cloak and Dagger,  the combination of the two permissions allows an attacker to both modify what the user sees and inject fake input, all while maintaining the expected “User experience”.

The potential consequences of the Cloak and Dagger attacks include almost complete control over the victim’s device – context-aware clickjacking attacks, perform (unconstrained) keystroke recording, steal user’s credentials, security PINs, and two-factor authentication tokens, and silently install a God-mode application with all permissions enabled.

According to the research, the flaws allow malicious applications downloaded from the Google Play Store to take control of the operating system’s user interface feedback loop. Thereby taking control of the device. What makes it more dangerous is the fact that user would be completely unaware of this malicious activity taking place.

The researchers have examined the attack and explained how they got on the Google Play Store to perform Cloak & Dagger attacks. They first submitted an application which got approved just after few hours and it is been said that it is still available on the Play Store. That application contained a non-obfuscated functionality to download and execute arbitrary code (to simulate malicious behaviour).

Once installed, the researchers say the attacker can perform various malicious activities including:

  • Advanced clickjacking attack
  • Unconstrained keystroke recording
  • Stealthy phishing attack
  • Silent installation of a God-mode application (with all permissions enabled automatically)
  • Silent phone unlocking and arbitrary actions (all this while keeping the screen off)

The attack has been successfully performed on 20 people by Researchers at Georgia Institute of Technology and none of them were able to detect any malicious activity.

It is important to mention that, starting from Android 6.0, this permission is treated differently from the others. The user needs to manually enable this permission through a dedicated menu. If an application is installed by the latest version of the official Play Store app, the SYSTEM ALERT WINDOW permission is automatically granted (users will not be notified at any point).

Researchers have reported their findings to Google, which promptly acknowledged all the problems that have been raised. However, no comprehensive patch is available yet: while few of the specific instances of problems can be fixed with a simple patch, most of the attacks are possible due to design shortcomings that are not easily addressable.

What can you do to protect yourself?

The easiest way to mitigate the issue and disable the Cloak and Dagger attacks in Android 7.1.2 is to turn off the “draw on top” permission by heading on to:

Settings → Apps → Gear symbol → Special access → Draw over other apps.

Don’t expect a true fix for this issue to come to your device anytime soon. However, “Android O” will partially address this flaw by disallowing malicious applications from completely drawing over the entire screen and generate alerts via notification if an application is actively drawing an overlay. With these changes, it’s less likely that a malicious application can get away with the exploit if the user is attentive. Thus, until Android O comes along (which is supposed to come by 3rd quarter this year), users don’t have much they can do to avoid being trapped, beyond regular security practices. It is still doubted if it would be able to detect all such cases. Install applications only from trusted sources, don’t install random applications, and, keep a close watch on what permissions an application is asking for.

All you can do is to check application permissions before installing it. And monitor what permissions are being granted to each application you install. Check if any application is asking more than what it is meant for, just do not install it.

 

References:

http://cs.ucsb.edu/~yanick/publications/2017_oakland_cloakanddagger.pdf

http://cloak-and-dagger.org/

http://thehackernews.com/2017/05/android-hacking-technique.html

http://mashable.com/2017/05/23/the-jammer-mini-roller/

http://gadgets.ndtv.com/apps/news/android-attack-cloak-and-dagger-uc-santa-barbara-geogia-institute-technology-google-1704400

Cloak And Dagger Exploit uses Overlays and Accessibility Services to Hijack the System

http://thehill.com/policy/cybersecurity/335126-researchers-spotlight-cloak-and-dagger-attack-against-android-devices

 

Author:

Shreeya Patewadiyar

Attack & PenTest Team,

Varutra Consulting

05/18/17

Buffer Overflow Attacks

Introduction

Buffer is a storage place in memory where data can be stored. It’s mostly bound in a conditional statements to check the value given by the user and enter it in to the buffer and if the value entered by user is more than the actual size of the buffer then it should not accept it and should throw an error. But what most of the times happens is buffer fail to recognise its actual size and continue to accept the input from user beyond its limit and that result in overflow which causes application to behave improperly and this would lead to overflow attacks.

In this article we will demonstrate buffer overflow attack on the Minishare 1.4.1 application which is vulnerable to buffer overflow attack.

Download link: https://sourceforge.net/projects/minishare/files/OldFiles/minishare-1.4.1-fin.exe/download?use_mirror=master&download=&failedmirror=kent.dl.sourceforge.net

And install it in windows XP (VM) to have better results.

I am using Kali Linux as an attacker machine and also install Immunity Debugger on your windows XP machine to debug the application that we are going to exploit.

Step 1: Install Minishare 1.4.1 on Windows XP machine and check the port on which it is running. In my case its running on port 80.

Step 2: Now we will create one python script. We are sending 2000 A’s to the target to see whether it’s getting crashed or not.

Step 3: But before that we need to give permission to our file so in my case its 1.py and IP 192.168.230.131 is of my Windows XP machine.

Step 4: Now the Minishare should be running on your Windows XP machine and after running above python script the application should get crashed and check the offset by clicking on to Click here and it should be hex value of A which 41.Now from this we can conclude that the application is not able to handle this much (2000 A’s) and get crashed. In short EIP (Instruction Pointer) is overwritten with AAAA leading to crash

Step 5: To check which offset value of buffer overwrites EIP we will use the ruby script which is readily available in our metasploit modules. As shown in below screen shot go to path in usr->share->metasploit-framework->tools->exploit.

Step 6: Copy the pattern generated into python script as below.

Step 7: Now open the Minishare in Immunity Debugger to check the value of EIP (Instruction Pointer) and ESP (Stack Pointer) register. You can see that the EIP is overwritten with ‘36684335’ and ESP is overwritten with ‘Ch7Ch’.

Step 8: To check the offset between EIP and ESP we have tool in metasploit framework.Just go to path as shown below.

Step 9: We can conclude that EIP start from 1787 and contain four characters and ESP starts from 1791.

Now we will over write 4 bytes after 1787 with character B, in order to check that our calculation of EIP is correct. In order to that the changes has been made in the script as below:

Step 10: As seen below our calculation is correct as EIP is overwritten with 424242 i.e. BBB (hex) and ESP is overwritten with CCC.

Step 11: Now here comes the dreaded part of finding bad characters. Bad character are \r\n (\x0a\x0d in hex) which also called Carriage return (\r) and Next Line (\n).If the \x0d and \x0a are present anywhere in the buffer then it get terminated and rest of the remaining buffer will not be taken into consideration. Most of the time \x00 is bad character.

Now we will add the series of characters from \x01 to \xff into my buffer and check it in debugger to check for bad characters.

Step 12: From the below screenshot we can see that 4141 and then 01,02….0C then after that 0D is expected but the buffer breaks which means bad character is present. So remove the bad character which \x0d and re run the code above and check whether the sequence gets completed or not.

Step 13: The series is now get completed.After that we will search for JMP instruction.

So basically when the crash occurs we want the content of ESP to be executed by EIP.

This means we have to make EIP jump to ESP. This can be achieved by executing JMP ESP instruction.

We will open the server and look for the executable modules in Immunity Debugger that contains JMP ESP instruction and then we will overwrite memory address of that instruction on EIP.

From below screenshot we can see that USER32 has JMP ESP Instruction

Note the JMP ESP address 77D8AF0A and make it reverse \x0a\xaf\x8a\xd8\x77.

Step 14: Now we need to create payload using msfvenom by entering below command to get the reverse shell.

 

Step 15: Now our final script will look like this which will also include code generated from msfvenom command.

Step 16: Run the exploit and on kali machine listen to incoming connection like below. We got reverse shell on our Windows XP machine.

Conclusion: Minishare is vulnerable to buffer overflow attack and this vulnerable application is already installed on windows xp. Due to exploitation of Minishare application we got the reverse shell on the target system.Kindly do not install the applications which are already having such vulnerabilities which may cause a huge damage to your system.

AUTHOR:

Pranav J.

Attack & PenTest Team,

Varutra Consulting

01/9/16

Mobile Vulnerability Database (MVD)

 gpmvd

 

Introduction:

The Android operating system is the most widely used operating system for mobile devices. Android has around 82.8% (IDC) market share and is a favourite  target for attackers. One of the latest vulnerabilities, StageFright, allows the attacker to execute arbitrary code on an Android device which takes advantage of a flaw that exists in media library stagefright. Considering other platforms such iOS, Windows, and Blackberry, Varutra is maintaining the vulnerabilities related to mobile operating systems in the Mobile Vulnerability Database (MVD). Varutra has developed the MVD application for the Android platform which identifies vulnerabilities on the Android operating system and provides detailed vulnerability reports, and which is freely available on Playstore for all Android users. The applications for other platforms are under development and will be available very soon for iOS, Windows and Blackberry.

MVD (Mobile Vulnerability Database):

Mobile Vulnerability Database, or MVD, is a unique place to find out about vulnerabilities reported worldwide for Mobile Platforms.

A user can browse through vulnerabilities specific to their mobile platform and the particular version. The objective of MVD is to give a common place for mobile users to get acquainted with the vulnerabilities that might exist on their devices. Users can choose to receive specific vulnerability details as a report via Email.

1. MVD

Platforms covered by MVD

At present MVD covers major mobile smartphone platforms such as Android, Blackberry, iOS and Windows Phone.

2.1 PlatformsMVD Web Application:

MVD is also available in web interface where users can search and gather information related to mobile operating system vulnerabilities by simply searching by the Common Vulnerabilities and Exposures (CVE ID) vulnerability category.

A user can browse through vulnerabilities specific to their mobile platform and the particular version. The objective is to give a common place for mobile users to get acquainted with what vulnerabilities might exist on their devices. Additionally, users can choose to receive specific vulnerability details as a report via Email.

Web Application

For more information: http://varutra.com/mvd/

MVD Platforms:

MVD is developed for mobile operating systems such as Android, iOS, BlackBerry and Windows

3.1 MVD PlatformsTerminologies related to MVD

What is KVID?

KALP Varutra ID (KVID) is a unique number assigned to each reported vulnerability; maintained in the MVD database by the Varutra team.

E.g. KVA01 for Android, KVB01 for Blackberry, KVI01 for iOS and KVW01 for Windows Phone

Note: KALP stands for Knowledge Attained Learn Process. It is a blog for information published on the World Wide Web and consisting of discrete entries (“posts”) typically displayed in reverse chronological order.

What is CVE?

Common Vulnerabilities and Exposures (CVE) is a dictionary of common names (CVE Identifiers) for publicly known information security vulnerabilities maintained by the MITRE Corporation. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this “common enumeration.”

For more information: https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures

What is CVSS?

Common Vulnerability Scoring System (CVSS) is a vendor agnostic, industry open standard designed to convey the severity of vulnerabilities. CVSS scores may be used to determine the urgency for update deployment within an organization.

For more information:

https://en.wikipedia.org/wiki/CVSS

CVSS scores can range from 0.0 (no vulnerability) to 10.0 (critical).

E.g. BlackBerry uses CVSS in vulnerability assessments to present an immutable characterization of security issues. BlackBerry assigns all relevant security issues a non-zero score. Customers performing their own risk assessments of vulnerabilities that may impact them can benefit from using the same industry-recognized CVSS metrics.

MVD Feature:

MVD feature How to get the Vulnerability Report on Email?

The user can register with their Name and Email ID on Register for Vulnerability Report and then select the required platform and version to receive the report. A module is being implementing where once a user is registered they will get automatic updates for any new vulnerabilities reported in the platform and version specifically chosen by the user.

4.1 Vulnerability Report

 Users can now access the MVD on their Android Smartphones, Tablets.

The MVD Android application covers major mobile smartphone / tablet platforms such as Android, Blackberry, iOS and Windows Phone. Users can register with their Name and Email ID on “Register for Vulnerability Report” and then select the desired mobile platform and version to receive the report. Users can also download the MVD Android application on your device from Google Play:

https://play.google.com/store/apps/details?id=com.varutra.mobilevulndb&hl=en

 Conclusion: 

MVD very useful for mobile phone users who are interested in knowing the vulnerabilities in their Android phone and want to mitigate the vulnerabilities. Additionally, MVD is useful for security researchers interested in knowing the vulnerabilities present in multiple mobile operating systems.

For more Details reading Pentestmag

Author:

Attack & PenTest Team,

Varutra Consulting

10/27/15

External Penetration Testing – Case Study

Penetration Testing

ABSTRACT

External Penetration Testing consists of a reviewing and assessing the vulnerabilities that could be exploited by external users/Hacker without any credentials or without having any access to target system.

The assessment basically plays vital role in ensuring perimeter security, infrastructure security of the organization which may or can leads to the impact of business as Sensitive information present. Also it will ensure about possibilities of external threats/attackers & behavior of them as well, to minimize risk and threat ratio External Network Security Assessment has taken into consideration.

If External Network Security is not taken seriously, will leads to information/data theft which will be damage to the image of the company/organization’s brand and ultimately it will affect whole business of the organization. This will show whether there has been a Return on Investment (ROI) of existing implemented security controls, such as firewalls, intrusion detection and prevention systems, or implemented application defenses.

The role of a pentester is to perform penetration testing of the internet facing network, find vulnerabilities and try to exploit vulnerable systems/network to obtain confidential and sensitive information which can or may compromise the network perimeter and suggest measures to remediate the security issues to secure the network.

Varutra’s penetration testing methodology is in accordance with best standards and follows guidelines from OSSTMM, OSINT, NIST and OWASP. It makes use of our extensive experience in penetration testing and security assessment to discover previously missed vulnerabilities providing an impact level of security assurance.

This is a case study of an external network penetration test that Varutra performed on one of the overeas client organization proving egovernance. Some of the information has been changed or modified to maintain confidentiality.

BACKGROUND

The client network was consisting of various technologies such as firewall, routers, IPS, web servers etc.  The goal was to understand the current level of external risks which may compromise the sensitive data of the customer as well as the organization. Mainly we had to understand about infrastructure of client network & based on it we started the Penetration Testing. Client commissioned Varutra to carry out an external penetration testing and supplied Varutra with the external IP address ranges to be tested. No other information given such as live IP addresses, name, type, nature of systems along with the underlined services running on them.

APPROACH AND METHODOLOGY

Varutra consultants then proceeded with the following stages of the penetration test:

Information gathering (Active & Passive)

– Attacking on DNS

– Discovering Firewall & IPS

– Scanning for External IP’s and associated systems, services.

Attacking WordPress application

Attacking Joomla application

Attacking Web Servers

– Attacking Web Applications

– User Account Bruteforcing

Attacking Network Layer

– Attacking Web Servers

– Attacking Email Server

– Firewall Evasion

Producing a detailed report of issues and recommendations with proof of concepts screenshots

Varutra has followed scenario based assessment approach for the Penetration Testing Phases.

During an External Penetration Test, Varutra can take the perspective of a known or unknown external threat to the organization. Varutra has started footprinting of the organization using Open Source Intelligence (OSINT), Domain Name System (DNS) reconnaissance, NSLookup and other techniques to identify all information that belongs to the client’s network & infrastructure. Varutra started identifying and discovering ports with respect to its services on each workstation and identified vulnerabilities associated with them.

During the attack phase, Varutra attempts to find all possible ways which can breach client’s network using the combinations of tools and techniques employed by hackers in real world attacks. Mainly targets includes web applications/web servers, email system, firewalls and personal information through techniques of Social Engineering attacks.

 External Penetration Testing Methodology

Figure: External Penetration Testing Methodology

 

KEY FINDINGS/OBSERVATIONS

Varutra identified and analysed network perimeter based on the scanning techniques and responses getting from the target. Identified firewall IP which was giving wrong information regarding ports i.e. firewall was misconfigured showing closed ports as well. While doing web server assessment we came across web-server running with outdated version of Apache which leads us conducting Denial of Service attack on the web-server. The attack was successfully achieved. On the web application layer Varutra found multiple critical vulnerabilities such as SQL Injection, XSS, HTML Injection, and Improper Session Management as well as some low and informational level vulnerabilities. This all assessment done with the automated testing using commercial and open source tools as well as extensive manual testing for verification and validation. This was the most important phase of a penetration test because it effectively demonstrates the impact of breach for the concern organization. Main targets in this phase were security credentials and other personal information, web-server/website credentials and sensitive proprietary information of organization (such as source code, or internal methodologies and formulas).

In the final deliverable, Varutra has provided in detailed information for each and every vulnerability which was discovered and exploited, including suggested recommendation or mitigation steps. Finally, Varutra has provided a detailed step-by-step impact of the breach to target organization which explains how several low severe vulnerabilities also can be linked together to achieve a complete and successful compromise.

 

KEY HIGHLIGHTS

Varutra consultants completed Penetration Testing process with scenario based. Main key highlights of the testing are listed below:

1. Initial scoping of the network was conducted to map and identify the current network, sensitive assets, entry points, existing security mechanisms etc.

2. Conducted penetration testing on the target network devices and systems.

3. Exploit tests carried out, such as mail spoofing and DNS zone transfer.

4. Consultants leveraged on the known vulnerabilities to further penetrate the network and identify the impact of the vulnerabilities if getting exploited.

5. Technical, in depth list of issues listed and recommendations on reducing the risk starting with the most critical.

 

DELIVERABLES

The reports and remediation information provided by Varutra were customized to match the Client’s operational environment and requirement. The following reports were submitted to the client:

1. Executive Report: Overview of the entire engagement, the vulnerabilities statistics and the roadmap for the recommendations made to mitigate the threats identified.

2. Technical Report: Comprehensive information, proof of concept examples and detailed exploitation instructions of all the threats/vulnerabilities identified and remediation for the same.

3. Mitigation Tracker: Simple and comprehensive vulnerability tracker aimed at helping the IT asset owner/administrator to keep track of the vulnerabilities, remediation status, action items, etc.

 

BENEFITS

Our Penetration Test helped the client to identify the potential threats / vulnerability that could have compromised their network and its components. We also assisted them in assessing percentage of potential business and operational impacts of successful attacks/exploitation.

Additionally, the client gained the following benefits:

* Risk Benefits: Varutra minimized security risks by assessing and analysing the client’s infrastructure vulnerabilities and recommended solutions and remediation with proven methods to enhance security of organization.

* Cost Savings: Varutra suggested cost-effective risk-mitigation measures based on the client’s business requirements that would ensure security and continuity of the business.

* Customer Satisfaction: Penetration testing was conducted with minimum interruption and damage across client systems/workstations to identify security vulnerabilities, their impacts and potential risks.

* Compliance: As an added bonus, the client was able to utilize the information gained from this Penetration Test to easily gain industry certifications and provide a higher level of service to its customers.

 

REFERENCES

https://www.dionach.com/library/network-penetration-test-case-study

http://www.testlab.com.au/images/pentest.png

 

AUTHOR:

Omkar Joshi & Chetan Gulhane

Security Consultant, Varutra Consulting Pvt. Ltd.

10/4/14

Shellshock-Security Patching Aftermath

Shell Shock-

On September 24th 2014, a publicly disclosed vulnerability was revealed in the UNIX/Linux which we have discussed in our blog http://varutra.com/blog/?p=1010. Although a patch has been released for this vunerability by vendors such as ubuntu,redhat and centos etc. but the patch was not successful, Additional vulnerability in the same area were discovered which left Bash again more vulnerable to severe attack such as arbitrary remote code execution. The set of vulnerability collectively known as shell shock are serious issue in many organizations. The CVE number that are part of this are CVE 2014-6271, CVE 2014-7169,  CVE 2014-7186, CVE 2014-7187, CVE 2014-6277 and CVE 2014-6278.

In response to shellshock, Richard Stallman (software freedom activist and computer programmer) said the bug was just a “blip”. It’s not, it’s a “blimp” — a huge nasty spot on the radar warning of big things to come. Three more related bugs have been found, and there are likely more to be found later. The cause isn’t that a programmer made a mistake, but that there is a systematic failure in the code — it’s obsolete, having been written to the standards of 1984 rather than 2014.

Detailed Explanation

The Shellshock problem is an example of an arbitrary code execution (ACE) vulnerability. Typically, ACE vulnerability attacks are executed on programs that are running, and require a highly sophisticated understanding of the internals of code execution, memory layout, and assembly language—in short, this type of attack requires an expert. Attacker will also use an ACE vulnerability to upload or run a program that gives them a simple way of controlling the targeted machine. This is often achieved by running a “shell”. A shell is a command-line where commands can be entered and executed. The Shellshock vulnerability is a major problem because it removes the need for specialized knowledge, and provides a simple (unfortunately, very simple) way of taking control of another computer (such as a web server) and making it run code. Suppose for a moment that you wanted to attack a web server and make its CD or DVD drive slide open. There’s actually a command on Linux that will do that: /bin/eject. If a web server is vulnerable to Shellshock you could attack it by adding the magic string () { :; }; to /bin/eject and then sending that string to the target computer over HTTP. Normally, the User-Agent string would identify the type of browser you are using, but, in in the case of the Shellshock vulnerability, it can be set to say anything.

Example: curl -H “User-Agent: () { :; }; /bin/eject” http://example.com/

would be enough to actually make the CD or DVD drive eject.

How does this Attack works?

When a web server receives a request for a page there are three parts of the request that can be susceptible to the Shellshock attack: the request URL, the headers that are sent along with the URL, and what are known as “arguments” (when you enter your name and address on a web site it will typically be sent as arguments in the request).

For example, here’s an actual HTTP request that retrieves the XYZ homepage:

cmd4

 

In this case the URL is / (the main page) and the headers are Accept-Encoding, Accept-Language, etc. These headers provide the web server with information about the capabilities of my web browser, my preferred language, the web site I’m looking for, and what browser I am using.

It’s not uncommon for these to be turned into variables inside a web server so that the web server can examine them. (The web server might want to know what my preferred language is so it can decide how to respond to me).

For example, inside the web server responding to the request for the XYZ home page it’s possible that the following variables are defined by copying the request headers character by character.

cmd 1

As long as those variables remain inside the web server software, and aren’t passed to other programs running on the web server, the server is not vulnerable.

Shellshock occurs when the variables are passed into the shell called “bash”. Bash is a common shell used on Linux systems. Web servers quite often need to run other programs to respond to a request, and it’s common that these variables are passed into bash or another shell.

The Shellshock problem specifically occurs when an attacker modifies the origin HTTP request to contain the magic () { :; }; string discussed above. Suppose the attacker change the User-Agent header above from

cmd2

to simply () { :; }; /bin/eject. This creates the following variable inside a web server:

cmd 3

If that variable gets passed into bash by the web server, the Shellshock problem occurs. This is because bash has special rules for handling a variable starting with () { :; };. Rather than treating the variable HTTP_USER_AGENT as a sequence of characters with no special meaning, bash will interpret it as a command that needs to be executed.

The problem is that HTTP_USER_AGENT came from the User-Agent header which is something an attacker controls because it comes into the web server in an HTTP request. And that’s a recipe for disaster because an attacker can make a vulnerable server run any command it wants (see examples below).

The solution is to upgrade bash to a version that doesn’t interpret () { :; }; in a special way.

Some attacks using shellshock

The Shellshock attack takes advantage of a flaw in Bash that enables attackers to execute remote commands that would ordinarily be blocked.

Allows an attacker to execute command via user agent, referrer, and other HTTP headers. shell shock

Figure : Working of Shellshock

The Shellshock problem is an example of an arbitrary code execution (ACE) vulnerability. A shell is a command-line where commands can be entered and executed.

  • Somebody could use your server as an attack bot:
    () { :; }; ping -s 1000000 <victim IP>
  • If victim.com was vulnerable then
    curl -H “User-Agent: () { :; }; /bin/eject” http://victim.com/
    Would be enough to actually make the CD or DVD drive eject.
  • To extract private information, attackers are using a couple of techniques. The simplest extraction attacks are in the form:
    () {:;}; /bin/cat /etc/passwd
  • DoS attack using Shellshock
    () { :;}; /bin/sleep 20| /sbin/sleep 20|/usr/bin/sleep 20

Proof of Concept for incomplete fix to shellshock

The bash fix for CVE-2014-6271 was incomplete and command injection is possible even after the patch has been applied. The issue is being tracked as CVE-2014-7169 and exists due to incorrect function parsing.

To test, execute this command from within a bash shell:

foo='() { echo not patched; }’ bash -c foo If you see “not patched“, you probably want upgrade immediately. If you see “bash: foo: command not found”, you’re OK.

Shell Shock --

 Figure: Unpatched Bash

The two attacks CVE-2014-6277(Permits remote code execution and requires a high level   of expertise. It has a CVSS score of 10.0) & CVE-2014-6278 (More severe as it allows remote code execution and doesn’t require a high level of expertise. It has a CVSS score of 10.0) are more severe and permit remote code execution:

These two vulnerabilities have been resolved in upstream patches Ubuntu/RHEL/Debian.

Deadening Shellshock

We strongly recommend applying the patches that were released on September 27th in order to remediate these new vulnerabilities by the following command:

APT-GET: Ubuntu / Debian

Update Bash to the latest version available via

apt-get: sudo apt-get update && sudo apt-get install –only-upgrade bash

YUM: CentOS / Red Hat / Fedora

Update Bash to the latest version available via the yum:

sudo yum update bash

For detailed explanation to mitigate the shellshock go through the links:

https://access.redhat.com/articles/1212303

http://www.bankinfosecurity.com/how-to-mitigate-shellshock-risks-a-7363/op-1

https://f5.com/solutions/mitigation/mitigating-the-bash-shellshock-cve-2014-6271-and-cve-2014-7169-vulnerabilities

http://www.akamai.com/html/security/shellshock-bash-cve-list.html

References:

https://www.cloudflare.com

http://seclists.org/oss-sec/2014/q3/650

https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the-shellshock-bash-vulnerability

https://www.qualys.com

Author(s): Lokesh Bawariya Security Consultant & Sachin Wagh Security Consultant, Varutra Consulting