Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Offence oriented Defence

6,177 views

Published on

A talk given at the ITWeb Security Summit 2013.

Published in: Technology
  • Be the first to comment

Offence oriented Defence

  1. 1. Offence oriented Defence Dominic White & Jeremy du Bruyn @SensePost
  2. 2. This talk is about … • Understanding how attackers attack – acknowledging the problem – allows more innovative defence • Common defences allow common bypasses – Best practises introduce commonality that is exploited – Common defences lose out over time as attackers adapt • Many “security basics” are honestly hard – knowing the attacks help to prioritise
  3. 3. Why listen to us? • We attack networks and systems as our day (night) job – They’re often quite similar • We care about making them harder to attack • We spend time studying how others attack networks and systems – Other pentesters – Real bad guys (“APT” campaigns) • SensePost has been doing it since 2000 – Possibly more insight into .za infosec practises than any other
  4. 4. How defenders spend • Compliance/GRC – Policies, auditing, responding • Risk Management – Ranking, prioritising, justifying • Best Practises – Passwords, patches, policies • Technology – UTM, WAF, DLP, DAM, SIEM, IPS, AV • Staff – Compliance specialists, risk specialists, security managers, device ops managers
  5. 5. Truth is … • Those defences don’t – Block actual attacks – Move to counter the bypasses used to side-step them • Risk Management – Hard to link risk-based priorities to meaningful technical priorities • Compliance – “teach the test” – Little incentive to create contradictory measurements • Best Practice – We can’t honestly say we know how to defend – Some practises are hard/impossible to do – Common best practises have common bypasses
  6. 6. The Wall • Your defences are a wall • We get to evaluate the wall, figure out how to get over it, and do it – Attackers can often evaluate your defences before getting to you • Once we’ve done it, we have the capability/technique/tool we can do it again, with much less effort – Attackers can keep building their toolchain – Attackers are good at sharing • Defenders now need to build an increasingly huge wall as “the basics” become by-passable with tools
  7. 7. And so … • Popular defensive design patterns lead to popular attack patterns to bypass them – Knowing these can help you avoid or rejigger them • Some stuff has been recommended for decade+, are we really just too lazy? – Let’s just admit that some stuff, will never be done, and come up with a prioritisation strategy that works – Although, you shouldn’t need a pentest/breach to be reminded, design for them
  8. 8. PASSWORDS
  9. 9. Corporate Passwords • Best Practice – Enforce password complexity – Expire them monthly • Belief – Passwords will be more complex & harder to guess/crack – Passwords have a shelf life • Reality: – Users employ coping methods • Password1 or June2013 or Password8 • <Capital><rest of word><number> • Call centre resets to same password every time – Most organisations pick the same policy – Cracking common storage formats is efficient • NTLM / LanMan
  10. 10. Corporate Passwords • Best Practice: Lock an account after X failed login attempts • Belief: People won’t be able to guess passwords • Reality – Lockout period has a timeout, just try one password across all accounts (horizontal brute) • Bonus – Find an Internet-facing auth point & brute there for ext->int win – Executives get exceptions
  11. 11. So what? • Best practises created the vulnerability • Everybody doing the same thing lets attackers optimise • The actual attacks aren’t being looked for
  12. 12. Defend! • Differentiate yourself from the optimised attack – Blacklist common passwords – Enforce length rather than complexity (15+ bonus) – Extend password expiry • Crack your own passwords (or look for duplicate hashes) – Operationalise this as a metric • Monitor for horizontal brutes • Canary accounts • Two factor authentication
  13. 13. MASSPLOITATION
  14. 14. Service/Default Accounts • Best Practice: – Change all vendor supplied/service passwords from the default or disable • Belief: – Requires attackers to guess the password or can’t use the account • Reality: – The rate of developer new app use exceeds security capacity to secure – Complexity across application stack – Belief about network controls/development boxes lead to exceptions
  15. 15. Patching • Best Practice: – Ensure systems are fully patched • Belief: – Known vulnerabilities will not be exploitable • Reality: – Known systems are(?), unknown aren’t – Some software is easier to patch than others – Unknown vulnerabilities & patch window are realities
  16. 16. Baselines & Homogonaity • Best practice: – Ensure all systems are configured the same • Belief: – All systems will have the same security baseline • Reality: – A flaw in one is a flaw in all, Mistakes scale against you – Management agents are remote access methods – Local admin passwords …
  17. 17. So what? • 100% compliance for every piece of software, on every machine, for all time … – You need to do the basics, but let’s admit 100% as impossible – 99% on 1k machines, still gives 10 vuln hosts • Attackers are good at finding the 1% • Attackers care about exploitation, missing language packs not so much
  18. 18. Defend! • Admit you’ll never hit 100% • Use attacker tools/methods to find the 1% – Find the machines your risk/compliance based focus didn’t care about – Scope be damned! • Prioritise based on ease of exploitation – Availability/popularity/stability/ease of exploit • Make hard choices – do you need that software there? • Defence in depth – Check out hardening tools EMET/PAX (grsec) – Have a plan for once exploited
  19. 19. ANTI-ANTI-ANTI-ANTI-VIRUS
  20. 20. Anti-Virus • Best practice: – All systems must make use of Anti-virus to protect against malware • Belief: – Malware/attacks will be blocked – Malicious e-mail will be blocked – We don’t need to follow up if AV said it blocked • Reality: “All of us had missed detecting this malware for two years. That's a spectacular failure for the antivirus industry in general. We were out of our league, in our own game.” Mikko Hypponen
  21. 21. The truth • Mikko was talking about Flame (APT) • Is it that hard? • R600 will buy you access to a great “crypter” – Will make any file undetectable by AV, updated regularly • 20 lines of code to implement my own – Currently bypasses all AV, with a delay & custom file template
  22. 22. Attackers Get to Practise
  23. 23. So what? • You wouldn’t run without it, but guaranteed bypassable • We need to do something, AV is something, do AV • Attackers can test their attacks • Do we just keep building the wall & run all of them? • A lot of money at stake in perpetuating the problem – “I've never seen _single_ report when modern updated AV with all features was bypassed.” Jindrich Kubec Director of Threat Intelligence @ avast!
  24. 24. Defence! • AV isn’t useless, a signature may only be added a year from now, but it’ll tell you, you missed something – investigate • Push your vendor to do better, don’t accept lame signatures, get them to block techniques • Watch the logs, alerts then silent is a bypass pattern • Run multiple AV engines at different layers
  25. 25. LATERAL MOVEMENT
  26. 26. Network Pivoting & DMZs • Best Practice: – Separate your Internet-facing systems into their own network, then only allow connections into the DMZ, not out • Belief: – Contingency plan; even if your Internet-facing servers get hacked, hackers can’t get to your internal network • Reality: – “Lateral movement” is a regular action by so- called APT actors
  27. 27. DMZ – Screw ups • (lame) Web servers in the DMZ, DB in the internal net • Attack – SQLi on the DB (with command exec) gets you onto the internal network • (less lame) Web server & DB in DMZ/s, but on the domain • Attack – Get command exec, get domain account, connect to DC • (least lame) A connection can be initiated to the internal network • Attack – Move around until you can find something you can own, that has access to the internal network – Often not as hard as it sounds
  28. 28. The trouble with tunnels
  29. 29. Trying to explain a real attack …
  30. 30. The toolchain • “Pushing a camel through the eye of a needle” – 2008 BH/Defcon talk by Haroon Meer & Marco Slaviero • Released reDuh by haroon/marco/glenn/ian/gert @sensepost
  31. 31. Defend! • DMZs must disallow connections from being initiated to internal – Check for yourself, plugin and portscan • But, stuff’s not architected to make that easy • Web services provide hope – Expose integration services in the DMZ, have a worker from internal consume it • Other important advice we don’t have time for – Needs separate/disconnected management infrastructure – Don’t share with VPN – fundamentally different purposes – Actually, if you can, stick every machine in it’s own DMZ ala AP isolation – Don’t forget egress filtering & split DNS
  32. 32. Account Pivoting & Escalation • “When in doubt, attack the control plane. When certain, attack the data plane.” -David Ulevitch • Belief: – Centralised user management makes systems more secure. • Reality: – In some ways, yes, but it gives us organisation wide administrative accounts, and it’s easy(ish) to do.
  33. 33. Lateral Movement • Windows is *terrible* at passwords & keeping secrets – Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques • Attackers have gotten really good at post-exploitation • Attacks – Digest auth gives clear-text creds! (wce/mimikatz) – Windows security tokens work well too (incognito) – Still passing-the-hash 16 years later (wce/pth-toolkit) – SMB/NTLM relay attacks (metasploit) – NTLM/LM unsalted, Kerberos can’t do IP, crack away (john/hashcat) – Cached logins (at least they’re salted) • Lateral opportunities – if it works on one … – Local accounts (local admin) – Domain accounts (admin or service) – Apps & Agents (VNC, DBs etc.) – Connected shares
  34. 34. So what? • Good advice is blindly implemented, and the original point missed – DMZs are a great idea, but must not allow connections initiated in low trust network • Advanced protections have well understood bypasses and haven't grown – Tunnelling & windows cred extraction sound hard, but the tools are there • Your exposure is greater than the sum of the parts, you can't look at vulns in isolation, or at entry-only
  35. 35. Defend! • Use specialised/separate DA, server admin & user accounts – Only use the relevant account when required – Limit DAs to login from management network & management jump box (not laptop) • Monitor *all* your AD groups – Administrators, Enterprise Admins, Domain Admins, Shared Trust, Sub-Group inheritance • Beware of the tokens • Check out RODC & Attribute/Account Filters • Read MS’ paper
  36. 36. CONCLUSION
  37. 37. This talk was about … • Understanding how attackers attack – acknowledging the problem – allows more innovative defence • Common defences allow common bypasses – Best practises introduce commonality that is exploited – Common defences lose out over time as attackers adapt • Many “security basics” are honestly hard – knowing the attacks help to prioritise
  38. 38. Questions? research@sensepost.com @sensepost dominic@sensepost.com @singe

×