Bcc risk advisory irisscon 2013 - vulnerability management by the numbers and dumb robots!-2
•Download as PPTX, PDF•
0 likes•454 views
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Bcc risk advisory irisscon 2013 - vulnerability management by the numbers and dumb robots!-2
Similar to Bcc risk advisory irisscon 2013 - vulnerability management by the numbers and dumb robots!-2 (20)
More from Eoin Keary
More from Eoin Keary (18)
Bcc risk advisory irisscon 2013 - vulnerability management by the numbers and dumb robots!-2
- 1. Vulnerability Management by the numbers and dumb robots!
- 2. Rahim Jina • Director BCC Risk Advisory • OWASP Contributor • edgescan.com • Ex-Head of Security of Fonality • Ex-Big 4 Consultant Eoin Keary • CTO BCC Risk Advisory • OWASP GLOBAL BOARD MEMBER • Architect edgescan.com
- 3. RISK
- 4. Automation +
- 5. Automation
- 6. Automation
- 7. Fraud – Technical Vulns
- 8. “(Cyber crime is the) second cause of economic crime experienced by the financial services sector” – PwC 2012 Cyber Crime • US $20.7 billion in direct losses • Global $110 billion in direct losses • Global $338 billion + downtime Globally, every second, 18 adults become victims of cybercrime - Symantec “One hundred BILLION dollars” - Dr Evil “The loss of industrial information and intellectual property through cyber espionage constitutes the greatest transfer of wealth in history” - Keith Alexander Almost 1 trillion USD was spent in 2012 protecting against cybercrime “Jimmy, I didn’t click it” – My Grandma “556 million adults across the world have first-hand experience of cybercrime -- more than the entire population of the European Union.”
- 9. Fraud – Logic Vulns “40% of applications tested by BCC Risk Advisory in the last 12 months had a critical business logic vulnerability”
- 10. Example 1 – Loan Calculator & Approval
- 11. Example 1 – Loan Calculator & Approval
- 12. Example 2 – Coupon Abuse Stacking Trust the Machine DISC10
- 13. Example 2 – Coupon Stacking 90%
- 14. Example 3 – Flight Booking
- 15. Example 3 – Flight Booking
- 16. Example 4 – e-Auction
- 17. Example 4 – e-Auction
- 18. Example 5 – e-Dating
- 19. Example 5 – e-Dating
- 20. What’s your point? • Robots don’t understand true love • SIMPLE • COMMON • LEGALITIES
- 21. Really, what’s your point? • There is no big button • Automation helps but is only part of the solution • Continuous testing & assessment • Pure blackbox tests are dumb • Onion Approach
- 22. “We need an Onion” SDL Design review Threat Modeling Code review/SAST Negative use/abuse cases/Fuzzing/DAST Live/ Continuous/Frequent monitoring / Testing Ongoing Manual Validation Vulnerability management & Priority Dependency Management …. Robots are good at detecting known unknowns Humans are good at detecting unknown unknowns
- 23. Thanks for Listening Some websites were harmed during the making of this presentation rahim@bccriskadvisory.com www.bccriskadvisory.com © BCC Risk Advisory Ltd 2013. All rights reserved.
Editor's Notes
- Edgescan – Saas product – hybrid automated & manual testing solution for apps and network
- Risk is contextual Security is about managing risk Kinder eggs banned in the US (danger to small kids) Guns legal CONTEXT IS KEY More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. Schneier, Bruce.
- What do we mean by automation? Scanners Bots, spiders Firewalls, WAF’s Correlation engines SIEM
- Automation (application security) doesn’t understand context, therefore cant be relied upon to make risk judgments (sqli example) Automation does not equal security Automation alone should not be relied upon for security Automation is used a lot for compliance but compliance does not necessarily equal security
- Automation gone awry – Missing context. A fool with a tool.... Automation is dumb and requires a driver Consultant “tune tools” Use multiple tools – verify issues Customize Attack Vectors to technology stack Achieve 80-90 application functionality coverage Comes down to experience of the driver and not so much the tool OSSTMM The Open Source Security Testing Methodology Manual 1. tools don’t know when they lie, 2. tools are only as smart as their designers 3. tools can only work properly within the confines of the environment they were made for.
- Fraud and Application Security Vulnerabilities We’ve heard about about xss, sqli, csrf, buffer overflows, injection attacks, etc Technical vulns – Weakness resulting from broken or missing security control (authentication, input validation, access control) We do get fraud occurring using these types of vulns, however not every vuln of these types can be exploited to commit financial fraud. Vuln does not equal fraud – its an avenue (but it’s a start and it helps). Not a 1=1 relationship. Turning a vuln into an exploit is not trivial and to do this without being found, triggering some kind of warning or alarm is also hard. Automation is good at finding these types of issues – downwards trend
- [Not talking about countries or cyber warfare or espionage] Business logic vulns – ways of using the legitimate processing flow of an app in some way that results in negative consequence to the organization. Fraud committed by abusing business logic, authorization issues (mention authorization as a special case) Applications are designed to mirror a business process – do what they are meant to do but don’t always do what they are not meant to do. Don’t mean to bash developers (pressure). Apps designed to fulfil a set of desirable functions, not generally designed not to fulfil a set of undesirable functions Logical state machines – States, transition between states (input/output). Applications have inherent vulns which are logical in nature – these are not technical vulnerabilities Cant be detected by automation (or automation alone) -> cant understand the business context. Csrf example. (tools can be customised, but this has to happen for each application – not practical).
- Purpose: Loan Calculator & approval application Vulnerability: Business logic flaw, through parameter manipulation & authorisation Change interest rate Change loan term Amount - : [Alter the risk rating for the applicant] EASY Automated tools cannot know what parameters are used by the business process
- Exposure/Result: Financial fraud EUR20,000 loan at 0.5% over 75 years. This system was also being designed to automatically approve applications – up to internal audit or chance to catch with large number of applications. Mitigation: Technical controls good – input validation, output encoding. Variables need to be more than type safe (looking for int/string) - Validation of the business process.
- Purpose: Applying coupon codes | Showing coupons in a retail environment Vulnerability: Applying the same coupon code multiple times | Coupon stored on local device Also DISC10 Automation/Scanners cant find these vulns!
- Exposure/Result: Adding more than one coupon for discount code | MAKE UP YOUR OWN COUPON Petty theft – coupons used EVERYWHERE Mitigation: More logic – Use and abuse cases. One coupon per session. More distinct. | Some kind of code (QR codes) & out of band verification. Anti-tampering hash/integrity check (use some crypto)
- Purpose: Book flights Vulnerability: JUST USE THE APP Book a seat Seat is held before actually paying Too long, times out and you have to restart SCRIPT! Book the plane – know the type of plane, what seats.
- Exposure/Result: - Private jet -DoS (business) Artificially inflate price (competitors?) DISRUPTION TO BUSINESS RESULTING IN REAL FINANCIAL LOSS Is this fraud? Gray area…. Mitigation: -Difficult – complex IP/session locks (nat etc) Captcha would help (captcha is not security) - Countdown (ticketmaster)
- Purpose: Any e-auction. Auctioning any goods, tickets, electronic goods, books, etc. Vulnerability: While bidding, noticed the username of the ‘other bidder’ App had account lockout Wait until last few minutes Lock out the bidders
- Exposure/Result: Get the gold! Whats the fun in bidder against people. Mitigation: User ids – predictable, usernames different than screennames - Captcha on login (not security! – can be defeated by OCR tools)
- Purpose:e-dating Search for interesting people, talk to them. Vulnerability: Search function meta-data. TOO MUCH META DATA
- Exposure/Result: This was where they had last logged in from. Monitor regularly to track movements, houses, etc. Mitigation: Here to update peoples location in the app, although it was ‘scrubbed’ when viewing the app, devs left this data accessible. - May have been test/dev data left in by accident. Easy – DON’T SEND THIS DATA - Scrub this data.
- Simple: Agree that these are easy? No tools required – just a brain! Common: Finding more issues like these Legal: Is this really hacking? After all - Just using the application and the data presented to us. Court? Just using the app against itself.
- Not an easy problem to solve – approach from several directions Automation really helps, but really depends on the driver (car analogy). Coverage – much better at finding tech vulns Code constantly changing. Attackers already have a time edge on a live application – might as well try to even the field with better than zero knowledge testing. Pure blackbox: youre testing the tester, not necessarily the application. Manual validation of issues here is key (no more 100 page scanner reports handed to developers to fix issues that don’t exist or have no business risk)
- If you don’t understand the business, you cant see the flaws in the business logic
- Lighthearted look at appsec