In earlier posts I addressed how individuals can avoid a Podesta-style XSS Hack and insights on hacking, hashes, AWS keys and mobile OAuth, which are applicable to broader audiences. In this post, I'm sharing takeaways more applicable to the IT/Corporate audience.
Tidbit #1: Emulated Environments Used for Malware Detection May Be Ineffective for Evasive Malware
A major front in the cyber security battleground is the dynamic detection of malware using emulated environments. The malware therefore tries to distinguish a real system from an emulator, and behaves well (essentially it hides) when it detects an emulator.
Over 80% of malware since mid-2015 has exhibited evasive behavior. These dynamic anti-virus products can all be defeated by evasive malware: VirusTotal, Kaspersky, AVG, Bitdefender and VirusBlokAda. How does the malware evade detection? Here are a few fingerprints for detecting emulators:
- Hardcoded artifacts/strings such as "computername"
- Operating system don't behave correctly
- Timing skews
- Process introspection, such as uninitialized memory, data left on stack or in registers after function calls, PEB/TEB, DLLs in memory
- CPU redpills - emulated cpus are different from non-emulated
Tidbit #2: How One Company Lost It All to Hackers
Based on a talk at Black Hat 2016 titled: Account jumping, Post Infection Persistency and Lateral Movement in AWS presented by Dan Amiga and Dor Knafo.
Account Jumping is when organizations (often startups) purchase an AWS account from third parties for a discount. When these startups close shopthe leave accounts that have tens of thousands of USDs in AWS credits, which they sell at a large discount on the black market, leaving data exposed on sold accounts.
Tidbit #2a: Surviving Key Rotation or Deletion (as an attacker)The AWS STS (Security Token Service) generates a temporary access token that survives approximately 36 hours past the point when the full key is deleted. After the attacker gains control of the AWS environment, they may plant backdoors to get access later, even after the stolen access token has expired.
- aws sts get-caller-identity
- aws sts get-session-token --duration-seconds 129600; this returns a json formatted Credential with a SessionToken and an AccessKey
Tidbit #3: Be Very Careful of These Two Properties When Using JNDI
Together the following two properties allow for executable code to be uploaded and executed remotely via the Java Naming and Directory Interface (JNDI). These two JVM properties enable remote class loading and execution:
trustURLCodebase = true
Using the relatively new method of JNDI injection, attackers can run arbitrary code on the server by performing JNDI lookups. More on this method in this Black Hat talk by HPE Security Fortify.
Tidbit #4: Avoid HPKP Suicide
HTTP public key pinning is also known as HPKP suicide. HPKP lets you pin a hash of the key that you're serving out for your TLS connections. That way once a person visits your site the first time, it establishes trust on the first use. This is the only key to trust for this server for a specific period of time (for a maximum of 60 days). You can also tack on sub-domains.
The suicide comes in when the server loses control of the pinned key, which remains active for up to 60 days. This may lead to deliberate self-bricking via HPKP + Rapid Key Rotation, and is also known as HPKP Footgun.
HPKP suicide allows in-browser code signing. Someone might also use this method to lock out valid user from a web page and blackmail the page owners. Or it might allow hackers to track users of a particular site.
To see which browsers use hpkp, check out http://caniuse.com/hpkp