Tag: supply-chain

By Posted on Posted in all No Comments

Lately I've been talking a lot about the supply chain risk. You import some software, and are suddenly importing their business model and practices. Well, we've just had another 'shenanigan' unveiled. And its got some good drama. https://github.com/dominictarr/event-stream/issues/116

In a nutshell there is some package which is relatively stable. The original developer doesn't use it anymore, its stagnant, but people are still using it. Someone comes alone, offers to take over the maintaining, its handed off.

The new dev makes a quick minor fix, updates the package. And then... makes some evil changes, pushes them on top of that version and then hides it.

And now all your bitcoin are belong to unknown dev #2.

And lots of things are broken. One person in the thread (perhaps a troll) is complaining because he has some software which has pinned the dependency to the bad version, and now won't build in their CI.

Millions of people have installed this software, somewhere, everywhere, no real way to say.

Since there is no signing, we can't say what was in github when it was published, or if it came from github or elsewhere, so the source is murky. There's some encryption, some patching of dependencies. You could have this and not know. You can't trust the 'npm ls' to show the truth.

So this brings up the question of open source governance. A strong project that is hard to breach has multiple maintainers, who are unrelated to each other, and who it takes more than one of reviewing a commit to get it approved. Is this something you look for when you choose your immediate upstreams? Do your upstreams look for this? Do their upstreams? And so on. The tree is both deep and wide.

Red team only has to get it right once, blue team needs to be right 100% of the time.

Commence worrying in 3...2...1.

Tagged with: , ,

By Posted on Posted in all 2 Comments

So most of you will have the Slovak 'NBU' on your RSS speed-dial, but I found I was a bit behind on my reading of it. As I was catching up, skcsirt-sa-20170909-pypi caught my eye. In a nutshell, its around a phenomena called 'typo-squatting'. In this case, Python-package name squatting (called pytosquatting).

So there is a popular package 'urllib2'. The developers moved on to version 3 (urllib3), deleting the old one. Someone moved in and registered 'urllib' and 'urrlib2'. In turn other unwitting people like you and I would do a 'pip install urllib' or 'import urrlib'. Done, right? Wrong! It behaved properly (so you didn't notice) and then... well... had side-affects you didn't want. Other typos included 'urlib3' (dropped 'l') etc.

Here's a few they highlighted.

  • acqusition (uploaded 2017-06-03 01:58:01, impersonates acquisition)
  • apidev-coop (uploaded 2017-06-03 05:16:08, impersonates apidev-coop_cms)
  • bzip (uploaded 2017-06-04 07:08:05, impersonates bz2file)
  • crypt (uploaded 2017-06-03 08:03:14, impersonates crypto)
  • django-server (uploaded 2017-06-02 08:22:23, impersonates django-server-guardian-api)
  • pwd (uploaded 2017-06-02 13:12:33, impersonates pwdhash)
  • setup-tools (uploaded 2017-06-02 08:54:44, impersonates setuptools)
  • telnet (uploaded 2017-06-02 15:35:05, impersonates telnetsrvlib)
  • urlib3 (uploaded 2017-06-02 07:09:29, impersonates urllib3)
  • urllib (uploaded 2017-06-02 07:03:37, impersonates urllib3)
Tagged with: , , ,

By Posted on Posted in all No Comments

 

It finally happened to you. A developer used 'import A'. A pulled in B, B pulled in C, D. D pulled in E... and somewhere along that chain evil lurked. Now all your bits are belong to l33t hackerz.

So like all things in life its time to over-react after the fact (something about a barn door and a horse).

And like all good things in life research ~= google. So you do. And you find... shocking... a set of tools. Sadly language specific, but lets not be greedy.

What these tools do is glom onto your git repo and snoop around. They find a 'requirements.txt' etc, parse it. Then they go find those packages, parse them, and so on. A tree is built. And then they watch the vulnerability stream of those upstreams for you. Some even conveniently issue a Pull-Request to your repo when they find an issue for you!

And cuz its (nearly 2019), they all have an API, a freemium business model, and some 'open-ish' source on Github.

But, tl;dr: if you are waiting for bad things to happen to good software in production as a means of knowing you have a security issue, maybe you should look at moving it upstream with some auto-security-dependency-tracking. You can maybe merge this with your SAST platform (like Clair).

Tagged with: , , ,