Tuesday, 13 March 2018

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/

Thursday, 15 February 2018

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 jadxgui

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

Wednesday, 7 February 2018

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/

Monday, 29 January 2018

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:

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/

Wednesday, 10 January 2018

How serious is Cross-site request forgery (XSRF or CSRF)?



 Brisk Blogs 

HOW SERIOUS IS CROSS-SITE REQUEST FORGERY (XSRF OR CSRF)?


Cross-site request forgery is attacking website as a legitimate and trusted user that tricks the victim submitting a malicious request. An attacker may forge a request to log the victim into a target website  CSRF, this could even lead to further damage.
The attacker often takes advantage of the fact that the user is already authenticated, but with some types of this attack. Impacts of successful CSRF exploits vary greatly based on the privileges of each victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. Utilizing social engineering, an attacker can embed malicious HTML or JavaScript code into an email or website to request a specific ‘task URL’. The task then executes with or without the user’s knowledge, either directly or by utilizing a Cross-Site Scripting flaw  It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can’t be circumvented
As a webmaster, however, you should not assume that you are protected from CSRF attacks when you see anti-CSRF tokens used in your web applications.

BURP SUITE:

Burp Suite is an integrated platform for performing security testing of web applications Burp to test the security of their applications. Some of Burp’s more advanced features will take further learning and experience to master It is not a point-and-click tool but is designed to be used by hands-on testers to support the testing process.
It was developed to provide a comprehensive solution for web application security checks. In addition to basic functionality, 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 A penetration tester configures their Internet browser to route traffic through the proxy which then acts as a sort of Man In The Middle by capturing and analyzing each request and response to and from the target web application.
Step: 1 Here how to test CSRF test manually configure burp suite with your browser
Step: 2 Take authenticated web application Testing Site  You can log in using the credentials test:test.
Step 3: Then value in the field you can change the name email ID PH: NO Example Name Open Burp Proxy open the Tab Intercept On
Step: 4 Update the filed Submit the request so that it is captured  Burp Proxy  the Raw
Step: 5 Right Click Go to Engagement tools Generate CSRF PoC Option
Step : 6 PoC Generated Copy the HTML Open Note pad paste the HTML

Step:7 Modified the data As Test Username Email ID abc@gmail.com
Step: 8 Then Save It has test.html Open another browser login the Test site as test user click and Open the Test.html file submit the request

Step: 9 Attack has been successfully accounting information has been changed serves as an initial check to verify whether the attack is possible web application has been altered. A successful attack shows that the web application is vulnerable to CSRF
Cross-site request forgery is an understated attack technique that can be exceedingly deadly. In some cases it can lead to the complete compromise of a web-based system. We at BriskInfosec take care of the complete   web application security   testing helping the developers to develop their website and application in a secure manner.
For further information please feel free to get in touch with us @ Contact@briskinfosec.com

AUTHOR

Surya
Security Engineer
BriskInfosec Technology and consulting PVT LTD