4 ms·
How would you deal with malicious packages that randomize or time delay their malicious behavior? Say you have a package that only triggers the evil activity o
by koolba 4y ago
How would you deal with malicious packages that randomize or time delay their malicious behavior?
Say you have a package that only triggers the evil activity one out of 10,000 evaluations? It'd have a 99.99% of passing validation but could still wreak havoc on a heavily used client side application.
Ditto for a package that simply delays it's malicious payload until some point in the future, after the scan has occurred? I guess this is a bit easier to test for by future dating the system clock, but again what if it's a random window? (e.g. every other day for five minutes, at 4:59pm UTC).
- ashishbijlani 4y agoYou're right; a sophisticated bad actor can employ time- or event-based hiding techniques. However, these limitations apply to dynamic/runtime analysis only. Packj performs static+dynamic+metadata analysis. As static analysis scans every line, it will flag use of risky APIs (e.g., file delete, net send, process fork) regardless of when they are being invoked at runtime. Having said that, obfuscated code (e.g., base64 encoded) or runtime payloads (e.g., downloaded from pastebin) will not be analyzed with static analysis, but it will tell you if the recent package version uses base64 or exec APIs in the code (file/line) for you to take a deeper look. We've some ideas on runtime lightweight sandboxing, and will eventually implement those.