Millions of Vectors – Github and it's Supply chain issue

Welcome all my supply chain aficionados! Today we are going to tackle an oft ignored security vector...its ignored mostly because everyone thinks everyone else is doing security and "we don't have to waste money verifying this code, Github spends millions of dollars on security and we are totally, 100% safe!".

Buahahahahahahahahahajajajajajaja!!!!

Well, sadly I wish that were true. Both the thought of spending millions of dollars on security (they do, but most of this money is securing, monitoring, and responding to security events on their Ops Landscape, and checking code for any vulnerabilities will only be as good as the coder who knows enough to script something to find those instances.  Mind you, larger events like the Log4j supply chain event will be broadcast on all media and will only be overlooked if the SoC (Security Operations Center) Analyst is dong this as a night job until their music career takes off.

Supply chain vectors are also ignored as it takes true understanding of the landscape and supporting code to do this efficiently in enterprises...all this would benefit greatly by well documented code and....well...yeah.  Lets not go there as we all know that in this race to save a few pennies we rarely have time to document things as they should.

Well, lets define what a supply chain attack is before we go any further...were on the 4th paragraph already and I am assuming everyone knows what we are talking about. The entirety of any written program you interact with today, be it web based app or hard coded app, are built like a a Lego structure.  Not the small $9.99 Lego sets, but the massive $299.95 (the extra four cents is what really makes this deal!)...and just like Lego sets, you can build structures that will be used to make the whole structure. In simpler terms...

Legos give you the brick...but one can use the bricks to build a wall and now instead of having to build a wall (brick by brick) every time, you can just take the prebuilt wall and copy and paste your way to programmer heaven! So lets take this fictional wall we have built with Lego bricks, and someone wants to build a Lego wall template with a window...they can build off the original wall, and then add their window...this is called a fork! A fork is when one programmer takes the main branch of code and creates a fork in the road as it were, and makes a variant of the original code.  Some of these forked codes, will contain outdated code from the time it was forked.

So imagine if one of the bricks used in the original wall, and one specific brick would melt in rainwater...Well, then we might have built thousands of Lego homes, all with the same vulnerability...the one faulty brick which will melt the next rainy day.

That in a nutshell is a supply chain attack...where an often forked piece of code is found to have a zero day vulnerability that is not known to the final builder of the app...so a programmer with the best of intentions might accidentally allow for the problematic code to be delivered to their users.  Imagine I am a bad guy (/puts on my evil mustache)...and I fork some code for a wall and add a pretty window with green lasers shooting out of it and plays "Tequila" whenever one opens the window, but it also has a bit of malicious code in it...lets say, it allows anyone who knows where to look access to the Lego house...

Why are we talking about this today? Well, Github...arguably one of the biggest if not the biggest code repository in the world, has been dealing with supply chain attacks after being targeted by bad actors worldwide. For years security researchers have been theorizing which forked code will be next and finding supply chain abusing bad actors out there.  The most well known one is/was the log4j event...log4j being a very much used/forked piece of code that 150% of the internet runs on (don't ask me where the extra 50% came from, just roll with it)...

According to the mainstream news, Github has hundreds of thousands of repos which are trojan horses and hold malicious code. According to the darknet sources, there are millions of infected repos. Either way, there are way too many repos that are infected and the chance you might accidentally stumble across one if higher than it should be!

How do we protect against this? Ohhhh, this is more of a collection of things to do, vs simply buying a tool, or running a script...

Step 1: Document your code! Nothing helps this process more than proper documentation.  Not only that, have a separate manifest of all forked code for easy reference, or create a Microsoft Loop (this is really cool if you haven't used it yet, go check it out!)..this way, all the forked code is easily identifiable and you can search when something comes up on CVE/CVSS/NVD database.  Most people refer to this as a CVSS Score. If you have a separate manifest for all your included forked code, it will make it easier to identify if a high scoring CVSS vulnerability is something for the enterprise to worry about.

Documenting your code and having a separate manifest for all your referenced code should be part of your SDLC...if its not, please remediate immediately as documentation should be baked into every single line of code!

Step 2: Check against the NVD (National Vulnerability Database) every month (at least!) for the latest and the greatest vulnerability (CVE) with a score (CVSS).  As a general rule, anything above a 7 should be looked at within short order and anything above a 9 should be looked at immediately! Drop that sandwich and call your favorite pizza delivery as it will be a late night!

Step 3: Set up your firewalls in a way that only allows for the specific traffic needed to run the service.  Yes I know its a pain.  Yes I know its such a downer.  I have heard all the excuses before, and yes, we still have to set this up correctly.  Too many people just open up their firewalls and allow so much traffic to pass because they don't want to map their systems and set up the firewall correctly, but I have been saved dozens of times in my life by having a properly set up firewall...malicious code can't work on port 456 if its blocked.  Also remember that a firewall can be on the server itself or inline in the network...

Step 4: Set up your DNS and block known bad actor address lists and point any known bad address to something else...like ProzessTecs Blog site: Blogs - News & Update | ProzessTec For instance!

Step 5: Set up your Endpoint Protection Manager to block known bad actor address from an endpoint perspective.

There are a few more things we can do to minimize your exposure to malicious code, but those 5 should get you started. As a general rule, if you can't get rid of it, cripple it so it can't be used.  Take that paradigm, and apply to more than one layer in your defense strategy!

That's all for now! Hopefully your coffee stays lukewarm and your laptop always has battery!

Contact Us to learn more!