Hacker News new | ask | show | jobs
by tedivm 14 days ago
Most automated analysis isn't dependent on just behavior, but rather suspicious things in the code itself. You have a popular open source package with files that exist on pypi but not github then that's a big flag, or if a similar package suddenly has some base64encoded garbage that runs through an obfuscated exec call. In other words the simple fact that the project has obfuscated code is enough to flag for further attention.

That said if the only issue is time, researchers will just run their automated analysis through machines with dates in the future alongside their normal tests.

2 comments

A package I maintain once ended up in exactly this state because of a sync script.
Cat and mouse like the sibling says ;) Like if you start changing system time, I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this. Of course I'll run the code that does this through "my obfuscator".

The thing with cat and mouse based on time is that this now became a default. I rather liked my odds when malware authors assumed that the defaults were that dependabot updates right away. If the general consensus online seems to be 7 days, then I'll set my dependabot to wait 10 days, so on average I'll catch even things people report over a weekend. Now that the default is a longer time period, I have to change my time period to be even longer, which actually increases my risk in another way: I'll stay vulnerable to _actual_ vulnerabilities vs. supply chain attacks for longer.

> I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this.

This makes no sense, the system clock would be set before the suspect package is even pulled down. There isn't a "jump" just a reboot and system start at a "totally real" point in time.

And the premise is that this package can evade detection of its suspect code by using an ever-increasing amount of odd code? Yeah, that's a hard strategy.

A cat and mouse game at least raises the bar for the exploit. The status quo requires no attempt at obfuscation at all. It also makes it harder for such an exploit to turn into a worm, since developers have time to notice their credentials have been stolen and pull any malicious packages pushed using them. (and such worms hitting popular packages have so far been how most people have been exposed to this risk).
ok, but your package still contains obfuscated code that we can read