Risk Analysis Of Banking Malware Attacks

  • 5,463 views
Uploaded 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 …

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

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,463
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
321
Comments
0
Likes
3

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
  • This is to highlight that the threat has changed in terms of attacker motives, the sophistication of the attacks and the impact.APTattacks are focused on a single target, lastinguntil “they are in,” and are meant to collectinformation over a long period of time. They leavefew signs of their success, wanting to stay hiddenfor as long as possible in order to acquire largeamounts of sensitive information.Financial losses due to malware-based attacks are rising:In the U.S.A. alone, according to data from FDIC (Federal Deposit Insurance Corporation), during the third quarter of 2009 malware-based online banking fraud rose to over $ 120 millionIn the UK, according to data from the Cards Association, losses from the online banking sector in UK during 2009 totaled 60 million UK pounds.
  • Slide to convey how the threat landscape changed to qualify the type of attacks and the attack. Also mention other data not included on the slide such as the most sought type of data and the attack vectors
  • Are with credentials as a mean to get the data ?
  • Slide to convey how the threat landscape changed to qualify the type of attacks and the attack. Also mention that
  • Stage I-Define the objectives: Identify business objectives and ensure an appropriate level of security requirements to support the business goals for the application yet meeting compliance with security standards. Identify preliminary security and compliance risks and their business impacts to the application.Stage II- Define the technical scope: Define the technical scope/boundaries of threat modeling as dependency on the various technologies, software and hardware, components and services used by the application. Categorize any architectural and technologies/components whose function is to provide security controls (e.g. authentication, encryption) and security features (e.g. protection of CIA)Stage III- Decompose the application: Decompose the application in essential elements of the application architecture (e.g. users, servers, data-assets) that can be further analyzed for attack simulation and threat analysis from both the attacker and the defender perspective.Stage IV- Analyze the threats: Enumerate the possible threats targeting the application as an asset. Identify the most probable attack scenarios based upon threat agent models, security event monitoring and fraud mapping and threat intelligence reports. The final goal is to analyze the threat and attack scenarios that are most probable and need to prioritize later for attack simulation.Stage V-Vulnerabilities & Weaknesses Analysis: The main goal of this stage of the methodology is to map vulnerabilities identified for different assets that include the application as well as the application infrastructure to the threats and the attack scenarios previously identified in the previous threat analysis stage. Formal methods that map threats to several generic types of vulnerabilities such as threat trees will be used to identify which ones can be used for attacking the application assets. Once these vulnerabilities are identified, will be enumerated as and scored using standard vulnerability enumeration (CVE, CWE) and scoring methods ( CVSS, CWSS)Stage VI: Analyze the Attacks: The goal of this stage is to analyze how the application and the application context that includes the users-agents, the application and the application environment, can be attacked by exploiting vulnerabilities and using different attack libraries and attack vectors. Formal methods for the attack analysis used at this stage include attack surface analysis, attack trees and attack libraries-patterns. The ultimate outcome of this stage is to map attacks to vulnerabilities and document how these vulnerabilities can be exploited by different attack vectors.Stage VII:Risk and Impact Analysis: The goal of this final stage is to derive risk and impact values for the application environments, determine the residual risks to the business after countermeasures are applied and existing compensating security controls-measures are considered and provide risk mitigation strategies for informed risk management decisions.
  • P.A.S.T.A allows architects to understand how vulnerabilities to the application affect threat mitigation, identify the trust boundaries and the classification of the data assets, identify vulnerabilities and apply countermeasures via proper design, developers are helped to understand which components of the application are vulnerable and the learn on how to mitigate vulnerabilities, security testers can use security requirements derived through the methodology as well as use and abuse to create positive and negative test cases, project managers can prioritize the remediation of security defects according to risks, business managers can determine which business objectives have impact on security while information risk officers can make strategic risk management decisions by mitigating technical risks yet considering costs of countermeasures vs. costs associated with business impact as risk mitigation factors
  • Explain the rationale of P.A.S.T.A and why this new framework is being used The seven steps of the P.A.S.T.A process will be covered by looking first and for most at malware-based threat mitigation as a business problem, followed by the definition of the technical scope of existing security controls and their dependencies, the analysis of the effectiveness of these controls using use and abuse cases, the analysis of malware-based threats using threat agent models and threat intelligence reports, the vulnerability and weaknesses analysis of multi-factor authentication, transaction integrity and session management controls, the model of the banking Trojan attacks using attack surface analysis, attack trees and identification of attack paths and the final risk and impact analysis that qualifies and quantifies the negative impact to the financial institution for these kind of attacks and the residual risk after different countermeasures are applied to protect online banking transactions as well as to detect the occurrence of the attacks. The ultimate goal of this presentation is to be able to provide application security-risk managers-officers and application security architects, an example on how P.A.S.T.A. threat modeling can be used to making informed risk management decisions and devise risk mitigation strategies to protect online banking applications from banking Trojans, malware-based type of attacks.
  • Application architecture:The architecture of the application with respect to the “end to end” deployment scenario The location of servers on which the application functionality resides to (e.g. the network topology)The end to end data flows and the protocol/services being used/exposed from/to the user to/from the back end (e.g. data flow diagrams)The use case scenarios (e.g. sequence diagrams) Extract essential information in support of security architecture risk analysisThe exposure of the assets: servers hosting the application and the data including any external, DMZ and internal/GRN linksAll major application software/system components in all the application iers(e.g. front end, middle-tier, back end) and the protocols being used between tiersThe data interactions between the user of the application and between servers for the main use case scenarios (e.g. login, registration, query etc)
  • Login help functionsUser registration, change userID/password, forgot userID/password, change of challenge/question/answersOnline profile management functionsChange of account profiles, emails, address, phone numbersHigh risk loginsAuthentication with Challenge/Questions, KBALogging from high risk location/machine, countryTransactions involving validation of Sensitive Customer InformationValidations of CCN#, CVV, ACC# and PINs for registration/ account openingAccess of PII and Sensitive Customer InformationRetrieval of PII such as SSNs, TaxIDs, DOB (e.g. account opening, tax statements)Access to Sensitive Customer Information such as ACC#, CCN#, PINsHigh Risk Financial TransactionsAccess of Sensitive Customer Information (e.g. ACC#, CCN#, SSN, DOB)ACHWires,Bill-payments
  • Web-based attacks take on all comersWhile targeted attacks frequently use zero-day vulnerabilities and social engineering to compromiseenterprise users on a network, similar techniques are also employed to compromise individual users. Inthe late 1990s and early 2000s, mass-mailing worms were the most common means of malicious codeinfection. Over the past few years, Web-based attacks have replaced the mass-mailing worm in thisposition. Attackers may use social engineering—such as in spam messages, as previously mentioned—tolure a user to a website that exploits browser and plug-in vulnerabilities. These attacks are then used toinstall malicious code or other applications such as rogue security software on the victim’s computer.15Of the top-attacked vulnerabilities that Symantec observed in 2009, four of the top five being exploitedwere client-side vulnerabilities that were frequently targeted by Web-based attacks (table 2). Two of thesevulnerabilities were in Adobe Reader, while one was in Microsoft Internet Explorer and the fourth was in anActiveX® control. This shows that while vulnerabilities in other network services are being targeted byattackers, vulnerabilities in Web browsers and associated technologies are favored. This may be becauseattacks against browsers are typically conducted through the HTTP protocol that is used for the majority ofWeb traffic. Since so much legitimate traffic uses this protocol and its associated ports, it can be difficultto detect or block malicious activity using HTTP .The top Web-based attacks observed in 2009 primarily targeted vulnerabilities in Internet Explorer andapplications that process PDF files (table 3). Because these two technologies are widely deployed, it islikely that attackers are targeting them to compromise the largest number of computers possible. Of theWeb browsers analyzed by Symantec in 2009, Mozilla® Firefox® had the most reported vulnerabilities, with169, while Internet Explorer had just 45, yet Internet Explorer was still the most attacked browser. Thisshows that attacks on software are not necessarily based on the number of vulnerabilities in a piece ofsoftware, but on its market share and the availability of exploit code as well.16
  • Detective ControlsDetect and monitor application functions/transactions targeted by banking malwareAnomaly detection to detect anomalies in login/account transactions and misuse/signature based detection to match with known attack patternsLogs of malware targeted functions such as logins, account management, financial transactions involving wires, billpay, ACH, external transfersIdentify malware by detecting clues of malware initiated transactionsJavascript to capture user’s actions to detect HTML injected data fields with hidden/encrypted codes validated on the serverDetection of specific cookies and web form variables set by malware in HTTP transaction flowsHave customers to subscribe to alerts/notifications OOB (e.g. SMS) for financial transaction

Transcript

  • 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 http://www.owasp.org
  • 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. PART I – Malware and Hacking: The Threat Scenario OWASP 3
  • 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. 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: http://www.verizonbusiness.com/Products/security/dbir/ OWASP 5
  • 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: http://www.verizonbusiness.com/Products/security/dbir/ OWASP 6
  • 7. The Threat Actors Behind Hacking & MalwareSource: Verizon Data Breach investigation Report: http://www.verizonbusiness.com/Products/security/dbir/CyberCrime & Doing Time A Blog about Cyber Crime and related Justice issues: http://garwarner.blogspot.com OWASP 7
  • 8. The New vs. the Old or Dr Jerkill/Mr Hydevs. Sherlock Holmes OWASP 8
  • 9. Lesson #1 From Business Risk Management: IKnow it By I Ignore it OWASP
  • 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. 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. 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. PART II-Introducing PASTA™ (Process for Attack Simulation and Threat Analysis) Risk Based Threat Modeling Methodology OWASP 13
  • 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. 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. 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. The PASTA™ Threat Modeling Methodology OWASP 17
  • 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. PART III-Using PASTA™ for thereat modeling of banking-malware attacks OWASP 19
  • 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. STAGE IDefine The Business & Security Objectives: “Capture requirements for the analysis and management of banking malware risks” OWASP 21
  • 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. 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. STAGE IIDefine The Technical Scope: ”Definition of the scope of the threat modeling exercise” OWASP 24
  • 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. 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. The Architecture Diagram In Scope OWASP 27
  • 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. STAGE IIIDecompose the Application :”Identify the security controls that protect the application data/assets/servers/components” OWASP 29
  • 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. Transactional Security Control Analysis OWASP 31
  • 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. 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 (ifraudalert.org) OWASP
  • 34. Statistical Data Of Banking Malware Targets SourceThe top-level domains most commonly targeted by ZeuS OWASP
  • 35. The Upward Trends Of Spreading of BankingMalware OWASP
  • 36. Banking Malware Attack Scenarios OWASP 36
  • 37. Examples Of Banking Malware CustomerReported Incidents OWASP 37
  • 38. Analysis of Attack Vectors Used By DifferentTypes of Banking Malware OWASP 38
  • 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. STAGE V Weakness and Vulnerabilities Analysis:Analyzing application weaknesses and vulnerabilities exploited by banking malware attacks OWASP 40
  • 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. 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. The Top 5 Malware PropagationVulnerabilities & The Top 10 Attacks OWASP 43
  • 44. Web Application Vulnerabilities Likely To BeExploited By Banking Malware Attacks Black White Box Box Testing Testing OWASP
  • 45. STAGE VIModel The Attacks and The Exploit Of Weaknesses and Vulnerabilities: “Modeling of banking malware attacks” OWASP 45
  • 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. 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. Attack & Vulnerability Analysis for ApplicationFunctions/Transactions OWASP 48
  • 49. PASTA ™ Threat Analysis With The Help of TheThreatModeler™ Tool OWASP 49
  • 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. 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. 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. 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
  • 54. QUESTIONS ANSWERS OWASP 54