Tag Archives: SSDL

Open Source – The New Attack Vector

There are people who think open source is the holy grail of software,  I am not one of them.  Apparently hackers agree with me.  So does the Department of Defense.  They have even coined a term – SCRM or Supply Chain Risk Management.

Bottom line, developers need to understand that there is a war out there and they are the target.  According to Sonatype, the open source tools and governance company, said that the use of vulnerable open source components is up by 120% over the last 12 months,

Sonatype estimates that there are 1.3 million – yes, million – vulnerabilities in open source software components that are not recorded in the National Vulnerability Database managed by NIST.

Sonatype estimates that the average enterprise downloads 170,000 source components a year of which possibly 1 out of 8 of those have some form of vulnerability.  Sometimes those vulnerabilities get exploited in as little as 3 days.

Developers are still downloading vulnerable versions of Apache Struts (as in Equifax breach).  About 80,000 times every month.

Downloads of a vulnerable version of the Spring Framework was around 85,000 a month last year;  this year it is still 72,000 a month.

To add insult to injury, hackers are starting to inject vulnerabilities directly into some open source packages.  Done cleverly, such a logic bomb might never be discovered.

Point is, still a HUGE problem.

So what do you need to do?

#1 – Admit that open source software is far from bug free – even hugely popular packages like Apache Struts.

#2 – Create a SCRM program.  The larger the open source software package is, the more difficult it is to make sure that it is safe.  

#3 – Consider using automated tools to detect vulnerabilities.  Some of the tools are free and others are very expensive, and all of them change the development process.  Some of them are built into the software tools that developers are already using.

#4 – Create a process for finding out about patch availability.  Unfortunately,  except for the most popular open source packages, they are never patched, so you are pretty much on your own.

#5 – Treat open source packages just like code you develop when it comes to code reviews and testing.  The only difference that you can’t influence the development process.

Information for this post came from The Register.

Facebooktwitterredditlinkedinmailby feather

Secure Software Development Lifecycle Process Still Lacking

In late 2015 Juniper announced that it had found two backdoors in the router and firewall appliances that it sells.  Backdoors are unauthorized ways to get into these systems in a way that bypasses security.  Kind of like going around to the back of the house and finding the kitchen door unlocked when no one is home. Researchers said that there were telltale signs that this was the work of the NSA, although they would never say, of course.  If these backdoors were the work of the intelligence community, lets at least hope it was OUR intelligence community and not the CHINESE.  Whether these backdoors were intentionally installed in the software with the approval of Juniper management at the request (and possibly payment) of the NSA is something we will never know (See article in Wired here).

At the time, Cisco, Juniper’s biggest competitor, said that they were going to look through their code for backdoors too.  They claimed that they did and that they didn’t find any.

Fast forward two years and now the shoe is on the other foot.

Cisco has announced the FOURTH SERIES of backdoors in the last FOUR months in May.  Possibly their code audit from 2015 is still going on, but if so, that would be going on for more than 30 months, which seems like a long time.

The most recent SET of bugs includes three bugs which are rated 10 out of 10 on the government’s CVSS3 severity ranking.

The first of the three is a hardcoded userid and password with administrative permissions.  What could a hacker possibly do with that?

The second provides a way to bypass authentication (AKA “we don’t need no stinkin passwords”) in a component of some Cisco software (DNA Center).

The third is a another way to bypass authentication in some of Cisco’s APIs that programmers use.

In fairness to Cisco, they do have a lot of software.

But to beat Cisco up – WHAT THE HELL WERE THEY THINKING TO ALLOW HARD CODED PASSWORDS IN THE SOFTWARE IN THE FIRST PLACE?

Source: Bleeping Computer

Okay, now that I am done beating up Cisco (actually, not quite, I have one more), what lessons should you learn from this?

First (the last time today that I am going to beat Cisco up), in order for a Cisco customer, who paid a lot of money to get the equipment in the first place, to get these security patches – patches that plug holes that should have never been there in the first place – that customer has to PAY for software maintenance.  If you let the maintenance lapse, you can re-up, but Cisco charges you a penalty for letting it lapse.   For this policy alone, I refuse to recommend Cisco to anyone.

Second, if you are a Cisco user, because of this very user unfriendly policy, you must buy software maintenance and not let it expire.  If you do, you will not be able to get any Cisco security patches.  Remember that, as one of the biggest players in the network equipment space, Cisco is constantly under attack, so the odds of bugs turning up is like 100%.

Third, no matter who’s network equipment you use, you must stay current on patches.  These flaws were being exploited within days and since hackers know that many Cisco customers do not pay for maintenance, those holes, which are now publicly known, will be open forever.

Only half in jest, my next recommendation would be to replace the Cisco equipment.  There are many alternatives, some even free if you have the hardware to run it on.

Okay, that handles the end user.

But there is an even bigger lesson for software developers here.

How did these FOUR sets of back doors get in the software in the first place?

Only one possible answer exists.

A poor or non-existent secure software development lifecycle program (known as an SSDL) inside the company.

AS AN END USER CUSTOMER, WHEN IT COMES TO SECURITY SOFTWARE ESPECIALLY, YOU SHOULD BE ASKING ABOUT THE VENDOR’S SECURE SOFTWARE DEVELOPMENT LIFECYCLE PROGRAM.  

IF YOU GET AN EVASIVE ANSWER, FIND A DIFFERENT VENDOR.  VOTE WITH YOUR CREDIT CARD.

As a developer or developer manager, it is your responsibility to make sure that customers don’t vote with their credit cards.

IMPLEMENT a secure software development lifecycle program.

CREATE and MONITOR security standards.

TEST for conformance with those standards.

EDUCATE then entire development team – from analysts to testers  – about the CRITICALITY of the SSDL process.

Advertisement: we can help you with this.

While Cisco is big enough to weather a storm like this, smaller companies will not be so lucky.  The brand damage could be fatal to the company and all of its employees.

 

 

Facebooktwitterredditlinkedinmailby feather

Software Supply Chain Attacks are Real

For those of you who have been reading my blog for some time, you know that I have written about the software supply chain security problem.  In a nutshell, the problem is that programmers rarely write code from zero anymore.  Instead teams write pieces of code and integrate it.  Then there is limited testing due to time and budget.  Finally, everyone crosses their fingers and the code is released.

The folks at CCleaner discovered the hard way that it doesn’t always work out the way you expected.  Or hoped.

About 6 months ago researchers at Talos (a part of Cisco) and Morphisec discovered that the absurdly popular disk cleaner software CCLEANER had been compromised and was downloading infected software from the official web site and had been doing so for a month.

Worse yet, the code was cryptographically signed, meaning two things.  Most users would trust it and the attack happened from within Ccleaner’s four walls.

Finally more details of the story are coming out; useful for anyone else that writes software, for free or for money, and distributes it to outside parties.  This could be YOU!

2.27 million infected downloads (in just a month) later, Avast, the owner of Ccleaner is spilling the beans.

Not only is this a software supply chain lesson, but it is also a merger and acquisition lesson because this was discovered right after Avast bought Ccleaner from Piriform.

The attackers had stolen credentials and used them to log into Piriform’s London network using the remote desktop software Team Viewer that Piriform used.  From there they infected other computers, only working at night when the computers were likely not used, to avoid detection.

They then installed some malware called Shadowpad, which allowed them, among other things, to log every single keystroke on the infected machines.

Then they waited.  Two months after the acquisition closed, they infected the software inside the fence and waited for the infected software to be signed and uploaded to the web.

The attackers were very smart on top of this.  While 2.27 million infected copies were downloaded and 1.65 million copies asked the control server for instructions, only 40 payloads, representing 11 highly targeted companies, were activated with a second stage.  That is very patient.  To be willing to download over two million copies to only infect 40 very precise targets.  Those targets were in particular tech companies like Cisco .

Information for this post came from Wired.

So what does this mean for you?

First, if you are acquiring a company – or selling one – this could happen to you.  If you are the seller, you could sued for millions.  If you are the buyer you could be on the hook for millions.  It all hinges on the words in the contract.  CONDUCTING SOFTWARE SECURITY DUE DILIGENCE DURING AN ACQUISITION IS VERY IMPORTANT.  This is an example of why.

While this is not an example of downloading an infected library, the library did get infected.  How did the bad guys infect the code and get it checked in to the official library?  How come no review detected the added code that no one officially added?  The SECURE SOFTWARE DEVELOPMENT LIFECYCLE process might have caught this.

Could this have been caught during testing?  Probably.  You would have needed to be watching for where on the Internet that CCleaner was talking to – that it shouldn’t have been.  In fact, since it was trying to talk to Russian and Korea, that could have been an alarm bell since the test network likely should never have tried to do that.  But you have to be looking for it.

How come the attackers were able to compromise Team Viewer in the first place.  My bet is that Piriform was not using two factor authentication.  Bad boys and girls.  I know two factor is not friendly.  Neither is having 2 million infected copies of your software downloaded by your customers.

In the end you need to look at the entire software development process and think like a hacker to decide where he or she could compromise the process.

Obviously, these guys did.

How many other companies are already infected and don’t even know it?  THAT IS WHAT IS SCARY!

Facebooktwitterredditlinkedinmailby feather