O.P.C. Other People’s Code

I write this missive to highlight the need for code reviews of third-party code fragment (OPC), reviews, vulnerability scanning, and operational monitoring.

The last 36 hours have been quite informative and frightening, from both the systems and human perspectives.

To recap:

A social media platform was data scraped, and the published yield is 80+ TB of users data, to include geotagged photos, images of identification cards (front and back), user identification data (email and password in clear and hash), private messages (deleted and live), and public forum data, (deleted and live).

As an operations and security professional, the first few questions in my mind are HOW, WHY, and WHERE?

• HOW did this happen?
• WHY was this so massive?
• WHERE was the breakdown in opsec?

As to HOW this occurred, there are two scenarios being postulated:

Scenario 1:

That the platform in question used a third-party 2fa system, and whence the platform had issues communicating with the 2fa microservice, the authentication system failed “open.”

It appears that the inclusion of client code to work with the third-party 2fa microservice was either improperly configured or less than optimal configuration choices were made.

My thoughts on the above are not suitable for publication.

This allowed access to the platform’s administrative functions and the exposure of data on a massive scale.

Scenario 2:

The inclusion of OPC with a quite simple vulnerability that allowed SQL injection to dump database tables. These dumps included not just SQL data but links to other assets within the platform’s environment.

This allowed exposure of data on a massive scale.

Scenario 3:

A corner case combination of both the above.

Let us just call it, “Poor Application Design and Implementation.”

To review WHY this was so massive:

I will venture that a good program of code review and regular vulnerability scans was not in place. The results of the said program, if in place, were ignored/deprioritized due to business needs.

It is also fairly evident that data transfer metrics were not monitored or the alarms of said metrics were not acted upon.

WHERE was the breakdown in opsec:

The where is almost identical to the why:

• Code security was not considered.
• A program of regular vulnerability scans was not in place.
• Monitoring and alerting for basic operational metrics were not in place.

TAKEAWAYS:

• Do not use some random code just because it works.
• Review all included code for source.
• Include code only from trusted sources.
• Use code review tools on each build
• Regular OWASP / Vulnerability scans are necessary.
• Monitor and alert for administrative logins.
• Monitor and alert for anomalous events.
• Monitor and alert on outbound traffic spikes.
• Review your code sanitization with the development group.
• Review your monitoring with the operations group.

Authors Comments:

From the time before the WWW:

BEFORE Tim Berners-Lee created the world wide web, and in the early days of the internet, there existed a code repository (name redacted). That code repository housed the source to many of the basic tools for the operation of internet services. One of which was a C language compiler.

At some point, a “version” of the said compiler was provided with a testing feature that allowed the access of elevated privileges with a simple authentication method in the resultant code.

Needless to say, this was deployed on several sites.

The “error” was discovered by community review and was removed. Notices were sent to administrators who accessed the code, and the great recompile occurred.

Relevant to today:

With the explosion of open source software, docker images, and repositories, the chance of a poorly written or malicious bit of code has grown exponentially. The use of code review systems is mandatory. A simple google for “open source code review tools” will yield several options.

OWASP vulnerability scanning for www-based systems is mandatory. A google for “OWASP scanner” will yield several options for this as well.

The moral is:

• Code review is crucial.
  • If you can not read it, do not use it.
• Code sanitation is key.
  • If you can not explain it, do not use it.
• Monitoring is necessary.
  • It can alert you to “strange” events.
• Vulnerability scanning is mandatory
  • Do this on a REGULAR basis.