Ever feel like a deer-in-headlights? This is Preventing Deer In Headlights. (PDIH)
Commercial: New classes: CASP class in January
PDIH TOPIC: Software Plug-in Supply Chain: How was CAPTCHA attacked?
- Nov. 1st (Thursday) 15:30 CEN.
- 25 minutes
- The link to our live meeting.
- Choose Guest & type your name
- If you would like to test your connection link
How we “purchase” software today is very different. My main concern is not the origin of the software. The problems arise when software developers hand off their software to someone else to maintain after our initial purchase.
I was at a technology conference and the old-timers were complaining that everything is a wordpress site today. I am not too worried about wordpress, but our dependency on third-party plug-ins is out of control. The same may be said about containers and any reusable code.
To be clear: the vendor did the right thing after a security flaw was found. My concern is with our use of these third-party plug-ins that are security-related.
Over 300,000 sites use this particular captcha plug-in. The plug-in was sold to another vendor, who made an update that allowed for a back door into all of the sites. Full administrative access was possible for a week. We are going to break down the attack and discuss what to do about supply chain problems like this.
LINK: backdoor in CAPTCHA
- Maintain the database of software components
- Validate changes in ownership or support
- Maintain previous versions of software in the event that you need to rollback
- Collect security data from many sources and review it regularly
Impact on security?
Our responsibility is security. Individuals who support websites may follow our direction in automatically updating all plug-ins on the site. The problems that we have run into are: blindly updating configurations, trusting third parties, and not reviewing terms of service.
This is what we will talk about on Thursday. Come be a part of cybersecurity. Don’t be a deer-in-headlights.
Can’t make it?
If you are a past student, you will have access to the recordings.
CPEs – Yesssss!
Most CPE requirements have both a validation step and an audit-able requirement. We do both for our past students. Free. You must login. Use this link ONLY if you are a past student who has been given audit-able access. https://www.vmlt.com/mod/url/view.php?id=14166
I hope you attend – it will be fun.
Commercial– CASP starts Saturday January 21, 2019 ; please tell your friends! To see other start dates you can go to: https://www.expandingsecurity.com/calendar/
Andrew K’s response ( POINTS!)
Interesting article you provided. I like how it laid out the process of investigating the code and the businesses behind software. To me, from the take-down notice, to the code installing over itself, to similar software with the same vulnerability from the same company, it all adds up to no good.
As you said the solution is to track your 3rd party software you use and review periodically. Also, limit the number of libraries (attack surface). Along those lines of the attack surface, we also try to use common technologies from larger known companies that we hope (although not a strategy) have more resources to verify the external libraries they use or have the ability to code a similar in-house solution rather than re-bundle it. We also look to use full feature frameworks from one source rather than piecemeal libraries from multiple sources. We develop in the cloud and have setup our continuous integration alongside our code repository. It good to see cloud repositories improve their services and that they think about security. Both GitHub and GitLab have purchased software vulnerability detection software companies, Appcanary and Gemnasium respective. This allows the code and libraries for each build to be scanned before deployment.