Cross Site Port Attack (XSPA)

 

CROSS SITE PORT ATTACK (XSPA)

INTRODUCTION:

A web application is helpless against Cross Site Port Attack if it forms client provided URLs and does not disinfect the backend reaction got from remote servers previously sending it back to the client. The responses, in specific cases, can be concentrated to distinguish benefit accessibility (port status, flags and so forth.) and even bring information from remote administrations in unique ways.

Detecting a potential XSPA vulnerability is very simple and if the web app takes URL as input and tries to make it connect to the port and analyse the output and I have been attempting this XSPA attack on a testing app http://testphp.vulnweb.com/

Once I visited the testing site, and here I have selected the image categories option on the site as follows

Later I have selected the required image file it takes me to the URL as follow

Once I Visited this site I have started to capture the backend response using Burp Suite tool

Burp Suite is a graphical tool for testing Web application security, and It was mainly developed to provide a comprehensive solution for web application security checks. and In addition to this basic functionality, it also has some extra features such as proxy server, scanner and intruder, the tool also contains more advanced options such as a spider, a repeater, a decoder, a comparer, an extender and a sequencer

I have cross checked this site using my localhost with some ports and captured the response in burp suite, and by this method, we can precisely analyse the response for each port

Here I have captured the response of the image URL and crossed check it with my localhost with port 80(HTTP), and I can see the response 200 OK (Normal response)

Once It fetches the average result, and you can also confirm this for other ports like 22(ssh), 21(ftp), 25(SMTP), 8080(https) etc. and you can check the result in browser as well.

During Port analysis, if any required port is closed, it fetches the result as

It also shows the response of 200, but it displays some warning like (failed to open) or connection refused etc. and if it shows this case of errors then you can confirm that the port is closed

In the above screenshot shows the different case of the port is opened but it shows the result without exposing the attacker IP on the server logs and it also reveals the backend service running on SSH

MITIGATION FOR XSPA ATTACK:

• Unauthorized URL’s access should be restricted
• Restrict Connectivity to the internal ports
• Whitelist IP address
• Disable Unwanted protocols and services.
• You can block your ports using firewall for better security please check the link below to block your inernal ports

Reference Link:

http://www.thewindowsclub.com/block-open-port-windows-8-firewall

CONCLUSION:

XSPA vulnerability attack mainly used to perform port scanning of a target using another vulnerable website and also an attacker can perform a DOS attack, Code Execution and other major attacks on other vulnerable  websites

Reference Link:

https://teamultimate.in/cross-site-port-attack-xspa-tutorial/

http://indiatriks.blogspot.in/2012/07/xspa-cross-site-port-attack.html

AUTHOR

RamKumar G

SecurityEngineer

BriskInfoSec Technology and Consulting PVT LTD

Find  me @ https://www.linkedin.com/in/ram-kumar-3439b511a/

Detection and Exploitation XML Entity Injection(XXE)

DETECTION AND EXPLOITATION XML ENTITY INJECTION(XXE)

INTRODUCTION

XML External Entity Attack is a type of injection or input validation vulnerability which occurs in an application that allows any input parameter or data to be XML input or input which is combined into XML form data, and it is passed to an XML parser running with sufficient privileges to include external or system files.

Recently, there has been an increase in the use of XML documents due to the growing use of the web services such as REST API and SOAP, which commonly use XML to process the data.

XML has a feature to create entities dynamically; some of the objects are predefined, and they referenced by using an ampersand (&) and a semicolon (;) at the end. However, XML also allows us to create custom entities, the most popular being the internal and external entities. Internal entities can be used to reference internal data and external entities to reference data from external sources.

EXAMPLE FOR INTERNAL ENTITY:

<!DOCTYPE profile [<!ENTITY name "Brisk Infosec">]>
<Profile>
<name>&name;</name>
<class>Cyber Security</class>
<service>Pentest</service>
</profile>

In the first line, we have defined an entity “name” having a value “Brisk”; the block used to define the entities is known as the DTD block. Next, in the third line, you can see that we have referenced the entity “&name;”, which holds the value “Brisk.” In this way, we don’t have to input the name each time. All we have to do is use a reference to the entity.

EXAMPLE FOR EXTERNAL ENTITY:

<!DOCTYPE profile [<!ENTITY name SYSTEM "http://target.com/profile ">]>
<Profile>
<name>&name;</name>
<class>Data</class>
<service>pentest</service>
</profile>

In the first line, in the DTD block, we have defined an external entity, which contains a link to an external resource. When this XML document is processed, it would request an external source and would replace values of all instances of “&name;” with the content of the external resource. If the content of the external resource is processed and displayed back to the user without proper validation, an attacker may be able to abuse the parser in conducting an XXE injection attack.
To find any XXE (XML External Entity) vulnerability, attacker or tester needs to inject XML characters in all input fields and observe if XML parsing errors are generated.

EXPLOITATION OF XXE VULNERABILITY:

Use information disclosed in error messages to determine at what file path the XML parser is parsing. Cause errors to occur using malformed XML.

Let us consider a test website (here I’m using OWASP Mutillidae application)

1. In below image, the application has an XML parser input page,

2. Let’s try giving some XML inputs and check the response from the server.

3. After that, we can try to inject XML inputs with multiple user-defined entities

4. Now we can try to include external data using <!Entity> section of XML input. The <!ENTITY> section of an XML document optionally defines external files to be included as part of the XML document. Interestingly these can even be files from the system parsing the XML.

We can use the <!ENTITY> section of XML input, we can try to access local files like /etc/ passwd files of a Linux server.

5. Once we have given the above XML payload, we can get the password files details from back-end Linux server.

6. Similarly, we can try to load the boot.ini files if the server is windows operating system, using an XML payload like below

          <?xml version="1.0"?>

            <!DOCTYPE change-log [
                        <!ENTITY systemEntity SYSTEM "../../../../boot.ini">
            ]>
            <change-log>
                        <text>&systemEntity;</text>
            </change-log>

MITIGATIONS FOR XXE INJECTION ATTACKS:

1. XML parser functions like unmarshaller should have a secure configuration to prevent allowing external entities as part of an incoming XML document input.

2.XML inputs should not be processed directly as java.io.File, java.io.inputstream.

References:

https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
https://stackoverflow.com/questions/40649152/how-to-prevent-xxe-attack

Dawood Ansar

Security Engineer

BriskInfosec Technology and consulting PVT LTD

Find me @https://www.linkedin.com/in/dawood-ansar-29403213b/

MARA FRAMEWORK

MARA FRAMEWORK

Mobile Application and Reverse Engineering and Analysis Framework and it’s a tool that contains some major reverse engineering and analysis tools for Mobile Application testing and using this framework we can decompile a particular APK file and analyze the major issues in OWASP Mobile Top and this tool is been mainly used by the Penetration testers, security researchers, and application developers.

We can also use the various features of the APK file like

• APK Reverse Engineering
• APK DE obfuscation
• APK Analysis
• APK Manifest Analysis
• Domain Analysis
• Security Analysis etc.

APK REVERSE ENGINEERING:

• Disassembling Dalvik bytecode to smali bytecode via baksmali and apktool
• Disassembling Dalvik bytecode to java bytecode via enjarify
• Decompiling APK to Java source code via jadx–gui

APK DEOBFUSCATION:

We can extract the APK and analyze the code using Jadx-gui and it shows the codes that has been available for a selected APK File

APK ANALYSIS:

• Parsing smali files for analysis via smalisca
• Dump all assets, libraries and resources
• Extracting certificate data via openssl
• Identify methods and classes via classyshark
• It Extracts the Manifest File in XML format
• Scan for apk vulnerabilities via androbug framework
• Analyse the APK for Potential malicious behavior like androwarn

APK MANIFEST ANALYSIS:

• It Extracts the Intent and exported activities
• It Extracts the Manifest Files and services
• Extract exported services
• Checks if the APK is debuggable
• Checks if the APK allows Databackup
• Check if the APK receives any binary SMS

DOMAIN AND SECURITY ANALYSIS:

Domain analysis is been fetched from the WhatsWeb and the security analysis is checked from the OWASP mobile TOP 10 Checklist

INSTALLATION:

I have downloaded the MARA Framework from Github and listed the option in the framework

We need to launch MARA framework by using the command ./mara.sh

OPTIONS IN FRAMEWORK:

Here In the particular folder of MARA Framework you can see the option by the command of ./mara.sh

And I have downloaded a vulnerable app and configured in the Mara framework

APK ANALYSIS AND REVERSE ENGINEERING:

And after the analysis of the APK it gets saved in the particular folder as given in the below screenshot

Particular Folder that has been saved on the PC is by the below screenshot

Here the decompiled files get saved on the MARA-Framework folders and by viewing this files you can check for the required issues by the vulnerable APK-file.

CONCLUSION:

A multiple set of test tools will be necessary for a more thorough and comprehensive testing process .I have given an overview of the MARA Framework setup process and how it can expedite your android app reverse engineering and static analysis process.

BriskInfosec holds utmost experience in Mobile App Penetration Test to identify potential vulnerabilities and insure coding practises in android application

To know more get in touch with us

AUTHOR

Rajesh

Security Researcher

BriskInfoSec Technology and Consulting PVT LTD

Find @ https://www.linkedin.com/in/rajesh-karunakaran-4aa392102/

LYNIS- Open-Source Linux System Auditing Tool

LYNIS- OPEN-SOURCE LINUX SYSTEM AUDITING TOOL

Lynis is a system based auditing and open source tool. It supports with the auditing systems which is running UNIX-systems and providing controls for system hardening and comliance based testing.

By running ‘lynis’ the program is begun and will give the essential parameters accessible. If you are using it for first time Lynis (or utilized Git), at that point utilize “./lynis” to begin the program from the local directory.

The most common command to begin Lynis is utilizing review framework order. This still begin the security scan.

To run Lynis you should meet one essential: have compose access to/tmp (temporary documents).

INSTALLATION VIA PACKAGE

Installing Lynis via a package manager is one option to get started with Lynis. For most operating systems and distributions, a port or package is available.

First add our software repository. This way the latest version will be available to your system.

RED HAT

This applies to systems running YUM, including CentOS, Fedora, Red Hat Enterprise Linux (RHEL).

$ yum install lynis

DEBIAN

Systems running Debian, Linux Mint, Ubuntu, or are based on one of these.

$ apt-get install lynis

OPENSUSE

$ zypper install lynis

After the installation, it is time to run Lynis for the first time.

INSTALLATION VIA GIT

Clone project

The first step is cloning the project. Before doing so, select the parent directory. Git will create a ‘lynis’ subdirectory with the full program in it.

$ cd /Desktop

$ git clone https://github.com/CISOfy/lynis

Cloning into ‘lynis’…

remote: Counting objects: 1733, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 1733 (delta 3), reused 0 (delta 0), pack-reused 1725
Receiving objects: 100% (1733/1733), 886.18 KiB | 378.00 KiB/s, done.
Resolving deltas: 100% (1204/1204), done.
Checking connectivity... done.
$ cd lynis

That is it. Time to run your first security audit:

$ lynis audit system

Although no configuration is required, there are a few useful commands to learn.

LYNIS COMMANDS

The Lynis tool requires a minimum amount of parameters to run. If you are using it for the first time, just run lynis and see what output it provides.

                                    ./lynis

AUDIT

The audit command tells Lynis to perform an audit.

Targets include:

• system - audit the host system

• docker file - audit a docker file

SHOW

The show command informs Lynis to share information, like help or the value of something.

Options:

• help – show help and tips
• profiles – show discovered audit profiles
• settings – show active settings
• version – show Lynis version

• Here you can see the commands which are all given in the Lynis auditing tool,There are more options which are given below, some of them are layout options, misc options and Enterprise options too.

• Lynis scans the system and performs the tests, results should be displayed on the screen. The log files should be displayed on the screen during the system scan. To check that log database to saved here var/log/lynis.log. The log file should store once the backup before the process of running Lynis again and again. During the audit process, Lynis will gather some findings and data points should use where we can find that storage process using varlog/lynis-report.dat.Benefits:
  • Perform audits within a few minutes
  • System hardening can be done
  • Central management
  • Powerful reporting
  • Compliance checks (e.g. PCI DSS)
  • Additional plugins and more tests
  Comparison between Lynis and other tools:
  Hardening process are easily exposed when compared to other auditing tools such as Bastille, TOD (Touch of Death). It conserves time when compared to other auditing tools.
  It helps to track your compliance needs, IT audits, better security defences.
  Operating system Finding:
  It detects the operating system name, operating system version, host name and hardware platform for the Lynis tool.
  Lynis runs almost all UNIX-based systems and versions including,
  AIX
• FreeBSD
• Linux
• macOS, Solaris etc…

• It even runs on the storage devices like Raspberry Pi, or QNAP

• System Tools:It find out the Binaries, scanning the tools which are all currently updated or not and used some plugins also in this system tools.

• Boot configuration:In this boot configuration level issues to be find whether the password is encrypted, booting method like legacy boot or UEFI boot method, Grub checking possibilities, and how many services are running in the system, to check the start-up files also.

Conclusion:

Security need to be reliable. Lynis can remind us to stay consistent. Lynis will scan your system and warn you for any security holes. This blogs gives an idea about Lynis server hardening tool to harden server and also discussed about where the exact location of hardening. BriskInfosec offers end to end server hardening solutions where ever the industry requires to know more get in touch with us.

AUTHOR

Aravind

Security Engineer

BriskInfosec Technology and consulting PVT LTD

Find me @https://www.linkedin.com/in/aravindhan-s-90b98787/

How can Insecure CORS lead to a biggest security threat for your application?

HOW CAN INSECURE CORS LEAD TO A BIGGEST SECURITY THREAT FOR YOUR APPLICATION?

WHAT IS THE MEANING OF AN ORIGIN?

Two websites are said to have same origin if both have following in common:

• Scheme (http, https)
• Host name (google.com, facebook.com, briskinfosec.com)
• Port number (80, 4657, 7777)

So, sites http://example.com and http://example.com/settings have same origin. But https://example.com:4657 and http://example.com:8080/settings have different origins.

The ‘Same Origin Policy’ restricts how a script loaded from one origin can interact with a resource from another origin. It is an important built-in security mechanism for browsers for isolating potential malicious scripts.

WHAT IS CROSS ORIGIN RESOURCE SHARING?

It is the need of Web 2.0 to share resources across origins. Following are some examples:

• Cross Origin Writes: A website can POST data to an endpoint of another website.
• Cross Origin Embedding: A website can refer images from another website using <img src> tag. Also, an iframe using <iframe src> tag can be embedded if the source website allows it.

Apart from the above two scenarios, when one website reads data from another website, it is called as ‘Cross Origin Resource Sharing’ aka CORS.

CORS is a W3 specification that allows cross domain communications from the browser. It works by adding new HTTP Headers that describe the origins that are allowed cross domain information sharing.

In other words, CORS is used to relax the ‘Same Origin Policy’ for legitimate and trusted requests. It is an essential feature of Web 2.0 to support APIs that are exposed via web services to be accessible.

 Some noteworthy example of web applications supporting CORS: Google, YouTube, Flickr.

TWO MOST IMPORTANT CORS HEADERS:

• Origin: It is set by browser in every CORS request. Its value is the domain name from which the request originates.
• Access Control Allow Origin: It is set by server in every CORS response. Depending on its value, the browser decides if the response is allowed or not. It can be set to * (also called the wildcard character) to make resources public (However, this is not a good practise).

PRE-FLIGHT REQUEST

A pre-flight request is just a normal HTTP request that happens before the actual cross-domain communication. The logic behind this is to ensure the client and server are fully compatible (protocol, security, and so on) with each other before the data is actually exchanged. If they are not, then the relevant error is raised.

Please keep that in mind that a pre-flight request only triggers if:

• Custom HTTP headers are sent
• The body MIME-type is different than text/plain
• The HTTP method is different than GET or yuPOST

The following is a typical pre-flight request-response pair:

Request:

   OPTIONS / HTTP/1.1
   Origin: http://api.user.com
   Access-Control-Request-Method: PUT
   Host: api.example.com
   Accept-Language: en-US
   Connection: keep-alive
   User-Agent: Browser

Response:

   HTTP/1.1 204 No Content
   Access-Control-Allow-Origin: http://api.user.com
   Access-Control-Allow-Methods: GET, POST, PUT
   Content-Type: text/html; charset=utf-8

SIMPLE REQUEST

A simple CORS request is similar to a pre-flight request without the initial capability exchange sequence occurring. In a typical simple CORS request, the following sequence happens:

Request: http://example.com  – Origin A

Response: http://cdn.briskinfosec.com – Origin B

1. Origin A attempts to access the home page of a CDN running at origin B, http://cdn.briskinfosec.com , using CORS.
2. Origin A sends a GET request to the Origin B web server.

The Origin B server responds with Access-Control-Allow-Origin.

A SCENARIO TO EXPLOIT CORS VULNERABILITY:

In this demo we are going to use a vulnerable intranet application which has a secret located at ‘secret-cors-3.php’. It has an Admin who accesses it from his local environment. Its URL is: http://127.0.0.1:80/bwapp/.

As it is an intranet application, the attacker cannot interact with it remotely. Our goal as an attacker will be to capture the secret (from a remote internet location) by exploiting CORS vulnerability.

THE EXPLOITATION:

• The attacker hosts a website containing the malicious script for cross domain interaction.
• Victim i.e. the Admin of the intranet website visits the attacker’s website. Location http://127.0.0.1:4567

• Response is received from the attacker’s website containing the following malicious payload:

• As soon as the web page is loaded, ‘makeRequest’ method is called. The method initiates a cross domain request to capture the secret, to the vulnerable intranet application located at ‘http://127.0.0.1:80/bwapp/secret-cors-1.php’

• It fetches the response and stores it in the variable ‘secret’.

• The ‘Access-Control-Allow-Origin’ has value set to *. So, the malicious script now has the payload and it simply issues a GET request to the attacker’s web server. Attacker hosts another web server at location: http://127.0.0.1:7777

• Meanwhile, attacker monitors the logs of that web server. The payload gets executed and the logs receive the secret.

HOW TO MITIGATE IT?

• ‘Access-Control-Allow-Origin’ should be never set to * if the resource contains sensitive information.
• The mitigation is simple and just a proper configuration. Configure the Access-Control-Allow-Origin header to allow requests only from the domains that you trust. For e.g.: Access-Control-Allow-Origin: Saurabh.com. The below image illustrates that the CORS attack does NOT get executed when the server is configured with correct ‘Access-Control-Allow-Origin’ instead of a ‘Wildcard’ character.

• Make sure that in server side validation for checking the origin header value, you are comparing with absolute value and NOT with regular expression.
• For example: The following code does a comparison with regular expression:

RegEx(“^https://mail.example.com$”)

In the above validation, dots (.) mean any character. So, an attacker can bypass it by making the CORS request origin from following domain: https://mailxexample.com
The patched code will be:

            if($_SERVER[“HTTP_ORIGIN”] == “https://mail.example.com”)
                    {
                        header(“Access-Control-Allow-Origin: https://mail.example.com”);
                    } 

• Client should not trust the received content without sanitization because that will result in client side code execution. For example: If website abc.com trusts and fetches cross domain data from example.com. example.com has a malicious intent and starts sering malicious javascript to abc.com, then abc.com can protect its users from cross site scripting by sanitizing the received data and then presenting it to its users.

WHAT IF THE ORIGIN HEADER IS SPOOFED?

The point of origin header is not to protect the resources on the server, that task is up to server itself. Origin header is to protect the user. Following scenario demonstrates it:

• An attacker Charlie creates a malicious website M
• User Alice is tricked into visiting website M which tries to perform CORS action on server example.com that supports it.
• The domain example.com will be listed in website M’s list of allowed domains. So, the request will be rejected.
• The important point here is that M cannot spoof the origin header because the request is initiated from Alice’s browser.
• This can be done by Alice using a local proxy tool. But why would a victim hack himself, so this scenario is not real.

Another way, an attacker can do this, is by intercepting the request being a man in the middle. But if the attacker has access to the traffic, then capturing cookies and session ID are better options rather than changing the Origin header.

OWASP CATEGORY FOR CORS VULNERABILITY:

This vulnerability falls under to the category of ‘Security Misconfiguration’ of OWASP Top 10. The HTTP response header ‘Access-Control-Allow-Origin’ is not configured correctly and this creates the issue.

REFERENCES:

• In the demo, Bwapp was used as the target web application. It is a deliberately made insecure web application. More about it at –http://www.itsecgames.com/
• CORS Introduction –https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
• Same Origin and Cross Origin Policies:https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

We have discussed about what CORS is and how to exploit CORS vulnerability in the web application and API web services .It is important to   verify that the CORS are configured properly. As a p part of web application   we need to make sure the shared resource are secure and HTTP headers haven’t tampered. A CORS Exploitation can cause great consequences letting sensitive data to compromise.

BriskInfosec provides the best web application and API security test.  Discover the reason to conduct Application Security test with us.

Reach us – Contact@briskinfosec.com

Author

RadhaKrishnan

Security Engineer

BriskInfosec Technolagy and Consulting PVT LTD

https://www.linkedin.com/in/radhakrishnan-r-209607111/