Exposed APIs of Securities Lending Firm Could Leak Sensitive Data

Exposed QA Systems, Insecure API Design and Weak Security Controls: Perfect Recipe to Trigger Security Breach !

Disclaimer: The information presented in this blog post is for educational purposes only. The research is an outcome of independent efforts that are dedicated towards in making Internet a safer place.

Authors: Aditya K Sood and Rehan Jalil

As part of our in-house cloud security research activities, we continuously look for new threats posed by cloud apps and cloud infrastructure. Our goal is to detect new threats or security flaws in the cloud and then educate the Infosec community on cloud security best practices.

To no one’s surprise, a significant security breach occurred in one of the credit bureau infrastructure that resulted in the exfiltration of sensitive customer data, including Social Security Numbers (SSNs).

During our research over the last few weeks, we came across 3–4 web servers deployed on the AWS infrastructure. We were actually focusing on the AWS exposed documents artifacts as a part of in-house research but, interestingly, web servers running on TCP port 9000/ 9001 caught our attention. These web servers were found to be running in an unauthenticated manner. Upon accessing the HTTP service hosted on TCP port 9000/9001, we found that the web server returned a list of APIs. At first, this looked normal, but on further inspection, we noticed that the API URL contained a name of the credit bureau as the resource. We then queried one of the APIs and found that it was possible to retrieve the data. The APIs were exposed as:

http://<exposed AWS system IP address>/equifaxes{?page,size,sort}
http://<exposed AWS system IP address>/profile
http://<exposed AWS system IP address>/sblFiles{?page,size,sort}
http://<exposed AWS system IP address>/sblSums{?page,size,sort}
http://<exposed AWS system IP address>/sbls{?page,size,sort}

Some of the screenshots from the APIs are shown below:

One of the instances was showing the X-Application-Context as “equifax-consumer:prod,aws:9001”

Some of the systems were found to be active on September 15th, 2017 as shown below:

We only performed restrictive checks to understand how the API’s interface worked and we were able to obtain the internals on which parameters are used to store the data as shown below:

A sample data blob shows how the APIs are used to retrieve the data.

Observations / Inferences

We made the following inferences based on the information gathered as a part of our research:

1. A third-party securities lending firm’s QA systems hosted on AWS were exposed online that process the credit bureau data.
2. After the data constructs were queried via API, we found that some of the data was not legitimate, as the data looked rogue or vague. However, we did find some valid SSN numbers but they did not match the information in the obtained data. The data dumps (JSON blobs) revealed the entire details on how the data was processed and stored. It was very clear that sensitive information such as SSN, credit card score, etc. were stored in clear text in the database.
3. These QA/test systems highlighted the HTTP response header as “X-Application-Context: equifax-consumer:prod,aws:9001” that showed the traces of a “production instance”. It was not completely clear why these systems were deployed or why they were tagged with the name of the credit bureau’s consumer production instance.
4. The APIs (as discussed earlier) were insecurely designed and following flaws were noticed:

• The APIs were called over non-HTTPS channel. It means QA systems perform the testing and assessment over unencrypted channel.
• The APIs did not have any authentication controls enabled, which means no unique tokens were used to validate the origin of the requests. No HTTP authentication was in place.
• The APIs did not have authorization controls enabled as well. It means any adversary sitting remotely can access the systems from any geographical location on the Internet.
• It was possible for the adversary to interact with these APIs without authentication and authorization that could result in the exfiltration of data from the QA systems.

5. This further raises the questions of the data sharing and handling practices followed by the providers and the third-parties. Consider the following:

• How do credit bureaus share the data with third-party firms such as securities lending companies ?
• What types of security controls are in place for the systems operated by the third-party companies handling customers data ?
• How are the data sharing controls audited by the independent auditors for achieving compliance?

6. Considering the design of APIs, it should be understood how insecurely third-party securities lending firms handle consumer data. The systems can be queried by API interface to dump consumer data. Attackers could have targeted third-party securities lending firms to dump data.

Recommendations

• The QA or critical backend systems should not be exposed on the Internet. This could result in leakage of information about the the network environment including data storage, API design and others.

Consumer should be aware of the fact that scammers can use unverified data dumps to extort money from them. Please be sure not to fall prey to any kind of social engineering tactics adopted by scammers by showing the masked credit bureau data dumps.

• Systems of the securities lending firm should be scrutinized for unauthorized access by analyzing system logs, HTTP logs and other indicators of compromise available on these servers. There could be a possibility other adversaries could have used the exposed information to retrieve data from backend systems.

Responsible Disclosure

As a part of responsible disclosure guidelines, the issue was reported to the credit bureau security team and all details were shared about the systems. The security team of the credit bureau firm confirmed that the QA systems deployed on AWS were not owned by them. Additional tests verified that the systems belonged to one of the securities lending firm based out of Chicago. We contacted the securities lending firm and disclosed all the details to its Chief Compliance Officer. We asked for the feedback ASAP, but after sending additional messages for the feedback to no avail, we decided to go ahead and release the details.

For the first set of verifications tests, the systems were active on 15th September 2017. However, before the release of this blog, another verification test was conducted and it was observed that a few systems were still found to be active on the 8th October, 2017.

Additional Tests

We performed some cross verification tests based on the data extracted during the months of September and October. The data obtained (around 9th October, 2017) from these QA systems such as SSN numbers, credit scores, and other parameters holding sensitive information were found to have been encrypted. This was not the case with the data obtained around 15th September 2017. This could suggest that the credit bureau or securities lending firm has started encrypting sensitive data in the database as part of an enhanced security effort. An example is shown below: