What Caused the SBA Flaw that Exposed Business Owners’ Personal Info?

Current events are reshaping the way we live our everyday lives, and taking a heavy toll on the business world, with organizations of all sizes feeling financial disruption. Business continuity is more essential than ever during the pandemic; not just for customers who rely on products and services, but also for companies that need to keep funds flowing.

This has, foreseeably, led to thousands of loan applications for the Small Business Administration (SBA) in the United States, placing an overwhelming demand on the Economic Injury Disaster Loan Emergency (EIDL) program. The program currently provides up to $10,000 in financial assistance to small businesses suffering financial loss from the pandemic, but has unfortunately come with a security risk for some applicants seeking loans in order to maintain their business health.

During the recent influx of loan applications, the SBA acknowledged that the personal information of nearly 8,000 business owners might have been exposed to others accessing the program online. The flaw in the program simply required a user to hit the “back” button while in the loan application portal, which in some cases may have shown sensitive information belonging to another applicant.

Possible causes of the SBA flaw

While we can’t be certain which flaw is plaguing the SBA loan application system, we can make an educated guess based on similar behavior we’ve seen. Jamie Rougvie, a member of Veracode’s Manual Penetration Testing team, believes this flaw may be a combination of redirects and access control misconfigurations. Here is how this flaw may have impacted the SBA loan application process:

The Flaw

A company signs up to the loan portal and is given a unique Identity relating to that loan. Let’s say ‘Company A’ signs up and gets a LoanID of 1. ‘Company A’ then signs into the application and starts to fill in the application form. They then notice that they made a mistake on the previous page, so they click the back button within the application.

This back button then redirects them to the previous page. Now, let’s assume the code behind the button redirects them to the following URL: 

https://www.URL.com/application?LoanID=2 

(it should be noted that on the Loan site this would be a more complex than a hard coded URL). We would assume that the value may be coming from a variable which is being dynamically changed based on a number of factors.

 

You can see here the LoanID has changed from 1 to 2. This means that instead of showing ‘Company A’ data, it will attempt to show the data of LoanID 2 which is ‘Company B.’

What should happen here is when ‘Company A’ is redirected, a check should be done to make sure they have permission to access the page that they are being redirected to. If they have permissions to access the page, the redirect occurs. If they do not have permissions to access the page, either an error is displayed, or they are redirected elsewhere.

It seems like in this case no checks were performed on the request, and as such “Company B’s” data was displayed to “Company A” – meaning sensitive PII information was leaked on the webpage.

It’s not clear if “Company A” only had access to “Company B’s” data, or if this data changed each time a new request was made via the back button. This would mean that each time the back button was pressed, another company’s data would be leaked to a standard user. If an attacker found this type of flaw, they could within a small amount of time be able to obtain PII information of all companies in the loan application.     

The seriousness of this issue depends on the type of application, and the information that is disclosed via the vulnerability. “In an application like a loan website where the vast amount of information would be sensitive, this would be a critical severity issue and we would jump on call with the customer straight away to discuss the problem,” Jamie further explains.

The SBA loan application issue potentially exposes sensitive information like an applicant’s name, Social Security Number, tax identification number, address, date of birth, financial insurance information, and more – which means a threat actor could then take that information and use it in any number of additional threats, like social engineering attacks or potential identity theft.

That’s why it’s important to stay one step ahead. Situations that entail building applications or websites quickly to amplify communication and provide services are not unique to current events; they should always involve security measures like regular scans and testing procedures. “When you combine the power of Veracode automation tools and our MPT (Manual Penetration Testing) services, these types of issues can be identified early on and can be mitigated before pushing the application into production,” Jamie explains.

Being proactive instead of reactive will set your organization up for preventative security measures so that you’re not faced with the cleanup that comes from worrisome vulnerabilities like IDOR and Session Management flaws.

Reducing risk with healthy AppSec

Cyberattacks and security threats are on the rise, which only amplifies vulnerabilities like the one we saw from the SBA in early April. Ultimately, this combination of rapid digital acceleration, and an uptick in cyberattacks, has left many organizations vulnerable. This situation stems in part from organizations adopting reactive, rather than preventative, security strategies.

What does preventative AppSec look like? Companies that are concerned about the health of their applications should scan early and scan often to identify problems before an issue arises. The mentality of shifting security left, bringing it into the development process sooner rather than later, can save money and time down the road. It helps eliminate security debt, too, which piles up over time and is carried as a constant risk from project to project.  

Data from our 10^th annual State of Software Security Report (SOSS) shows that when organizations scan their code frequently (more than 300 times a year), they carry five times less security debt than those that scan the least.

Having a suite of SaaS solutions in the cloud to scan application code is essential for remote teams, but even more so today with entire companies going digital. Veracode’s application security solution combines five analysis types in one for a comprehensive look at your code as developers work. Every step of the way in the software development cycle (SDLC) – from the IDE to production – these scans ensure that your team is working smartly and efficiently to produce secure applications and stay ahead of potential issues.

And with hands-on training tools like Security Labs, developers are better equipped to write secure code, saving their organization from needing to remediate flaws down the road. Using Security Labs, software developers can exploit and fix an application in a contained environment with fast feedback, helping them learn in the languages that they need to know inside and out. Not only does it help developers satisfy compliance requirements, but also, they walk away with the training and skills needed to write more secure code and remediate flaws faster.

You don’t have to compromise between the race for swift deployment and the need for better application security. With the right tools and training, your organization and your team of developers will be well-equipped to handle what comes next as more of the world continues to take on a digital transformation and new security threats emerge.