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.

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

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

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.

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.

10/27/15

External Penetration Testing – Case Study

Penetration Testing

ABSTRACT

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

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

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

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

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

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

BACKGROUND

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

APPROACH AND METHODOLOGY

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

Information gathering (Active & Passive)

– Attacking on DNS

– Discovering Firewall & IPS

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

Attacking WordPress application

Attacking Joomla application

Attacking Web Servers

– Attacking Web Applications

– User Account Bruteforcing

Attacking Network Layer

– Attacking Web Servers

– Attacking Email Server

– Firewall Evasion

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

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

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

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

 External Penetration Testing Methodology

Figure: External Penetration Testing Methodology

 

KEY FINDINGS/OBSERVATIONS

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

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

 

KEY HIGHLIGHTS

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

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

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

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

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

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

 

DELIVERABLES

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

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

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

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

 

BENEFITS

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

Additionally, the client gained the following benefits:

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

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

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

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

 

REFERENCES

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

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

 

AUTHOR:

Omkar Joshi & Chetan Gulhane

Security Consultant, Varutra Consulting Pvt. Ltd.

10/4/14

Shellshock-Security Patching Aftermath

Shell Shock-

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

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

Detailed Explanation

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

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

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

How does this Attack works?

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

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

cmd4

 

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

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

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

cmd 1

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

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

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

cmd2

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

cmd 3

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

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

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

Some attacks using shellshock

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

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

Figure : Working of Shellshock

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

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

Proof of Concept for incomplete fix to shellshock

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

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

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

Shell Shock --

 Figure: Unpatched Bash

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

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

Deadening Shellshock

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

APT-GET: Ubuntu / Debian

Update Bash to the latest version available via

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

YUM: CentOS / Red Hat / Fedora

Update Bash to the latest version available via the yum:

sudo yum update bash

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

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

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

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

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

References:

https://www.cloudflare.com

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

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

https://www.qualys.com

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

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

07/15/14

VoIP Penetration Testing Part – IV

 

In the previous tutorial VoIP Penetration Testing Part – III we have learnt about SIP User extension enumeration. This is the last article in which we will focus on various VoIP attacks such as attacking VoIP authentication, DoS Attack and Caller ID Spoofing.

Attacking VoIP Authentication :

SIP uses Digest Authentication, which is vulnerable to a basic offline dictionary attack.

In order to perform an offline dictionary attack, the attacker needs to sniff the username, realm, Method,URI and MD5 response hash over the network.

http://varutra.com/blog/wp-content/uploads/2014/07/1.jpg

Figure : Attacking VoIP Authentication

All of these are available over the network in clear text. Once this information has been obtained using sniffing, attacker can perform offline dictionary attack.

Lab Setup :

1.  Install Backtrack 4
2. Two Softphone on two systems. In our case

  • First Softphone (sachin-100)
  • Second Softphone  (wagh-200)

 Steps :

1.  Using wireshark first capture few REGISTER  requests and save it in a file called voip_attack.

http://varutra.com/blog/wp-content/uploads/2014/07/2.jpg

                                                                    Figure : Capturing REGISTER Request.

2.  Now use sipcrack suite, which is available in Backtrack under /pentest/voip directory.

SIPcrack is a SIP login sniffer/cracker that contains two programs:

  • sipdump to capture the digest authentication.
  • sipcrack to bruteforcethe password hash using a wordlist or standard input

3.  Using sipdump tool, let us dump the authentication data to a file and name it as Auth.txt

http://varutra.com/blog/wp-content/uploads/2014/07/3.jpg

                                    Figure : Dumping authentication data using sipdump

4.  This authentication data includes User ID, SIP extension, password hash (MD5) and victim’s IP address.

sipcrack Usage :

http://varutra.com/blog/wp-content/uploads/2014/07/4.jpg

Figure : sipcrack Usage

5.  Let us now use sipcrack tool to crack the authentication hashes using a custom word list.

http://varutra.com/blog/wp-content/uploads/2014/07/5.jpg

Figure : Cracking authentication hash using sipcrack

Denial of Service (DOS) attack On VoIP Network :

Denial of Server (DOS) attack is a dangerous attack that can cause the  VoIP network and devices to crash. Inviteflood is the tool used to launch DoS attacks.This attack can occur on two levels, standard network DoS attacks and VoIP specific DoS attacks. Generally we will send tons of data by flooding the network to consume all its resources or a specific protocol in order to overwhelm it with tons of requests.

inviteflood usage :

http://varutra.com/blog/wp-content/uploads/2014/07/6.jpg

Figure : inviteflood usage

As long as the tool keeps flooding the SIP gateway it will prevent users from making phone calls resulting in a DoS attack.

Syntax:
./inviteflood interface  Extension Target_domain target_ip Number_of_packets

http://varutra.com/blog/wp-content/uploads/2014/07/7.jpg

Figure : DoS attack using inviteflood

Caller ID Spoofing :

This is one of the easiest attacks on VoIP networks. Caller ID spoofing creates a scenario where an unknown user may impersonate a legitimate user to call other legitimate users on VoIP network. For demonstration, let us use metasploit’ auxiliary module named sip_invite_spoof.

Lab Setup :

Configure two Softphone on two different machines. In our case

  • First Softphone  (sachin-100) – 192.168.0.3
  • Second Softphone  (wagh-200) -192.168.0.139

Steps :

1.   Start your metasploit and load /auxiliary/voip/sip_invite_spoof auxiliary module.
2.   Configure the option.


http://varutra.com/blog/wp-content/uploads/2014/07/8.jpg
http://varutra.com/blog/wp-content/uploads/2014/07/9.jpg

Figure : Caller ID Spoofing

In our case
Set MSG 200—————————-Caller ID
Set RHOSTS 192.168.0.3————-Victim IP Address
Set SRCADDR 192.168.0.139——-Caller IP Address
3.   Auxiliary module will send a spoofed invite request to the victim user.

http://varutra.com/blog/wp-content/uploads/2014/07/10.jpg

Figure : Spoofed invite request.

4.  Victim considers it as legitimate call from other legitimate user. Bingo 🙂 🙂 🙂

 

Summary :

In this series of VoIP Penetration Testing we have learnt VoIP installation, Information gathering, Scanning, Banner Grabbing, Enumerating TFTP Server, User enumeration, attacking VoIP authentication, DoS attack, Caller ID spoofing, etc.

Hope you will find this article informative and useful in understanding the VoIp security issues and for conducting penetration testing. Do let us know your views.

Author: Sachin Wagh

Security Consultant, Varutra Consulting

06/23/14

VoIP Penetration Testing Part – III

In the previous tutorial VoIP Penetration Testing Part-II  we have learnt on how to do scanning against VoIP Server. In this tutorial we will configure the softphone which we will be using for further attacks.

Softphone Configuration :

Lab Setup :

  1. VoIP Server -192.168.0.4
  2. Two Softphone on two systems running on VMware’s

Steps :

1.   The main task is to configure Softphone. Download Zoiper Softphone from below link.

http://www.zoiper.com/

2.  Open your browser and enter IP address of your server. In my case it is http://192.168.0.4

Click on PBX > PBX Settings > Extensions

3.  Select Generic SIP Device and click on submit.

1

 

4.  You need to enter following detail :
User Extension: ( 202,302,402 and so on)
Display Name: (Enter the name of your choice)

2

5. Secret: (Enter string of your choice)

3

6. Click on Add Extension.

In my case I have added two extensions as shown below. After adding extension, do not forget to click on the Apply Configuration Changes button.

4

7. After clicking Apply Configuration Changes button, you will see following popup. Click on Continue with reload.

5

8. Now let us configure the Softphone.

6

9. Enter the password, which you have entered in the Secret field at the time of adding user on server. In username field enter the User extension that you have added in step 4 (E.g:100,200,) and in Domain field enter the IP address of Server. After submitting this information click on apply.

10. After Successful registration you will see following screen

7

Note: Same way we have configured one more softphone for user ‘wagh’.

11. Now let us try to call from user wagh to user sachin to check whether the setup is working properly.

8

It was observed that call from user wagh to sachin was successful.

SIP User Extension Enumeration :

The next and last step in information gathering is enumeration. It involves probing the identified services for known weaknesses. Enumeration involves getting information such as user account names, misconfigured shared resources, and software versions. One of the most common enumerations is against SIP protocol.

Targeting SIP proxy or location server will provide user registration and presence.

Lab Setup :
1. Client where the softphone is installed – 192.168.0.5
2. Server IP – 192.168.0.7

Before starting the practical, let us understand the SIP Request method and Response code.

SIP Request Method:

1
SIP Response Code:

2

Methods of enumeration:

  • REGISTER  – username enumeration
  • INVITE  – username enumeration
  • OPTIONS – username enumeration

1.  Username enumeration using REGISTER request method:

This involves gaining information about valid accounts registered on the VoIP network using error messages from SIP proxy or registration servers. Attacker sends SIP REGISTER requests to the proxy or registration server with the specified extension and checks for the response status code if and extension is valid. When the 401 Unauthorized or 407 Proxy Authentication Required or 200 OK is received, the SIP account username was valid. If 403 Forbidden is received, the SIP account username was invalid.

3

 

SIPVicious is a suite of command-line tools that works on Linux, Mac and Windows platforms.

The suite of tools includes

  • Svmap
  • Svwar
  • Svcrack
  • Svreport
  • Svcrash

For extension scanning, the svwar.py tool is used, which supports REGISTER, INVITE and OPTIONS scans. It supports all  three extension enumeration methods, the default method for enumeration is REGISTER.

4

2. Username enumeration using INVITE request method:

Sending an SIP INVITE request, means initializing a call to target with valid user usually generates 100 Trying and 180 Ringing messages, which means the SIP username extension was valid. When 404 Not Found is received, it means the SIP username extension was invalid. INVITE requests can be sent directly to phones if their IP addresses are known.

5

You will see calling screen on 192.168.0.5 System when you send INVITE request.

6

3. Username enumeration using OPTIONS request method:

The OPTIONS method is the most stealthy and effective methods.
The OPTIONS is used to advertise supported message capabilities and legitimate users.
Depending on if the received message was 200 OK or 404 Not Found, you can differentiate the valid and invalid SIP username extensions.

7

Svmap allows specifying the request method, which is being used for scanning.
The default method is OPTIONS.

8

In next and last tutorial we will learn on exploitation phase with various attacks.

Author: Sachin Wagh

Security Consultant, Varutra Consulting