Tuesday, September 3, 2013

Figure 1: New Search Engine in Development
Scenario:
A malicious code had access to a small enterprise of web developers, who are working on building a new search engine that will be participating on the market. Figure 1 shows a screenshot of the new project.

To verify the functionalities of this new search engine, we are going to make some tests. First, we will enter the word "trololo" to see the results. The server response to the request mentioned above is:
Figure 2: Search results for trololo of the new project

As you can see, this modest search engine is not ready to compete in the market, since the database is still very small, and only responds to keywords like "facebook" or "trololo":

Figure 3: Search results for facebook of the new project

Because the database is so poor, the developer has decided to redirect searches to other popular search engine in case that you don't get results. For example, let's try it with the word "nirvana" which is not found in the database corresponding to the new project:

Figure 4: Nirvana Search in the new project

The search is redirected to another search engine and the result can be seen below:

Figure 5: Nirvana Search Results on Bing

As you can see, the previous action aims to continue loading the database based on the response of the other search engines. Broadly speaking, we can understand how the server works.

The problem seems to be that this company has an internal attacker, who was devoted to analyzing vulnerabilities in the search engine, even knowing that it was an alpha version. Additionally, remember that there is a malware that is actively reporting all traffic from the internal network to the outside thereby filtering sensitive information.

A capture of the final traffic sent by the malware can be downloaded here.
Finally, after four days, the server was found in the following state:

Figure 6: Defacement of the search engine

Your job will be to see if it is an external attack executed by the malware author who infiltrated the systems, or whether it is an internal attack. To accomplish this objective You will have to verify the capture available to see if you can get the password of the administrator of that site. If it is possible, what is the password?

Note: In case you find irrefutable proof of his innocence, leave a comment and then develop a small tutorial, demonstrating the accuracy of the analysis. Apparently, only the root user had permissions to modify the files in the web.

Solution:
First, we need a tool to open the file, you can download Wireshark for this purpose, after that, we need to find something unusual in the traffic, as shown in Figure 7, there is an access to a FTP server where a file named data-intrusion.rar was downloaded:

Figure 7: FTP Server Access on Wireshark

In order to get a better view of this traffic we can use the option "Follow TCP Stream", let's see the results:
Figure 8: "Follow TCP Stream" of FTP Server

With this information we can see the credentials that were used to access to the server and the file that was downloaded, then we are going to reassemble the file and see what it contains:

Figure 9: This Image shows the transfer of "data-intrusion.rar"

And the next Figure shows the "Follow TCP Stream" of the RAR File in Raw:

Figure 10: "Follow TCP Stream" of "data-intrusion.rar" in Raw

This stream can be reassembled by pressing "Save as", then name it as you want, but don't forget the ".rar" extension:
Figure 11: "data-intrusion.rar" contains access.log

In the file "access.log" we can see all the requests made to the server and an interesting thing is that the server was attacked by an automated tool to inject SQL sentences.

Figure 12: SQLi requests by an automated tool (sqlmap)

In this case, the log file shows the requests but these are encoded, to learn more about this, please follow this link: HTML URL Encoding Reference
So we need to decode them, in order to make them easier to understand, you can use any tool for that purpose (I used a web app):

Figure 13: SQLi requests decoded (Easier to understand).

Example of one of the requests found in the log file:
"GET /search.php?q=facebook' AND ORD(MID((SELECT IFNULL(CAST(user AS CHAR),0x20) FROM challenge.users ORDER BY id LIMIT 1,1),5,1)) > 116 AND 'zJfx'='zJfx HTTP/1.1" 302 622 "-" "sqlmap/1.0-dev (1bae9955b7) (http://www.sqlmap.org)"

We can see that the tool (sqlmap) made some requests with the objective of getting a dump of the database, the tool is using the keyword "facebook" that would return a 200 code, with this the attacker can dump sensible information, to verify this, we can create a script that shows the results of the requests:

Figure 14: Script to extract useful information from access.log

In Figure 14, we can see the users & passwords that were extracted by the attacker, the last 2 lines are md5 hashes that can easily be cracked.

Decrypted Info:
user: root
password: pepe

user: guest
password: hacker

With these credentials the external attacker can easily make a defacement, so with this we verify that there is no internal attacker, or in this case, the internal attacker was not responsible for the defacement.

0 comentarios:

Post a Comment