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/7/18

Security Advisory- MEGA Chrome Extension Hijack

What is MEGA?

MEGA is a cloud storage and file hosting service offered by Mega Limited, a New Zealand-based company. The service is offered primarily through web-based apps. Mega mobile apps are also available for Windows Phone, Android and iOS.

Mega is known for its security feature where all files are end-to-end encrypted locally before they are uploaded. This prevents anyone from accessing the files without knowledge of the pass key used for encryption. As of January 20, 2018, Mega has 100 million registered users in more than 245 countries and territories, and more than 40 billion files have been uploaded to the service.

Affected Version

MEGA Chrome Extension 3.39.4

The Firefox version of MEGA has not been impacted or tampered with, and users accessing MEGA through its official website (https://mega.nz) without the Chrome extension are also not affected by the breach.

All extracted information will be immediately reported to a hacker-controlled server located in Ukraine. A list of the target services includes the following:

  • Google
  • Amazon
  • Microsoft
  • GitHub
  • com
  • Google Webstore Login
  • My Ether Wallet
  • My Monero
  • IDEX Market

Fig: MEGA extension window in browser

Current Scenario

On 4 September at 14:30 UTC, an unknown attacker managed to hack into MEGA’s Google Chrome web store account and uploaded a malicious version 3.39.4 to the web store. When installed the extension will monitor for specific login form submissions to Amazon, Microsoft, GitHub, and Google.

The hijacked MEGA extension then sent all the stolen information back to an attacker’s server located in Ukraine, which is then used by the attackers to log in to the victims accounts, and also extract the crypto currency private keys to steal user digital currencies.

Although the company has not revealed the number of users affected by the security incident, it is believed that the malicious version of the MEGA Chrome extension may have been installed by tens of millions of users.

Fig: Blog post published by the company

How this attack works?

It would perform monitoring of any form submission where the URL contains the strings Register or Login or variables exist that are named “username”, “email”, “user”, “login”, “usr”, “pass”, “passwd”, or “password”. If the extension detected any of these form submissions or data variables, it would send the credentials and variables values to a host in Ukraine called https://www.megaopac.host/.

To make matters worse this extension will also monitor for the following URL patterns: “https://www.myetherwallet.com/*”, “https://mymonero.com/*”, “https://idex.market/*”, and if detected, would execute Javascript that would attempt to steal the crypto currency private keys for the logged in user from these sites.

Fig: Monitoring login attempts to various sites

Fig: Stealing variables with certain names

Fig: Sending information to attackers

Fig: Capturing crypto currency keys

Prevention attempts by officials

The main reason for this attack was Google’s decision to disallow publisher signatures on Chrome extensions and relying solely on signing them automatically after upload to the Chrome web store, which removes an important barrier to external compromise. As a prevention attempt Google removed the MEGA extension from its Chrome Web Store five hours after the breach.

However, after four hours of the security breach MEGA updated the extension with a clean MEGA version (3.39.5), auto-updating all the affected installations.

Recommendations

  1. Users who had installed the extension should uninstall the MEGA version 3.39.4.
  2. Change your passwords at any accounts, especially financial, shopping, banking, and government institutions, that you may have used.
  3. Consider resetting the Chrome browser to make sure the extension is completely removed. (Settings->Show advanced settings->Restore settings to their original defaults)
  4. Until more information is available about the cause of the incident, it is recommended that all users should stop the use of the MEGA Chrome extension.
  5. Transfer any cryptocurrency funds, including tokens, to another address.

Some best practices to stay safe in future

  1. The incident highlights a security danger with third-party Chrome extensions. If you have any unused extension installed on your Chrome browser, it’s a good idea to remove them.
  2. Do not install potentially unwanted extensions on browser.
  3. Before granting permission, verify the reason why an application requires elevated permissions like ‘Read and Change your data on websites you visit’.
  4. Use two-factor authentication for any resources that support financial information, because in such cases, even if criminals get to your credentials, they won’t be able to compromise your accounts.
  5. Password managers are particularly helpful when need to change a whole lot of passwords at the same time.

References

  1. https://mega.nz/start
  2. https://www.neowin.net/news/megas-chrome-extension-suffers-breach-steals-user-credentials-and-crypto-keys
  3. https://sensorstechforum.com/mega-chrome-extension-hacked-user-passwords-stolen-uninstall-asap/

 

Author,
Jinto T.K.

SOC Team

Varutra Consulting Pvt. Ltd.

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

07/8/17

Threat Advisory Report on Petya Ransomware (Critical Severity)

  • Ransomware: An Introduction

Ransomware is a form of malicious software that locks up users files on the computer system, encrypts them, and demands that the user should pay a specified amount to get the files back.

A ransomware that affects Microsoft’s Windows operating system, when a system is infected, a pop up window appears, prompting the user of the system to pay to recover the files within specified time, with a countdown timer. It adds that if the user fails to pay within that time, the fee will be doubled, and if the user doesn’t pay within that period, the user will lose the files forever.

Payment is accepted only in Bitcoins. Experts say that Ransomware is spread by an internet worm- software that spreads copies of itself by hacking into other computers on a network, rather than the usual case of prompting unsuspecting users to open attachments. It is also believed that, the cyber-attack was carried out with the help of tools which were stolen from the National Security Agency (NSA) of the United States.

  • Petya Ransomware: An Introduction

A new variant of Ransomware known by the name Petya is Spreading like Wildfire.

On June 27, 2017, the world woke up to another ransomware outbreak named as “Petya” also known as “PetWrap” which also uses the same Windows SMBv1 vulnerability that the WannaCry ransomware abused to infect more than 300,000 systems and servers worldwide in just 72 hours in earlier this March.

It uses EternalBlue, CVE-2017-0143 (patched by Microsoft in March) and leverage an additional Shadow Brokers- leaked NSA exploits known as EternalRomance CVE-2017-0145 (patched by Microsoft in March) for remote access as an attack vector and spreading via SMB post-exploitation and uses either PSEXEC or WMIC tools to spread.

Some researchers have also found that, the Ransomware may take advantage of yet another tool published by the ShadowBrokers, known as EsteemAudit, which specifically targets computers running Windows XP and Windows Server 2003.

Note: Microsoft patched those vulnerability as a part of its unprecedented effort to secure its old, unsupported operating systems against leaked NSA exploits.

After further analysis about how Petya infects the MBR (Master Boot Record), Security Researchers found that Petya contains a programming error which destroys some of the MBR, leading to speculation it is a Wiper and intended to destroy data rather than make money by holding it to a ransom, which just trashes the first 24 sector blocks of the disk while replicating itself.

The way the code is set out (i.e. not setting bFinalBlock to True if the file is larger than 1 MB) suggests that, the developer was trying to encrypt files of size 1 MB at a time to avoid using too much RAM, but never got around to writing the code responsible for handling the rest of the file should it exceed 1 MB.

  • What is a Wiper?

When you erase/delete a file from the computer system, they are not really gone until the areas of the disk it used are overwritten by new information. If the normal Windows delete function is used, the “deleted” file is sent to the Recycle Bin until the space it uses is required by other files.

If Shift+Delete is used to bypass the Recycle Bin, the space occupied by the file is marked as available for other files. However, the file could be recovered days or even weeks later with third-party data recovery software; as long as the operating system does not reuse the space occupied by a file with another file, the “deleted” file can be recovered. While erasing files simply marks file space as available for reuse, data wiping overwrites all data space on a storage device, replacing useful data with garbage data.

So, a Wiper function simply overwrites the deleted files from hard disk with some garbage value and that’s where Wiper function is used.

After further analysis, it is also discovered that the attackers implemented a function that wipes the first 10 sectors of PhysicalDrive0 including the MBR under two conditions:

  1. If the hash command computed from a running process name (“exe”) returns 0x2E214B44
  2. If the function that replaces the actual MBR returns an error. Probably as a generic way to detect EDR trying to prevent boot loader modifications.
  • Is Petya a Ransomware or a Wiper?

The Petya cyber-attack that swept globally, and has infected enterprise networks across Europe is much worse than initially thought. Security researchers have now concluded that, the Petya attack is not a ransomware.

Petya is being termed as a wiper by researchers, with the aim of being mass destruction of user’s data. The idea was never to collect money from victims or enterprises. But it is now used to get ransom from the victims that is why it is called as Ransomware.

Petya has been around since March 2016 and differs from usual ransomware families because it does not encrypt files on a targeted system one by one. Instead, Petya reboots victim’s computers and encrypts the hard drive’s Master File Table (MFT) and renders the Master Boot Record (MBR) inoperable, restricting access to the full system by seizing information about file names, sizes, and location on the physical disk.

Petya replaces the computer’s MBR with its own malicious code that displays the ransom note and leaves computers unable to boot. 2016’s version of Petya was able to modify the disk in a way where it can actually revert its changes, whereas 2017’s version of Petya does permanent and irreversible damage to the disks.

To summarize, it encrypts a system’s MBR in addition to encrypting files. This double stroke renders the disk inaccessible and prevents most users from recovering anything on it.

  • Attack Scenario

The Petya Ransomware infection vector is believed to be the software updater process (EzVit.exe) of a Ukrainian program called MeDoc developed by Ukrainian Company M.E.Doc, and possibly through Microsoft Word documents laced with malicious macros. It combines both a client-side attack (CVE-2017-0199) and a network based threat (MS17-010) to become nastier.

The Current Petya attack is different in the sense that the exploits it uses are only used to spread across a local network rather than the internet. The important difference between WannaCry and Petya is, WannaCry was likely deployed onto a small number of computers and then spread rapidly, whereas Petya seem to have been deployed onto many computers and spreads via local network.

Additionally, using EternalBlue exploit, Petya can also propagate over the network using “WMIC” (Windows Management Instrumentation Command line) by trying credentials gathered from the local machine using “Mimikatz” this allows it to infect network systems which are patched against EternalBlue or not running SMB.

Again, it’s important to note that spreading appears to be limited to only devices on the local network.

Once Petya gets foothold it has two distinct stages. As per the updated information, following is the breakdown for Petya’s two stages:

  • During the first stage:
  1. The Windows executable file is dropped and executed.
  • Downloads the main binary at hxxp://185.165.29.78/alex/svchost.exe
  1. This overwrites the beginning of the disk, including the Master Boot Record, and makes an encrypted (XOR) backup of all original data.
  2. It then clears the windows event log using windows utility Wevtutil
  • (wevtutil cl Setup & wevtutil cl System & wevtutil cl Security & wevtutil cl Application & fsutil usn deletejournal /D %c:)

4. It then writes a message to the raw disk partition.

5. At the end, reboot the system at noon as a logic bomb

  • (schtasks %ws/Create /SC once /TN “” /TR “%ws” /ST %02d:%02d ; at %02d:%02d %ws) or time specified in parameter defined in DLL component “Rundll32 c:\windows\<dll name>.dll,#1 40”,
    • By default, when the malware infects a remote system, it runs the remote DLL with the value “40,” which makes it wait 40 minutes before rebooting the machine.

Note: Stage one ends when the infected device is rebooted.

  • During the second stage:
  1. The second stage initiates after the device reboots, and results in the entire drive being encrypted.
  • After restarting, a message appears announcing system encryption and asking a Bitcoin $USD300 as a ransom for decrypting the files.

Given this new ransomware’s added lateral movement capabilities, it only takes a single infected machine to affect the entire network. This Ransomware drops a credential dumping tool (typically as a .tmp file in the %Temp% folder) that shares code similarities with “Mimikatz” and comes in 32-bit and 64-bit variants.

Since users frequently log in using accounts with local admin privileges and have active sessions opens across multiple machines, stolen credentials are likely to provide the same level of access the user has on other machines. Once the Ransomware has valid credentials, it scans the local network to establish valid connections on TCP ports 139 & 445.

A special behavior is reserved for Domain Controllers or servers, Petya attempts to call DhcpEnumSubnets() to enumerate DHCP subnets for each subnet, it gathers all hosts/clients (using DhcpEnumSubnetClients()) for scanning for TCP 139 & 445 services. If it gets a response, the malware attempts to copy a binary on the remote machine using regular file-transfer functionalities with the stolen credentials.

It then tries to execute remotely the malware using either PSEXEC or WMIC tools.

It further attempts to drop the legitimate psexec.exe (typically renamed to dllhost.dat) from an embedded resource within the malware. It then scans the local network for admin$ shares, copies itself across the network, and executes the newly copied malware binary remotely using PSEXEC.

In addition to credential dumping, the malware also tries to steal credentials by using the CredEnumerateW function to get all the other user credentials potentially stored on the credential store. If a credential name starts with “TERMSRV/” and the type is set as 1 (generic) it uses that credentials to propagate through the network.

The encryption used by the malware is AES-128 with RSA. This is different from previous variants, which used SALSA20.  This ransomware’s encryption behavior depends on the malware process privilege level and the processes found to be running on the machine. It does this by employing a simple XOR-based hashing algorithm on the process names, and checks against the following hash values to use as a behavior exclusion:

  • 0x6403527E or 0x651B3005 – if these hashes of process names are found running on the machine, then the ransomware does not do SMB exploitation.
  • 0x2E214B44 – if a process with this hashed name is found, the ransomware trashes the first 10 sectors of \\\\.\\PhysicalDrive0, including the MBR

The RSA public key used to encrypt the file encryption keys is hardcoded and can be seen below:

 

 

 

 

The ransomware attempts to encrypt files that correspond to the following file extensions:

.3ds .7z .accdb .ai .asp .aspx .avhd .back .bak .c .cfg .conf .cpp .cs .ctl.dbf .disk .djvu .doc .docx .dwg .eml .fdb .gz .h .hdd .kdbx .mail .mdb .msg .nrg .ora .ost .ova .ovf .pdf .php .pmf .ppt .pptx .pst .pvi .py .pyc .rar .rtf .sln .sql .tar .vbox .vbs .vcb .vdi .vfd .vmc .vmdk .vmsd .vmx .vsdx .vsv .work .xls .xlsx .xvd .zip

Following Hashes are generated by Petya which can help detecting it;

  • 027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745 (main 32-bit DLL)
  • 64b0b58a2c030c77fdb2b537b2fcc4af432bc55ffb36599a31d418c7c69e94b1 (main 32-bit DLL)
  • f8dbabdfa03068130c277ce49c60e35c029ff29d9e3c74c362521f3fb02670d5 (signed PSEXEC.EXE)
  • 02ef73bd2458627ed7b397ec26ee2de2e92c71a0e7588f78734761d8edbdcd9f (64-bit EXE)
  • eae9771e2eeb7ea3c6059485da39e77b8c0c369232f01334954fbac1c186c998 (32-bit EXE)

Petya uses following files for infecting the systems;

  • c:\windows\dllhost.dat
  • c:\windows\<malware_dll> (no extension)
  • %TEMP%\<random name>.tmp (EXE drop)

In environments where command-line logging is available, the following command lines may be searched:

  • Scheduled Reboot Task: Petya schedules a reboot for a random time between 10 and 60 minutes from the current time
  • schtasks /Create /SC once /TN “” /TR “<system folder>\shutdown.exe /r /f” /ST <time>
  • cmd.exe /c schtasks /RU “SYSTEM” /Create /SC once /TN “” /TR “C:\Windows\system32\shutdown.exe /r /f” /ST <time>

This may be surfaced by searching for EventId 106 (General Task Registration) which captures tasks registered with the Task Scheduler service.

Lateral Movement (Remote WMI)

  • “process call create \”C:\\Windows\\System32\\rundll32.exe \\\”C:\\Windows\\perfc.dat\\\” #1”

Network indicators in environments where NetFlow data are available, this ransomware’s subnet-scanning behavior may be observed by looking for the following:

  • Workstations scanning ports tcp/139 and tcp/445 on their own local (/24) network scope
  • Servers (in particular, domain controllers) scanning ports tcp/139 and tcp/445 across multiple /24 scopes

Following Domains are believed to be infected with Petya:

  • hxxp://petya3jxfp2f7g3i.onion/
  • hxxp://petya3sen7dyko2n.onion/
  • hxxp://mischa5xyix2mrhd.onion/MZ2MMJ
  • hxxp://mischapuk6hyrn72.onion/MZ2MMJ
  • hxxp://petya3jxfp2f7g3i.onion/MZ2MMJ
  • hxxp://petya3sen7dyko2n.onion/MZ2MMJ
  • hxxp://mischapuk6hyrn72.onion/
  • hxxp://benkow.cc/71b6a493388e7d0b40c83ce903bc6b04.bin COFFEINOFFICE.XYZ
  • hxxp://french-cooking.com/

Countries that reported Petya infections include, but are not limited to, Russia, Ukraine, Spain, France, United Kingdom, the United States and India. The Extortion for Petya infections are set at $300 in bitcoins per infected device.

Reported affected industries include, but are not limited to: financial services; retail, hospitality and travel; and energy and utilities.

Researchers also believed that the attacker took an existing Ransomware which he repackaged and resulted in chaos.

  • Attack PoC

 

 

 

 

 

 

 

 

 

 

 

  • Advisory Notes

The EternalBlue SMB vulnerability was originally published by the Shadow Brokers who allegedly acquired NSA hacking tools. The vulnerability was published in April 2017 but patched prior to release by Microsoft in March 2017. The exploit is particularly dangerous because Petya Ransomware uses remote code execution vulnerability that does not require any user interaction.

Since the ransomware propagates primarily through the exploitation of the EternalBlue SMB vulnerability, multiple infections in the same organization are to be expected. This is because the exploit leverages a previously-patched Windows vulnerability and uses either PSEXEC or WMIC tools along with other lateral spreading techniques like stealing admin credentials to spread across a local network rather than the internet as mentioned earlier.

Researchers have also suggested not to pay any ransom as the email address “wowsmth123456[at]posteo[dot]net” which the Petya Ransomware asks you to contact upon payment has been blocked by the email provider, “Posteo” so making payment confirmation is pretty much impossible.

Early analysis indicates that for the current variant of Petya, administrators can stop the spread within a network from the Windows Management Instrumentation by blocking the file “C:\Windows\perfc.dat” from running.

Administrators can also shore up their defenses by using Microsoft’s Local Administrator Password Solution to protect credentials that grant network privileges. Researchers also found that the Petya runs on boot, meaning that if system is disrupted before Windows boots, or by quickly powering down once screen displays a fake “Check Disk” message, files encryption can be avoided.

If MS17-010 is not patched, the malware will spread via Microsoft Server Message Block. If MS17-010 is patched and the malware has admin rights, it will spread laterally via either PSEXEC or WMIC as mentioned in earlier sections.

Note: The actor(s) behind this activity is currently unknown and no major group has taken credit for the activity.

  • Mitigation Techniques

To safeguard the organization from Petya outbreak, Varutra Consulting recommends the following:

  • Prevent reboot after blue screen, thereby preventing stage 2 encryption.
  • Microsoft patches- MS17-010, SMB Server patches need to be applied over the network.
  • Disable SMB v1 and block all versions of SMB by blocking TCP port 445 with related protocols on UDP ports 137-138 and TCP port 139 at network perimeter.
  • Ensure Microsoft Knowledge Base KB4015546 & KB4015549 has been applied to all the systems as Petya leverages CVE-2017-0199.
  • As the Email used for the Petya Ransomware is “wowsmth123456[at]posteo[dot]net” detect/blacklist all incoming emails from wowsmth123456[at]posteo[dot]net at network boundary.
  • Below mentioned are the possibly infected IP’s which need to be blocked on firewall immediately “95.141.115[dot]108”, “185.165.29[dot]78”, “84.200.16[dot]242”, and “111.90.139[dot]247”
  • Do not pay any ransom associated with this activity. The actors may not even provide a decryption key, and furthermore doing so incentivizes and finances further criminal activity.
  • Enable strong Spam filters to prevent phishing e-mails from reaching the end users and authenticate in-bound e-mail using technologies like Sender Policy Framework (SPF), Domain Message Authentication Reporting and Conformance (DMARC) and Domain Keys Identified Mail (DKIM) to prevent e-mail spoofing.
  • Disable macro scripts from Microsoft Office files transmitted via e-mail.
  • Implement Endpoint Controls to Protect the Windows AppData Folder.
  • Prevent privileged execution of windows binaries from temp directories.
  • User education should involve frequently advising users of how attackers are trying to gain a foothold in the environment.
  • Advising users not to open Email attachments unless they are expecting it. Only open Email attachments received from trusted source.
  • If a document from an email is opened in Protected Mode, a user should not enable editing of the document unless they expected the document and know who sent it.

Read about WannaCry Ransomware Threat Advisory blog post here

  • References:
  1. https://securingtomorrow.mcafee.com/mcafee-labs/new-variant-petya-ransomware-spreading-like-wildfire/
  2. http://seckurity.com/2017/06/everything-technical-about-the-new-ransomware-petya/
  3. https://www.optiv.com/blog/intelligence-advisory-new-petya-ransomware-outbreak
  4. https://www.malwaretech.com/2017/06/petya-ransomware-attack-whats-known.html
  5. https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/
  6. https://www.wired.com/story/petya-ransomware-wannacry-mistakes/
  7. https://securelist.com/expetrpetyanotpetya-is-a-wiper-not-ransomware/78902/

Authors:

Lekhraj Rawat and Umang Waghmare

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

05/16/17

Threat Advisory Report on WannaCry Ransomware (Critical Severity)

1. Introduction

On Friday, May 12, countless organizations around the world began fending off attacks from a ransomware strain variously known as WannaCrypt, WanaDecrypt and Wanna.Cry.

Security researchers found “WannaCry” or “WannaDecryptor”; a type of ransomware which spreads from system to system silently and remains invisible to users until it unveils itself and then warns users that all their files have been encrypted with a key known only to the attacker and that they will be locked out until they pay to an anonymous party using the cryptocurrency Bitcoin.

Ransomware encrypts a victim’s documents, images, music and other files unless the victim pays for a key to unlock them.

Wana Decrypt0r triggered security alerts for ETERNALBLUE, an alleged NSA exploit. ETERNALBLUE works by exploiting a vulnerability in the SMBv1 protocol to get a foothold on vulnerable machines connected online. Microsoft patched the flaw in MS17-010, released in March, but there are high chances that all Windows PC owners have applied the security update.

On Friday, at least 16 hospitals in the United Kingdom were forced to divert emergency patients after computer systems there were infected with Wanna. According to multiple stories in the British media, approximately 90 percent of care facilities in the U.K.’s National Health Service are still using Windows XP – a 16-year-old operating system.

2. Attack Scenario

The initial infection vector of WannaCrypt 2.0 is not confirmed. It is possible that the initial vector is spam with malicious attachments (.pdf, .hta, and macro embedded MS Office files) commonly used in other ransomware campaigns.

Once WannaCry 2.0 achieves a foothold, the ransomware infects other machines by leveraging a remote command execution vulnerability of Server Message Block (SMB). It is confirmed to exploit at least one publicly disclosed SMB vulnerability – CVE 2017-0143 also referred to as “EternalBlue” – which was released by a group called ShadowBrokers in April 2017. Using arbitrary code execution privileges, the ransomware installs itself to the machine, then proceeds to encrypt a wide array of files.

Files are encrypted with the .WNCRY file extension added to them. The ransomware also downloads and installs TOR, with all dependencies, onto the infected machine, and uses this service to reach out to one of at least six .onion domains. The ransomware drops a ransom note named @Please_Read_Me@.txt; it also adds a lock screen, named “WanaCrypt0r 2.0”

At the time of reporting, the malware was requesting $300 USD in BitCoins, though this amount was later increased to $600. The Bitcoin wallets associated with the activity had received approximately 500 ransom payments, estimated to be worth over $150,000.

Additionally, reports indicate the ransomware may have increased its payment demands from $300 to $600, indicating the actors have some level of control over the demanded amount and are increasing the cost of decryption, likely due to the success of the malware.

The ransomware uses a unique encryption key for each binary placed onto a computer, but since the ransomware uses asymmetric RSA encryption even having the encryption key will not allow for convenient decryption.

Upon infection, the following files are created:

%Temp%\b.wnry

%Temp%\c.wnry

%Temp%\m.wnry

%Temp%\r.wnry

%Temp%\t.wnry

%Temp%\u.wnry

%Temp%\m.vbs

%Temp%\taskdl.exe

C:\ProgramData\taskse.exe

%Temp%\[14 random digits].bat

The file c.wry contains information needed by the malware to further the infection and communication with its Command and control server.

wanna18@hotmail[.]com

13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

sqjolphimrr7jqw6[.]onion

https://www.dropbox[.]com/s/deh8s52zazlyy94/t.zip?dl=1

win32-0.2.8.11.zip

https://dist.torproject[.]org/torbrowser/6.5.1/tor-win32-0.2.9.10.zip

https://www.dropbox[.]com/s/c1gn29iy8erh1ks/m.rar?dl=1

Adding the following registry entry for persistence:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v “” /t REG_SZ /d

“\”C:\Users\\AppData\Local\Temp\tasksche.exe\”” /f

It also drops the ransom file named @Please_Read_Me@.txt and the decryptor file named @WanaDecryptor@.exe, as shown below:

WannaCrypt0r 2.0 uses TOR hidden services for command and control, dropping and installing a fully functional version of TOR with all necessary components onto an infected machine. The TOR service reaches out to one of a number of .onion domains, including:

  • gx7ekbenv2riucmf[.]onion
  • 57g7spgrzlojinas[.]onion
  • Xxlvbrloxvriy2c5[.]onion
  • 76jdd2ir2embyv47[.]onion
  • cwwnhwhlz52maqm7[.]onion
  • sqjolphimrr7jqw6[.]onion

The following file extensions have been observed affected by this malware:

.der .slk .odb .jsp .3g2 .zip .edb .docm.pfx .wb2 .frm .php .flv .rar .potm .docb.key .odp .myd .asp .wma .tgz .potx .jpg.crt .otp .myi .java .mid .tar .ppam .jpeg.csr .sxd .ibd .jar .m3u .bak .ppsx .snt.p12 .std .mdf .class .m4u .tbk .ppsm .onetoc2.pem .uop .ldf .mp3 .djvu .bz2 .pps .dwg.odt .odg .sln .wav .svg .PAQ .pot .pdf.ott .otg .suo .swf .psd .ARC .ppt m .wk1.sxw .sxm .cpp .fla .nef .aes .xltm .wks.stw .mml .pas .wmv .tiff .gpg .xltx .hwp.uot .lay .asm .mpg .tif .vmx .xlc .rtf.3ds .lay6 .cmd .vob .cgm .vmdk .xlm .csv.max .asc .bat .mpeg .raw .vdi .xlt .txt.3dm .sqlite3 .ps1 .asf .gif .sldm .xlw .vsdx.ods .sqlitedb .vbs .avi .png .sldx .xlsb .vsd.ots .sql .dip .mov .bmp .sti .xlsm .eml.sxc .accdb .dch .m p4 .vcd .sxi .dotx .msg.stc .mdb .sch .3gp .iso .pptx .dotm .ost.dif .dbf .brd .mkv .backup .ppt .dot .pst.xlsx .xls .docx .doc

3. Attack PoC

4. Advisory Notes

The EternalBlue SMB vulnerability was originally published by the Shadow Brokers who allegedly acquired NSA hacking tools. The vulnerability was published in April 2017 but patched prior to release by Microsoft in March 2017. The exploit is particularly dangerous because WannaCry 2.0 a ransomware uses remote code execution vulnerability that does not require any user interaction.

Moreover, the malware can spread laterally as quickly as the commands can be processed by infected machines resulting in the highly virulent nature of this threat. Since the ransomware propagates primarily through the exploitation of the EternalBlue SMB vulnerability, multiple infections in the same organization are to be expected. This is because the exploit leverages a previously-patched Windows vulnerability and if an infected device does not have the appropriate patches it is likely other machines are similarly vulnerable.

The inclusion of over twenty language variants for the ransom note supports the conclusion that this malware was not targeted at a particular country or entity, but rather was intended to spread as widely as possible.

The success of this ransomware attack will almost certainly lead to future ransomware attacks attempting to propagate via critical Microsoft Windows vulnerabilities, even months after the vulnerability is publicly released and patched. The actor(s) behind this activity is currently unknown, and no major group has taken credit for the activity.

5. Mitigation Techniques

Varutra Consulting recommends the following:

  • Apply Microsoft patches MS17-010 / MS17-012 disabling SMB v1, and blocking all versions of SMB at the network boundary by blocking TCP port 445 with related protocols on UDP ports 137-138 and TCP port 139 for all boundary devices.
  • Due to recent changes in Microsoft patch naming, ensure Microsoft Knowledge Base 4013389 has been applied to all systems, as it is another name for the MS17-010 SMB vulnerability patch.
  • Do not pay any ransom associated with this activity. The actors may not even provide a decryption key, and furthermore doing so incentivizes and finances further criminal activity.
  • Enable strong spam filters to prevent phishing e-mails from reaching the end users and authenticate in-bound e-mail using technologies like Sender Policy Framework (SPF), Domain Message Authentication Reporting and Conformance (DMARC), and DomainKeys Identified Mail (DKIM) to prevent e-mail spoofing.
  • Prevent privileged execution of windows binaries from temp directories.
  • Disable macro scripts from Microsoft Office files transmitted via e-mail. Consider using Office Viewer software to open Microsoft Office files transmitted via e-mail instead of full Office suite applications.
  • Develop user security awareness training for identifying scams, malicious links, and attempted social engineering.
  • Scan your perimeter and other Internet-facing network structures for the presence of open Windows SMB ports.
  • Ensure that Snort Signatures ET-2024217, ET-2024218, and ET-2024220 are implemented to ensure lateral propagation detection within an enterprise network and not just at the border or perimeter.
  • Below mentioned are the possibly infected IP’s which need to be blocked on firewall immediately.
 

82.94.251.227:443

213.239.216.222:443

51.255.41.65:9001

86.59.21.38:443

198.199.64.217:443

83.169.6.12:9001

192.42.115.102:9004

104.131.84.119:443

178.254.44.135:9001

163.172.25.118:22

197.231.221.221:9001

128.31.0.39:9191

 

 

149.202.160.69:9001

46.101.166.19:9090

91.121.65.179:9001

2.3.69.209:9001

146.0.32.144:9001

50.7.161.218:9001

217.79.179.177:9001

213.61.66.116:9003

212.47.232.237:9001

81.30.158.223:9001

79.172.193.32:443

38.229.72.16:443

Read about Petya Ransomware Threat Advisory blog post here

6. References

https://www.microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=Ransom:Win32/WannaCrypt

https://krebsonsecurity.com/2016/12/before-you-pay-that-ransomware-demand/

http://webcast.gov.in/cert-in/

Customer Guidance for WannaCrypt attacks

01/30/16

How To Develop Secure Software – Action Plan To Make Secure

The purpose of this article is to provide a guideline for secure software development. Easily avoided software defects are a primary cause of commonly exploited software vulnerabilities. By identifying insecure coding practices and developing secure alternatives, software developers can take practical steps to reduce or eliminate vulnerabilities while developing software product.

According to a study released last year by WhiteHat Security, Cross-Site Scripting regains the number one spot after being overtaken by Information Leakage last year in all but one language. .Net has Information Leakage as the number one vulnerability, followed by Cross-Site Scripting. ColdFusion has a rate of 11% SQL Injection vulnerabilities, the highest observed, followed by ASP with 8% and .NET 6%. Perl has an observed rate of 67% Cross-Site Scripting vulnerabilities, over 17% more than any other language. There was less than a 2% difference among the languages with Cross-Site Request Forgery. Many vulnerabilities classes were not affected by language choice.

The most effective way to reduce application security risk is to implement a formal development process that includes security best practices to avoid application vulnerabilities. Secure Development process and Security Testing are powerful tools to monitor and search for application flaws and they should be used together to increase the security level of business critical applications/software.

Secure coding is the practice of writing code for applications in such a way as to ensure the confidentiality, integrity and accessibility of data and information related to those systems. Programmers fluent in secure coding practices can avoid common security flaws in programming languages and follow best practices to avoid the number of targeted attacks that focus on application vulnerabilities.

Application security is a process that begins from the application development lifecycle to ensure the highest security possible of the development process (coding), the system, hardware the application runs on and the network it uses to connect, authenticate and authorize users. Building secure software and incorporating security best practices in development process is the responsibility of all the stakeholders involved with the Software Development Lifecycle (SDLC).

1

Figure: SDLC Stakeholders

INTRODUCTION

The current trend is to identify issues by performing a security assessment of applications after they are developed and then fix these issues. Patching software in this way can help, but it is a costlier approach to address the issues.

This cycle of Testing – Patching – Re-testing runs into multiple iterations and can be avoided to a great extent by addressing issues earlier in the Life Cycle. This next section covers a very important aspect – the need for programs like S-SDLC.

As an old saying goes – “Need is the mother of invention” – this is applicable for Secure software development as well. There were days when organizations were just interested in developing an application and selling it to the client and forgetting about rest of the complexities. Those days are gone.

A very simple answer to the question is – “The threat landscape has changed drastically.” There are people out there whose only intention is to break into computer systems and networks to damage them, whether it is for fun or profit. These could be novice hackers who are looking for a shortcut to fame by doing so and bragging about it on the internet. These could also be a group of organized criminals who work silently on the wire. They don’t make noise but when their job is done, it reflects into a huge loss for the organization in question – not to mention a huge profit for such criminals.

This is where secure development comes into the picture. While employing a team of ethical hackers helps, having processes like secure development can help organizations in addressing the above discussed issues in a much more cost-efficient manner as identifying security issues earlier in the development life cycle reduces the cost.

Want to build secure application and keep your application from getting hacked? Here’s a guideline to build secure application and how to get serious about secure apps.

Let’s get serious about building secure Web applications.

 

THINGS YOU NEED TO DO IN A SECURE SOFTWARE DEVELOPMENT

1. AUTHENTICATION AND AUTHORIZATION:

Don’t hardcode credentials: Never allow credentials to be stored directly within the application code.
Example: Hard coded passwords in networking devices https://www.us-cert.gov/control_systems/pdf/ICSA-12-243-01.pdf

Implement a strong password policy: A password policy should be created and implemented so that passwords meet specific strength criteria. Implement account lockout against brute force attacks: Account lockout needs to be implemented to guard against brute forcing attacks against both the authentication and password reset functionality. After several tries on a specific user account, the account should be locked for a period of time or until manually unlocked.

2. SESSION MANAGEMENT:

Invalidate the session after logout: When the user logs out of the application the session and corresponding data on the server must be destroyed. This ensures that the session cannot be accidentally revived.

Implement an idle session timeout: When a user is not active, the application should automatically log the user out. Be aware that Ajax applications may make recurring calls to the application effectively resetting the timeout counter automatically.

Use secure cookie attributes (i.e. httponly and secure flags): The session cookie should be set with both the HttpOnly and the secure flags. This ensures that the session id will not be accessible to client-side scripts and it will only be transmitted over SSL, respectively.

3. INPUT AND OUTPUT HANDLING/VALIDATION:

Prefer whitelists over blacklists: For each user input field, there should be validation on the input content. Whitelisting input is the preferred approach. Only accept data that meets a certain criteria. For input that needs more flexibility, blacklisting can also be applied where known bad input patterns or characters are blocked.

Use parameterized SQL queries: SQL queries should be crafted with user content passed into a bind variable. Queries written this way are safe against SQL injection attacks. SQL queries should not be created dynamically using string concatenation. Similarly, the SQL query string used in a bound or parameterized query should never be dynamically built from user input.

Use CSRF tokens to prevent forged requests: In order to prevent Cross-Site Request Forgery attacks, you must embed a random value that is not known to third parties into the HTML form. This CSRF protection token must be unique to each request. This prevents a forged CSRF request from being submitted because the attacker does not know the value of the token.

Validate uploaded files: When accepting file uploads from the user make sure to validate the size of the file, the file type, and the file contents as well as ensuring that it is not possible to override the destination path for the file.

Validate the source of input: The source of the input must be validated. For example, if input is expected from a POST request, do not accept the input variable from a GET request.

X-XSS- Protection headers: Content Security Policy (CSP) and X-XSS-Protection headers help defend against many common reflected Cross-Site Scripting (XSS) attacks.

4. ACCESS CONTROL:

Apply the principle of least privilege: Make use of a Mandatory Access Control system. All access decisions will be based on the principle of least privilege.
Don’t use direct object references for access control checks: Do not allow direct references to files or parameters that can be manipulated to grant excessive access. Access control decisions must be based on the authenticated user identity and trusted server side information.

Use only trusted system objects, e.g. server side session objects, for making access authorization decisions. Use a single site-wide component to check access authorization. This includes libraries that call external authorization services.

5. PROPER ERROR HANDLING AND LOGGING:

Error messages should not reveal details about the internal state of the application. For example, file system path and stack information should not be exposed to the user through error messages.

Logs should be stored and maintained appropriately to avoid information loss or tampering by intruder. Log retention should also follow the retention policy set forth by the organization to meet regulatory requirements and provide enough information for forensic and incident response activities.

Do not disclose sensitive information in error responses, including system details, session identifiers or account information.
Logging controls should support both success and failure of specified security events.

6. DATA PROTECTION:

Ideally, SSL should be used for your entire application. If you have to limit where it’s used, then SSL must be applied to any authentication pages as well as all pages after the user is authenticated. If sensitive information (e.g. personal information) can be submitted before authentication, those features must also be sent over SSL.

Implement least privilege; restrict users to only the functionality, data and system information that are required to perform their tasks.

Encrypt highly sensitive stored information, like authentication verification data, even on the server side. Always use well vetted algorithms, see “Cryptographic Practices” for additional guidance.

7. BUSINESS LOGIC:

Business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules. Most security problems are weaknesses in an application that result from a broken or missing security control.

This will help to identify the minimum standard that is required to neutralize vulnerabilities in your critical applications. Phases been addressed? Have you made all the proper configuration settings in the database, web server, etc.?

 

ACTION PLAN TO MAKE SECURE SOFTWARE

These help organizations to think about security early on in the project. They represent specific security goals and constraints that affect the confidentiality, integrity and availability of important application data and the means by which that is accessed. If these requirements aren’t specified they won’t be built or tested.

“The key problem is that, at the network level, data used to exploit security flaws is often indistinguishable from legitimate application data. Our only hope is to tackle vulnerabilities at their root – in the applications themselves.”

STEP 1. THREAT MODELLING:

Threat modelling is an approach for analysing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modelling is not an approach to reviewing code, but it does complement the security code review process. The inclusion of threat modelling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning.
There are several good reference guides to help with threat modelling, including a free threat modelling reference from the National Institute of Standards and Technology (NIST).

STEP 2. ARCHITECTURE AND DESIGN REVIEW PROCESS:

The architecture and design review process analyses the architecture and design from a security perspective. If you have just completed the design, the design documentation can help you with this process. Regardless of how comprehensive your design documentation is, you must be able to decompose your application and be able to identify key items, including trust boundaries, data flow, entry points, and privileged code. You must also know the physical deployment configuration of your application. Pay attention to the design approaches you have adopted for those areas that most commonly exhibit vulnerabilities. This guide refers to these as application vulnerability categories. There are many excellent resources available for code reviews including those from Microsoft.

STEP 3. GET DEVELOPERS SECURITY-SAVVY:

The most effective solution is to train developers from the beginning on secure coding techniques. The securitysavvy software developer leads all developers in the creation of secure software, implementing secure programming techniques that are free from logical design and technical implementation flaws. This expert is
ultimately responsible for ensuring customer software is free from vulnerabilities that can be exploited by an attacker. At the implementation stage, security is largely a developer awareness problem. Given a specific requirement or design, code can be written in a vast number of ways to meet that objective. Each of these can lead to an application that meets its functional requirements.

By implementing these secure coding standards in your organisation and enforcing them through secure code reviews and static analysis tools, you can suppress one of the most common causes of released vulnerabilities in software.

“Security design reviews give an early insight into potential problems, as does threat modelling, and both can be performed early where security defects are easier and less costly to fix.”

STEP 4. PENETRATION TESTING:

Penetration testing (also called pen testing) is the practice of testing a computer system, network or Web application to find vulnerabilities that an attacker could exploit. Pen tests can be automated with software applications or they can be performed manually. Either way, the process includes gathering information about the target before the test (reconnaissance), identifying possible entry points, attempting to break in (either virtually or for real) and reporting back the findings.

This puts the application through the paces of a series of attacks. Output from the threat models can be reused here to establish the focus and scope of the testing. For example, did the tester try a series of SQL injection attacks vs. Cross Site Scripting? Did the tester attack the user interface vs. the database server?

 

diagram_steps

Figure: Penetration Testing

STEP 5. FINAL SECURITY REVIEW:

This step is conducted prior to deployment and is the last look in the mirror before walking out the door. Have all those weak spots found in the threat modeling and penetration testing.

 

SECURITY PRINCIPLES FOR SECURE CODE DEVELOPMENT

1. MINIMIZE ATTACK SURFACE AREA:

Every feature that is added to an application adds a certain amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack space.

2. PRINCIPLE OF LEAST PRIVILEGE:

The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions, such as CPU limits, memory, network, and file system permissions.

3. PRINCIPLE OF DEFENSE IN DEPTH:

The principle of Defense in Depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better.
Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur. With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.

4. FAIL SECURELY

Applications regularly fail to process transactions for many reasons. How they fail can determine if an application is secure or not. External systems are insecure. Many organizations utilize the processing capabilities of third-party partners, who more than likely have differing security policies and posture. It is unlikely that an external third party can be influenced or controlled; implicit trust of externally run systems is not warranted. All external systems should be treated in a similar fashion.

5. SEPARATION OF DUTIES

A key fraud control is separation of duties. For example, someone who requests a computer cannot also sign for it, nor should they directly receive the computer. This prevents the user from requesting many computers, and claiming they never arrived. Certain roles have different levels of trust than normal users. In particular, Administrators are different to normal users. In general, administrators should not be users of the application.

6. DO NOT TRUST SECURITY THROUGH OBSCURITY

Security through obscurity is a weak security control, and nearly always fails when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon keeping details hidden.

7. SIMPLICITY

Attack surface area and simplicity go hand-in-hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code. Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.

8. FIX SECURITY ISSUES CORRECTLY

Once a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue. When design patterns are used, it is likely that the security issue is widespread amongst all code bases, so developing the right fix without introducing regressions is essential.

THE TEN BEST PRACTICES
1. Protect the Brand Your Customers Trust
2. Know Your Business and Support it with Secure Solutions
3. Understand the Technology of the Software
4. Ensure Compliance to Governance, Regulations, and Privacy
5. Know the Basic Tenets of Software Security
6. Ensure the Protection of Sensitive Information
7. Design Software with Secure Features
8. Develop Software with Secure Features
9. Deploy Software with Secure Features
10. Educate Yourself and Others on How to Build Secure Software

BENEFITS OF SECURE SDLC

1. Build more secure software
2. Help address security compliance requirements
3. Reduce costs of maintenance
4. Awareness of potential engineering challenges caused by mandatory security controls
5. Identification of shared security services and reuse of security strategies and tools
6. Early identification and mitigation of security vulnerabilities and problem
7. Documentation of important security decisions made during the development

CONCLUSION:

Security and development teams can work together—they just need to look for common areas in which they can make improvements. Security teams focus on confidentiality and integrity of data, which can sometimes require development teams to slow down and assess code differently. At the same time, business units require developers to produce and revise code more quickly than ever, resulting in developers focusing on what works best instead of what is most secure.
This difference in focus does not mean that either side is wrong. In fact, both teams are doing exactly what they’re supposed to do. However, in order to facilitate teams accomplishing both sets of goals and working together more fluidly, changes to tools and processes are necessary.

REFERENCES:

1. http://info.whitehatsec.com/rs/whitehatsecurity/images/statsreport2014-20140410.pdf
2. https://www.owasp.org/images/7/7c/OWASP-Building-Secure-Web-Apps-070110.pdf
3. https://www.us-cert.gov/control_systems/pdf/ICSA-12-243-01.pdf
4. https://www.owasp.org/index.php/The_Owasp_Code_Review_Top_9
5. https://www.owasp.org/index.php/Testing_for_authentication
6. https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet
7. https://www.owasp.org/index.php/Application_Threat_Modeling

 

AUTHOR:

Security Consultant, Varutra Consulting, Pvt. Ltd.