Yep, another batch of presentation notes from Black Hat 2016.
Reminder that the slides and whitepapers are here: https://www.blackhat.com/us-16/briefings.html
Hiding malware with certificate bypass
Was at session too late, full.
➔Definitely should check out prez when posted on BH web site, then watch youtube this fall.
Ransomware background / context
Open-source Mlib ML pgm to detect ransomware using micro-behaviours. Spark-based.
Ransomware 1-time cost $200-$10K. $18M loss yearly. Health care providers attacked. Also Utilities.
Monetization expanding: Ransomware As A Service.
Zeus + other exploit kits now have Ransomware as a payload.
Bitcoin / TOR are enabling factors as well.
- Bitcoin provides anonymity in tx. Is possible to trace, but difficult.
- Acceptance high.
- Relative value high
- No international govt controls.
- Can transfer much more $ than pre-paid cards, Moneypak, etc.
TOR + covert SSL communication makes it difficult to difficult to spot infected hosts. Even goes outbound on tcp 443.
ML in security should be looked at as being computer-driven optimization of a manual security workflow.
Express right kinds of inputs in an easy-to-use framework.
Classic exploit chain recognizable by MIME types: eg poisoned Dns domain → Flash exploit → download ransomware payload.
Overall I/P data is reduced to “compressed form” (i.e. ML model) to use for future predictions.
- Model helps separate Signal from Noise
They use Random Forest Classifier.
Moved from MLIB to another library to reduce size of executable.
“Truthing” data (i.e. process of labelling data) is very arduous and long.
They have approx. 60 “behaviours”.
➔Check their github site for reference articles. https://github.com/jzadeh/Aktaion
Concentrated on Exploit Delivery rather than Ransomware behaviours or Exploit kit characteristics:
- Ransomware behaviours: file system specific, OS-specific
- Exploit kits: Depends on post-exploitation agenda.
Tool uses Bro logs. Converts raw log data to sequence of micro behaviours.
Tool runs sliding windows over micro-behav. Data. The resulting data becomes I/P to the ML classifier.
- Interesting sequences of MIME types > 5
- Referrer seq with small interval times
- MIME type distribution for single IP across a time window
- Prob observed (MIME type) to overall population
More powerful than say perimeter firewall since state of problem is isolated using distributed processing. The tool isolates a single flow for given user / IP.
They can fire a PS script for active defense to shut down network for given malware executable.
No time to see this ML tool.
➔Follow up by looking at web (if exists)
1000 ways to die with mobile OAuth
Demos of specific attacks from the wild to illustrate various typical mobile OAuth vuln patterns.
2014: Their research showed that 60% of Android/IOS OAuth implementations done incorrectly.
2016: Looked again. Vulns documented in 2014 still not fixed. Worse, there are now some new attacks previously unknown.
Some root causes:
- Complexity: eg 71 pg threat model OAuth 2.0
- Confusion between AuthN and AuthZ
- Requires coordination between multiple parties to attain gd security
- Flexibility of the standard. Many ways to implement OAuth – some wrong / risky.
OAuth 2.0 has 4 different “grant types” including:
- Implicit grant: no secret, no encryption. Bearer token not bound to relying party. Android’s “Intent Scheme” for Redirect can be overridden by the attacker in the mobile. Attacker can overwrite the Redirect URL.
- For better security, each app is signed by developer key.
Using AuthZ for AuthN → Potential for vulns
If app uses OAuth AuthZ as a means of AuthN, this can give rise to vulns.
Eg Wish, Instagram vulns discovered.
OpenID Connect is the best response to this. Signed JWT. Much more robust. Signed JWT gives authenticity. Std has a call to verify who is the user.
If use straight OAuth 2.0 AuthZ for user AuthN, then this can be vulnerable. Eg Sohu news app with Sina login. App did not verify the AuthZ code.
- Service Provider needs to verify that sender / receiver are both the same person.
- RP should do security checks only on server side.
If the OAuth Consent Page isn’t explicit enough, then user can unwittingly expose himself to attack.
Eg Tencent vuln
Consent Page should specify:
- User name
- User profile image
- Tell user which app is involved
- Describe all permissions
No State token
Eg Github vuln
No state token used to identify login session. User could be tricked with iFrame to give attacker control of his account.
Webview is a Browser that is bundled in mobile app. However the controlling app can get cookies from webview.
Eg Facebook vuln. No current fix.
Super prez with concrete Recommendations
Look at prez when posted on BH web site to see the recommended Mitigations. Not enough time to note them all.
Amazon hacking / defenses
They built their own isolated infrastructure. This is “lessons learned”. Based on Red Team exercise.
AWS security basics
Everything is doable (and should be done in production) from their APIs.
CodeView attack → lost access keys to AWS; attackers shut down AWS which terminated the company.
Sources of infection:
- Infected user PCs, phishing attacks
- People pushing company code to public GitHub, BitBucker
Cloud Metadata (if app hacked which uses API)
Poisoned AMI spun up as public AMI, phishing technique
- Startups close, have rec’d AWS credits.
- Admins resell these accts eg 100K US$ account value for $20K.
- You buy the acct + as a
AWS ECS task definition
- API call to task defn is recorded via CloudTrail
- Contains sensitive information (eg environment variables → keys)
- Docker container → info to CloudTrail → Datadog
- 3rd party service hacked → exposes your data (eg Datadog)
Use STS to generate access token for federation. This token remains valid even if the access key is revoked.
Demo to show this.
Attacker does aws get-session-token with vailidity for 36 hr.
He used AWS Access Key + AWS Secret Access Key (revoked) + (valid) STS key to get access to revoked acct.
- Are limiting factors eg if MFA on the account.
- But lot of things that can be done by attacker.
Another thing is to start an EC2 instance with high permission. Ssh back into this instance and get Production Role. Then get STS token to reconfigure environment.
How to hide
- Delete CloudTrail
- Stop the trails. “stop-logging” Will stop immediately + will not leave trace of why log
- Disable multi-region logging to kill monitoring.
- Attacker sets S3 lifecycle policy to delete files. Only keep 24 hr of logs!
- AWS Lambda
- Triggers on every new file in bucket
- The Lambda free tier ➔ 1M free requests each month. So no bill generated.
AWS Key mgmt. service
- AWS Key Mgmt service
- Integrated with SSE / CloudTrail
- Attacker: sets policy that only CloudTrail can encrypt/decrypt the log files. No one can change the key. So files are all encrypted without possibility of accessing. Key is unmanageable.
- Key can even be disabled / deleted. Then even CloudTrail cannot save files to bucket.
Create new access (typo squat for extra stealth)
Or –iterate all users + create 2cd access keys for every user
AWS Lambda on new user creation to add 2cd access key + post it back to attacker.
Backdoor existing roles
Use new tokens to assume modified roles
Create a lambda that responds to role modification to modify it back.
AWS Lambda Persistency
Lambda to recreate multiple attacker lambdas as described above.
VPC Access Persistency
Use a public endpoint and Lambda to bypass the VPC security groups.
Corporation extends private Intranet to AWS with private VPC.
SQS, AWS Gateway API, AWS S3 (with VPC endpoint)
- All have public endpoiints
- Will spin up a Lambda if called.
Result: Lateral movement back to enterprise Intranet
Very hard to detect – AWS has a lot of moving parts.
Watch CloudTrail implementation.
Stateless architecture with focus on data protection / encryption
Everything in environment should be automated. Can reprovision everything from scratch if breach occurs. Dockers. CloudFormation, etc.
Leverage strong acct separation: DEV,Staging, Production. Even isolate by micro-services.