3 ms·

Source code has issues with obfuscation methodologies that can defeat a lot of techniques. It’s why companies are trying to build more analysis down into the ke

Source code has issues with obfuscation methodologies that can defeat a lot of techniques. It’s why companies are trying to build more analysis down into the kernel such as via EBPF. For example, concatenating a series of strings and characters that wind up reading from .AWS/credentials in the end is surprisingly tough to catch based upon simple pattern recognition alone, especially if it’s done in a subtle way such as with a spare buffer while doing other legit activities. So until the syscall gets issued and all substitutions resolved the user space analysis can be highly resource intensive or inaccurate

jhugo 4y ago
Right, code analysis to try to detect places where it reads from ~/.aws/credentials is never going to be reliable. The correct approach is not to run untrusted code in an environment where it can read your AWS credentials.
- tremon 4y ago
  And if that's infeasible, to not run untrusted code in an environment where it has unfettered outbound access to the Internet.
- devonkim 4y ago
  Another approach is to only run credentials that are ephemeral, which is sort of what most SSO systems will do for cloud IAM. Instance profiles using IDMSv2 work as well, too. However some malware out there only needs a few seconds of dwell time to wreak some serious havoc so even ephemeral credentials may as well be the same as static credentials potentially, especially if your credentials are used to do permanent privilege escalation. All it really can do then is provide a time window of usage and make filtering through a SIEM much more accurate, which is certainly valuable for forensics at the very least and even more important in terms of law (chain of custody, irrefutability, etc).
eszaq 4y ago
How about flagging anything that looks like obfuscated code?
- ykonstant 4y ago
  Apologies if this was not a joke, but just imagining the implications of this made me laugh harder than any comedy I've watched the past few weeks. My... umm... "scientific code" would be flagged in miliseconds :D

jhugo 4y ago

Right, code analysis to try to detect places where it reads from ~/.aws/credentials is never going to be reliable. The correct approach is not to run untrusted code in an environment where it can read your AWS credentials.

tremon 4y ago
And if that's infeasible, to not run untrusted code in an environment where it has unfettered outbound access to the Internet.
devonkim 4y ago
Another approach is to only run credentials that are ephemeral, which is sort of what most SSO systems will do for cloud IAM. Instance profiles using IDMSv2 work as well, too. However some malware out there only needs a few seconds of dwell time to wreak some serious havoc so even ephemeral credentials may as well be the same as static credentials potentially, especially if your credentials are used to do permanent privilege escalation. All it really can do then is provide a time window of usage and make filtering through a SIEM much more accurate, which is certainly valuable for forensics at the very least and even more important in terms of law (chain of custody, irrefutability, etc).

eszaq 4y ago

How about flagging anything that looks like obfuscated code?

ykonstant 4y ago
Apologies if this was not a joke, but just imagining the implications of this made me laugh harder than any comedy I've watched the past few weeks. My... umm... "scientific code" would be flagged in miliseconds :D