Your SlideShare is downloading. ×
0
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Offence oriented Defence
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Offence oriented Defence

5,332

Published on

A talk given at the ITWeb Security Summit 2013.

A talk given at the ITWeb Security Summit 2013.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,332
On Slideshare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • H highlighted the risk that pentesters stop emulating bad guys, and start emulating other pentesters. We agreed. Helpfully, the amount of campaign analysis available today means we can study real attacker methods in ways we couldn’t before, and it turns out, they do a lot of the same things we find ourselves doing when faced with the same constraints. Different tools maybe, but similar tactics.
  • Risk management e.g. if we take a log monitoring box, is it obvious that that provides access to critical system x
  • The conclusion here, is we need something more than just building the wall. And Lockheed showed us with the kill chain, that investigation-lead based on understanding of actual attacks, can give you that.
  • e.g. anti-virus or ASLRAttackers keep building their toolchain (ref H in pushing a camel through the eye of a needle)Defenders “we need to do something, x is something, let’s do x”When attackers encounter something new, they need to spend time to figure it out and bypass it, this looks like alert, alert, nothing. Assuming stuff is blocked, is the wrong approach.Obscure defences, specific to your org or use, are less likely to have been seen before, and will generate a detection, a detection can be turned into an investigation if you move up and down the process, knowing it.
  • Highlight upcoming examples
  • Attackers know the coping methods, study passwords, and optimise.Example of phoning call centre and asking what they reset your account to.
  • Thing to stop bruting, doesn’t stop bruting.Citrix, OWA, any ad-auth point
  • Passwords longer than 15 can’t be cracked by hashcat, and LM is disabled
  • We call this massploitation, because we have scripts to take advantage of the risks we highlight, to automatically pwn as many boxes as we can. At one stage, we have 40k meterpreter sessions.
  • Remind people of the subtelty here. We’re not saying you can pwn through missing patched, we’re saying everyone knows that, but we’ve never stopped it, so why do we keep pursuing the impossibleMaybe you remember to do sql, but wahat about tomcat/hp management/axis2/postgres/mysql/firebird/etc. etc.
  • Result: passwords are left to defaults, blank or just fuggin easy. Maybe you remember to do sql, but wahat about tomcat/hp management/axis2/postgres/mysql/firebird/etc. etc.
  • Management agents; splunk, intel, hp system management, nagios
  • A flaw in one, is a flaw in all.
  • Remind people of the subtelty here. We’re not saying you can pwn through missing patched, we’re saying everyone knows that, but we’ve never stopped it, so why do we keep pursuing the impossible
  • Hard choices – all software comes at a cost, if you aren’t actively managing it (cost), then it’s making you vulnerable (cost)
  • You don’t have to test your payloads on a live client, test them against their AV before you get there. Attackers can test climbing the wall.
  • The problem is, people aren’t disciplined in how they build their DMZs, it’s also honestly hard
  • Dominic made this, not Panda. If you see this attributed to panda, it’s because he is a plagariser.
  • Hope someone gets the Star Trek reference. The trouble with tribbles was an episode of Star Trek in 1967. They bring a tribble (a small furry alien that purrs) onto the ship, they soon multiply exponentially and infiltrate all the ships systems.
  • HBGary referred to reDUH as “insidious”.There are many ways to skin this cat, and it can get pretty sneaky e.g. timingDNS exfil used to be niche (e.g. squeeza) not it’s everywhere sqlmap, sqlninja, metasploit, iodine
  • As pentesters, we’re timebound more than any other constraint, so we go for the control plane. Going for the data/app plane requires more business knowledge. But I know IT and I know IT people need a way to manage lots of boxes. If I crack that, I can get access to anything else, it’s just a matter of time.
  • Info leakage findings are lame, except the domain gives you *so much* of it. It makes it too easy for finding admins. Mention Etienne’s PsLoggedOn
  • Microsoft published a doc about defending againstpth attacks this yearTruthfully,unix suffers from similar flaws at scale – ssh keys, world readable config files, bash history. It’s just that AD is the default paradigm for this stuff.
  • Two points here. The obvious is, maybe someone should build it. But the other is that you could likely automate this and win in most cases. Some of it has been done before e.g. conficker (ms08-067 & creds). We send juniors in for internals a lot of the time, because we know they can pwn these things.
  • Cargo-cult DMZ implementations
  • We need a way to clear all tokens (of logged out users?). The group thing is a big one. It’s easy to hide an admin account 5 group levels down. Or hide it in Administrators which is where Domain Admins inherits its status from.
  • If you walk away thinking any of these attacks are novel, then you’ve missed the point. These attacks are so common/well understood that they are second nature to an attacker. We need novel ways of defending.Understand Passwords -> horiz brute, monitor for itMassploitation -> prioritise the ones you find with stable/easy exploitable vulns AV -> know what you get, don’t blindly trust it Lateral -> Attack result is greater than the sum of it’s parts
  • Transcript

    • 1. Offence oriented Defence Dominic White & Jeremy du Bruyn @SensePost
    • 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. 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. 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. 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. 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. 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. PASSWORDS
    • 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. 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. So what? • Best practises created the vulnerability • Everybody doing the same thing lets attackers optimise • The actual attacks aren’t being looked for
    • 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. MASSPLOITATION
    • 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. 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. 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. 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. 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. ANTI-ANTI-ANTI-ANTI-VIRUS
    • 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. 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. Attackers Get to Practise
    • 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. 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. LATERAL MOVEMENT
    • 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. 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. The trouble with tunnels
    • 29. Trying to explain a real attack …
    • 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. 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. 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. 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. 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. 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. CONCLUSION
    • 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. Questions? research@sensepost.com @sensepost dominic@sensepost.com @singe

    ×