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.

Risk Analysis Of Banking Malware Attacks


Published on

Analysis of How Banking Malware Like Zeus Exploit Weakenesses In On-Line Banking Applications and Security Controls. This prezo is a walkthrough the attack scenarion, the attack vectors, the vulnerability exploits and the techniques to model the threats so that countermeasures can be identified

Published in: Education
  • Be the first to comment

Risk Analysis Of Banking Malware Attacks

  1. 1. Threat Modeling of Banking Malware-Based Attacks Marco Morana (OWASP Cincinnati) & Tony Ucedavelez (OWASP Atlanta/Versprite Inc)OWASPAppSec EU,June 10th 2011Trinity College Copyright 2011© The OWASP Foundation Permission is granted to copy, distribute and/or modify this documentDublin Ireland under the terms of the OWASP License. The OWASP Foundation
  2. 2. Agenda For Today’s PresentationPART I: Threat Scenario of Hacking and MalwarePART II: Presenting The PASTA™ Risk Based ThreatModeling MethodologyPART III: Use of PASTA™ for the analysis of threats,attacks and the managing of risks posed bybanking-malware OWASP 2
  3. 3. PART I – Malware and Hacking: The Threat Scenario OWASP 3
  4. 4. The Threat Landscape The threat landscape of cyber attacks has changed dramatically in the last ten years:  Attackers are now financially motivated examples include theft of credit card data for sale, fraud of bank accounts  Attackers are part of organized crime that includes gangs of fraudsters, corporate spies, cyber-terrorist groups  Attackers are targeting financial businesses because is where the money is SOURCE: Cisco: Threat Control and Containment: New Strategies For A Changed Threat Landscape OWASP 4
  5. 5. Hacking and Malware Threats Stats Are the most common threat actions for 2010 data breaches Include the top three attack vectors Source: Verizon Data Breach investigation Report: OWASP 5
  6. 6. Hacking and Malware Attack Paths & Targets Web applications are the attack path sought for the highest percentage of data records breached The top 5 types of data sought by attackers are credit card and authentication data Source: Verizon Data Breach investigation Report: OWASP 6
  7. 7. The Threat Actors Behind Hacking & MalwareSource: Verizon Data Breach investigation Report: & Doing Time A Blog about Cyber Crime and related Justice issues: OWASP 7
  8. 8. The New vs. the Old or Dr Jerkill/Mr Hydevs. Sherlock Holmes OWASP 8
  9. 9. Lesson #1 From Business Risk Management: IKnow it By I Ignore it OWASP
  10. 10. Lesson #2: Act By Fear, Doubt, Uncertainty Fear of failing audit/non compliance => additional fines, restrictions and controls (e.g. SEC, PCI etc) Fear of bad reputation/press => public disclosure of data breach of PII in most US states (SB1386) Fear of lawsuits from businesses => fraud losses from private’s business and customers Doubts on risk mitigation measures => Not trusting our own security technology, people, processes Uncertainty on business impacts => Are we the target? How much money we loose from OWASP fraud incidents?
  11. 11. Lesson #3: Adopting An Adversarial ApproachToward Risk Management “Us vs. Them” (Security vs. Dev/IT/Business) Problem:  Remediation is drudgery  Demonstrating Threats & Mitigation Techniques is Absent  Does not foster collaboration amongst those whose ID risk and those who mitigate it. OWASP
  12. 12. Lesson #4 There is a Mature Approach toRisk Management: People, Process, Tools” People prepared to learn/deal/respond to cyber threats Processes for identifying security flaws that exploit weaknesses in applications/controls Tools and countermeasures to mitigate the risk posed to cyber threats OWASP 12
  13. 13. PART II-Introducing PASTA™ (Process for Attack Simulation and Threat Analysis) Risk Based Threat Modeling Methodology OWASP 13
  14. 14. Threat Modeling Defined[Application] Threat Modeling A strategic process aimed at considering possible attack scenarios and vulnerabilities within a proposed or existing application environment for the purpose of clearly identifying risk and impact levels.Use formal models to categorize threats, map them to vulnerabilities and identify countermeasuresDifferent focus for the analysis: Software centric Asset centric Security centric OWASP
  15. 15. The Limitations of Threat Modeling Today Several methodologies, none is widely accepted  STRIDE & DREAD are not methodologies, threat and risk classification respectively Narrow focus on risk mitigation (e.g. asset, attack, software, security centric) not all geared toward secure architecture analysis Limited in the adoption within the S-SDLC comparing with other assessments (e.g. secure code reviews, application pen testing) Not part of IS governance (e.g. information security risk management, fraud, incident response) Subjective and ad-hoc process reliant on application security knowledge of SMEs (Subject Matter Experts)/Security Architects/Consultants OWASP
  16. 16. The PASTA™ Recipe For Threat Modeling Focus on the application as business-asset target Embodies all strategic process for mitigating cybercrime risks Simulates attacks and analyzes targets Implemented in tactical stages each with pre- determined steps Focused on minimizing risks to applications and associated impacts to business OWASP
  17. 17. The PASTA™ Threat Modeling Methodology OWASP 17
  18. 18. The Beneficiaries of PASTA™ Threat Modeling Business managers can incorporate which security requirements that impact business Architects understand security/design flaws and how countermeasure protect data assets Developers understand how software is vulnerable and exposed Testers can use abuse cases to security tests of the application Project managers can manage security defects more efficiently CISOs can make informed risk management decisions OWASP 18
  19. 19. PART III-Using PASTA™ for thereat modeling of banking-malware attacks OWASP 19
  20. 20. Applying P.A.S.T.A for Banking Malware Threat Modeling, Goals of the VII Stages:I. Capture requirements for the risk assessment of banking malware threats, attacks and vulnerabilitiesII. Define the technical scope for the analysis application and transactionsIII.Conduct architecture level and transactional level security control analysisIV. Identify and extract threat information from the sources of intelligence/incidentsV. Analyze weaknesses and vulnerabilitiesVI. Model attacks scenarios and exploitsVII.Formulate a risk mitigation strategy to reduce the impact of banking malware to the business OWASP 20
  21. 21. STAGE IDefine The Business & Security Objectives: “Capture requirements for the analysis and management of banking malware risks” OWASP 21
  22. 22. Analysis Of Preliminary Impacts Of BankingMalware Impacts to Business  Lose money over fraud (e.g. illegal money transfers) and loss of customer’s sensitive information  Non-liability for fraud against business accounts triggers lawsuits  Reputation loss due to either public disclosure of loss of customer’s PII (e.g. affect company reputation and customer’s loyalty)  Unlawful compliance, due diligence and failing audit impacts (e.g. PCI-DSS, FFIEC/OCC, GLBA, SB 1386, FACT Act, PATRIOT Act) Impacts to the Customers  Theft of credentials  Theft of sensitive and confidential information  Loss of money from business accounts (Business Accounts) OWASP
  23. 23. Business Objectives & Security Requirements Project Business Objective Security and Compliance Requirement Perform an application risk Risk assessment need to assess risk from attacker assessment to analyze malware perspective and identify on-line banking transactions targeted banking attacks by the attacks Identify application controls Conduct architecture risk analysis to identify the application and processes in place to security controls in place and the effectiveness of these mitigate the threat controls. Review current scope for vulnerability and risk assessments. Comply with FACT Act of 2003 Develop a written program that identifies and detects the and FFIEC guidelines for relevant warning signs – or “red flags” – of identity theft. authentication in the banking Perform a risk assessment of online banking high risk environment transactions such as transfer of money and access of Sensitive Customer Information Analyze attacks and the targets Analyze attack vectors used for acquisition of customers’PII, that include data and high risk logging credentials and other sensitive information. Analyze transactions attacks against user account modifications, financial transactions (e.g. wires, bill-pay), new account linkages Identify a Risk Mitigation Include stakeholders from Intelligence, IS, Fraud/Risk, Legal, Strategy That Includes Business, Engineering/Architecture. Identify application Detective and Preventive countermeasures that include preventive, detective (e.g. Controls/Processes monitoring) and compensating controls against malware- based banking Trojan attacks OWASP
  24. 24. STAGE IIDefine The Technical Scope: ”Definition of the scope of the threat modeling exercise” OWASP 24
  25. 25. The Online Banking Application Profile Application Profile: Online Banking Application General The online banking application allows customers to perform Description banking activities such as financial transactions over the internet. The type of transactions supported by the application includes bill payments, wires, funds transfers between customer’s own accounts and other bank institutions, account balance-inquires, transaction inquires, bank statements, new bank accounts loan and credit card applications. New online customers can register an online account using existing debit card, PIN and account information. Customers authenticate to the application using username and password and different types of Multi Factor Authentication (MFA) and Risk Based Authentication (RBA) Application Type Internet Data Public, Non Confidential, Sensitive and Confidential PII Classification Inherent Risk HIGH High Risk YES Transactions User roles Visitor, customer, administrator, customer support representative Number of users 3 million registered customers OWASP
  26. 26. The Definition of The Technical Scope Design artifacts used for defining the scope:  Application components with respect to the application tiers (presentation, application, data)  Network topology  Protocol/services being used/exposed from/to the user to/from the back end (e.g. data flow diagrams)  Use case scenarios (e.g. sequence diagrams) Application design information to be extracted to define the scope:  The application assets (e.g. data/services at each tier)  The security controls of the application (e.g. authentication, authorization, encryption, session management, input validation, auditing and logging)  The data interactions between the user of the application and between servers for the main use case scenarios (e.g. login, registration, query etc) OWASP
  27. 27. The Architecture Diagram In Scope OWASP 27
  28. 28. The Application Functions in Scope All financial transactions that are possible targets for banking malware attacks:  Login help functions (e.g. registrations, reset userId/pwd)  Customer profile management functions (e.g. Change of account profiles, emails, address, phone numbers)  High risk logins (e.g. authentication with multi-factor authentication)  Transactions involving validation of Sensitive Customer Information (e.g. Validations of CCN#, CVV, ACC# and PINs for registration/ account opening)  Access of PII and Sensitive Customer Information (e.g. ACC#, CCN#, SSN, DOB)  High Risk Financial Transactions (e.g.  Money transfers to external accounts  ACH  Wires,  Bill-payments) OWASP 28
  29. 29. STAGE IIIDecompose the Application :”Identify the security controls that protect the application data/assets/servers/components” OWASP 29
  30. 30. Data Flow Diagramming MFA RBA/ Application Fraud HTTPs Calls (.do) Detection User/ Request XML/HTTPS Browser Web Server Financial Application XML/HTTPS HTTPs Transactions (ACH, wires Responses external transfer) (App & DB Server/Financial Server Boundary) Responses Messaging Internal (Web Server/ App & DB Server Boundary) Message Bus XML/JMS Application DMZ (User/Web Server Boundary) Server Service Message Restricted Network Response SQL Query Call/ Auth Data JDBC Financial Transaction Processing MainFrame Authentication Credential Store OWASP 30
  31. 31. Transactional Security Control Analysis OWASP 31
  32. 32. STAGE IV Identify And Analyze The Threats: “Identifying and extracting threat information from sources of intelligence to learn about the threat-attackscenarios and attack vectors used by banking malware“ OWASP 32
  33. 33. Identification of the Sources Of Intelligence Internal sources of fraud cases, attacks and incidents (e.g. SIRT) External sources of gathering and sharing information about banking malware attacks and incidents, these includes public/free and private/at cost services some examples:  APWG  Trusteer  CERT  UK Payments Administration  Digital PhisNet  Verizon  FS-ISAC  Verisign iDefense  IC3  Zeus Tracker  Internet Fraud Alerts ( OWASP
  34. 34. Statistical Data Of Banking Malware Targets SourceThe top-level domains most commonly targeted by ZeuS OWASP
  35. 35. The Upward Trends Of Spreading of BankingMalware OWASP
  36. 36. Banking Malware Attack Scenarios OWASP 36
  37. 37. Examples Of Banking Malware CustomerReported Incidents OWASP 37
  38. 38. Analysis of Attack Vectors Used By DifferentTypes of Banking Malware OWASP 38
  39. 39. Characterizing The Banking Malware Threat Profile1. Targeted and customizable2. Uses multiple avenues of infection and different attack vectors3. Takes & sends commands from command and control server4. Evades defenses for client and web application such as Anti-Virus, SS/TLS, MFA C/Q and fraud detection systems5. Injects HTML code into the victim’s browser to harvest accounts, login and PII data while user is logged6. Steals certificates for authentication7. Steals user input with key-loggers and form grabbers8. Allows fraudster to transfer money from the victim machine by riding the OWASP user session 39
  40. 40. STAGE V Weakness and Vulnerabilities Analysis:Analyzing application weaknesses and vulnerabilities exploited by banking malware attacks OWASP 40
  41. 41. Banking Malware Threats, Vulnerabilities & ApplicationWeaknesses Exploits Social Engineering/Phishing Threats  Exploit weak anti-phishing site to user controls (e.g. EV SSL)  Lack of information to customer on banking malware threats Account Takeover & Identify Theft Threats  Exploit weak data protection transit & storage (e.g. unsecure cookies, tokens, unsecured secrets and certificates for authentication)  Authorization flaws (e.g. RBAC bypass/elevation of privileges)  Business logic flaws (e.g. PINs, ACC# validations across channels) Financial Loss & Fraud Threats  Exploit authentication flaws for transactions (e.g. MFA bypass, weak authentication/factor per transactions),  Session management flaws and vulns. (e.g. session fixation, session riding/CSRF)  Non repudiation flaws (e.g. one-way SSL no digital signing for transactions) OWASP 41
  42. 42. Architecture Level View Of Security Flaws &Vulnerabilities > Presentation Tier > Get MY Account Info And Account Account#:***8765 Balance: 45,780 $ Weak Anti-Phishing Activity Last Transaction: Represents the top most level 5/25/09 and Anti-UI- of the application. Spoofing Controls The purpose of this tier is to translate commands from the user interface & Warnings into data for processing to other tiers and Browser present back the processed data ` ` Vulnerabilities & Flaws browser browser Authentication, Logic Tier Authorization, This layer processes commands and Identification and makes decisions based upon Session Mgmt. the application business logic It also moves and processes data Vulnerabilities and Servers Servers Design Flaws between the presentation and the data tier Account#, Query Balance, Data Tier Transaction History Flaws and Is the layer responsible for data storage and Vulnerabilities retrieval from a database or file system While Protecting Query commands or messages are processed Data/Transaction by the DB server, retrieved from the datasource and passed back to the lo the logical tier for Confidentiality processing before being presented to the user and Integrity Database Storage OWASP 42
  43. 43. The Top 5 Malware PropagationVulnerabilities & The Top 10 Attacks OWASP 43
  44. 44. Web Application Vulnerabilities Likely To BeExploited By Banking Malware Attacks Black White Box Box Testing Testing OWASP
  45. 45. STAGE VIModel The Attacks and The Exploit Of Weaknesses and Vulnerabilities: “Modeling of banking malware attacks” OWASP 45
  46. 46. Banking Malware Attack Analysis UsingAttack Trees Fraudster Fraudster Upload Malware on Attack Victim’s Phishing Email, Use Stolen Banking Vulnerable Site Vulnerable Browser FaceBook Social Credentials/ Engineering Challenge C/Q Drive-by Download/ Upload Banking Remote Access To Phish User To Click Malicious Ads Malware on Compromised PC Link With Malware Customer’s Pc Through Proxy Steal Digital Steals Keystrokes Logs into Victim’s Certificates For Man In The with Online Bank Authentication Browser Key-logger Account Delete Cookies Modifies UI Perform Un- Forcing to Login To Rendered By The Redirect Users To authorized Money Steal Logins Browser Malicious Sites Transfer to Mule Harvest Confidential Data/ Sends Stolen Data Money Transferred Credentials From to Fraudster’s From Mule to Victim Collection Server Fraudster OWASP 46
  47. 47. Banking Malware Attack Analysis Using “Use and Abuse Cases” Key logger/From grabber Threatens captures keystrokes Includes Login With UserID Drops Banking password incl. credentials Malware on victims/PC Includes over SSL Includes Includes Set IP with Proxy/MiTM to Includes same IP gelocation Includes of the victim FraudsterUser Threatens Includes Trust connection by IP and machine tagging/browser Communicate attributes Hijacks SessionIDs, with fraudster C&C Includes Cookies, Machine Tagging Includes Threatens Includes Capture OTP on web channel Threatens and authenticate Enter One Time Password (OTP) to authenticate on behalf of the user transaction Includes Capture C/Qs in transit and Threatens authenticate on behalf of user Enter Challenge Question (C/Q) to authenticate transaction Threatens Man In The Browser Injected HTML to capture C/Q OWASP 47
  48. 48. Attack & Vulnerability Analysis for ApplicationFunctions/Transactions OWASP 48
  49. 49. PASTA ™ Threat Analysis With The Help of TheThreatModeler™ Tool OWASP 49
  50. 50. Factors for Managing Risks of BankingMalware Attacks The Threats (e.g. the causes) Fraudster targeting on-line banking application for data theft and to commit fraud (e.g. un- authorized money transfer to fraudulent accounts) The Vulnerabilities (e.g. the application weakness) Flaws in authentication and session management; Vulnerabilities in data confidentiality and integrity; Gaps in auditing and logging fraudsters actions and security events The Technical impacts (e.g. compromising security controls) Bypassing authentication with Challenge/Questions, KBA, OTPs; Bypassing customer validations to authorize financial transactions; Tampering web forms for account takeover Abuse session by impersonating the authenticated user The Business Impact (e.g. financial loss, fraud, fees/fines due to unlawful compliance etc) Financial loss due to fraud and un-authorized money transfer to money mules; Reputation loss due to disclosure of breaches of customer data, PII; Lawsuits from businesses victim of business account compromise, un- OWASP 50 covered money losses; Unlawful non-compliance with regulations
  51. 51. Risk Analysis and Risk Mitigation Strategy Calculate risks objectively using different models for calculating risk:  Quantitative (e.g. Likelihood x Impact (H, M, L), Threat Source (STRIDE) x Severity (DREAD), Threat X Vulnerability X Impact (OWASP))  Quantitative (e.g. ALE = SLE X ARO) Devise a risk mitigation strategy based upon holistic measures:  Preventive and detective controls  Countermeasures at different layers/tiers of mitigation (e.g. browser web application, infrastructure)  Processes-Governance (e.g. risk based testing, improved fraud detection, threat OWASP analysis, cyber intelligence) 51
  52. 52. The Banking Malware Risk Management FrameworkThreat Misuses and Vulnerabilities & Countermeasures Technical BusinessAgents & Attack Vectors Weaknesses Impacts ImpactsMotivesDropper of Attacker targets Input validation vulnerabilities Identification and Site integrity is Reputation loss.Malware seeking vulnerable sites to allowing for Frame injection remediation of common violated, visitors of Money loss/siteto upload it to upload malware for of fraudsters URL, file injection vulnerabilities the site get malware taken down,vulnerable sites drive by download upload via flaws exploits and and data /input downloaded via lawsuits SQL injection attacks validation flaws malicious adsFraudster Attacker target Phishing and social Consumer education Once user selects Fraud, moneyattacking bank banking customer engineering attacks via campaigns, EV-SSL malicious link, JS on losses, reputationcustomers and with phishing to different channels (email, certificates to prove client, install banking loss, data breachinstitutions exploit browser Facebook, SMS). Lack of authenticity, site to user malware/trojan disclosure, vulnerabilities and customer information about controls, browser compromising the upload banking banking malware threats, lack controls browser trojan keylogger on of site to user trust controls his PC/browser (e.g. EV SSL)Banking malware Banking Browser vulns. allowing MiTB, Customer education on Once customer enter Loss of customerharvest s malware/trojan, gaps in anti-automation spoofed Uis, anti-forgey extra data in the PII, credentials,viictim’s account inject HTML form detection controls, virtual controls, CAPTCHA, Man HTML form it is sent PII. ReputationalData and logins fields in session keyboard bypassed by form present controls, anti- to C&C: loss of data loss via public using MiTB attack , grabbing forgery controls confidentiality and disclosure of keylogger to stead data integrity since breach, data, sends data to outside application Compliance audit C&C and receives control lawsuits, account commands replacement costFraudster Attacker sends and Authentication flaws in Architecture risk analysis Loss of data Money lossesattacking bank receives data to protecting transaction with to identify flaws, OOBA, confidentiality and associated tocustomers and banking malware to adequate strength, session OOBV, transaction transaction integrity, fraud frominstitutions perform un- management flaws and signatures, fraud session hijacking, money transfers. authorized financial vulnerabilities (e.g. session detection/monitoring, missing logging, Lawsuits transactions using riding/CSFR, fixation), non- event correlation from detection/monitoring compliance/audit MiTM and session repudiation flaws logs and fraud alerts OWASPrisks riding attacks
  53. 53. Examples of Countermeasures Against Banking Malware Threats PREVENTIVE DETECTIVE Anti UI Spoofing/Forging  Fraud detection/transaction Web Form Controls Monitoring  Watermarks on web forms  Anomaly detection that are difficult to spoof  Detection of cookies HTTP param. by the fraudster without  Logs of session information x high the user noticing risk transactions  Customer information to help identify forgery of  Malware vs. Man Present HTML/injected fields Detection Two-Way Out of Band  Capture/profile browser actions/events (OOB) Auth & Verification  Anti-automation/CAPTCHA / Transaction Signing  SMS, phone to send and  Customer alerts (e.g. SMS) receive authorization and  Real time notification for financial verification of transaction transactions /account changes 53 OWASP