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?

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


  1. Maintain the database of software components
  2. Validate changes in ownership or support
  3. Maintain previous versions of software in the event that you need to rollback
  4. 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.

CommercialCASP starts Saturday January 21, 2019 ; please tell your friends! To see other start dates you can go to:


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.

This article has made think how many companies produce software in a responsible way. This article reminded me of what my team currently does with our mobile apps.  The download of WordPress updates via WordPress struck me similar to Apple’s app store.  In the article’s use case, WordPress site was circumvented for updates.  We can technically do the same with Apple’s app store by using a library provided by a Microsoft library called Code Push. (https://docs.microsoft.com/en-us/appcenter/distribution/codepush/)  As a developer, I hate the Apple app store and having to wait up to possibly 3 days to publish a critical bug fix and the hoops Apple make developers jump through.  With Code Push, any JavaScript, HTML, or CSS change can be pushed to all mobile apps instantly. Although this is done in a more transparent way with intent to provide better customer support, it is not all that different from the article’s use case.  Another library we use is LogRocket.  https://logrocket.com/  It records user’s sessions and usage of the mobile app.  Once again with the intent to solve customer support issues but this too could be abused.  Both Code Push and LogRocket require online accounts to administer so their respective companies have access to my company’s app usage and so does Apple and Google via their stores.

Categories: Learning