Keamanan Digital dan Privasi di Masa Pandemi-Taro Lay (Director-Kalama Cyber)
- 1. Keamanan Digital dan Privasi di Masa Pandemi Taro Lay Cyber Security Evangelist
- 5. The “New Normal” Challenges
- 7. Old Problem in “New Situation Almost three-quarters (approximately 72%) of people forced to work remotely through the Covid-19 coronavirus pandemic believe they are now more conscious of their organizational cyber security policies than they were before, but are still happy to break the rules if expedient.
- 8. The Beginning of Attack Stories 80% of security breaches involve a weak or stolen privileged credential 85% of cyber attacks enter through a compromised endpoint
- 9. Privilege Accounts ● Organizations are facing new challenges as they rapidly shift to support remote teams ● Passwords may be reused/shared across multiple people and systems ● Users may install risky applications without review or approval ● IT has less time for oversight of privileged accounts
- 10. Application Security Hypervisor, images (VM/Docker) App level security (libs, code, data) OS / Network / Physical Access Intra-services communication (auth, azn, TLS)
- 13. JSON Web Token (JWT) ● Based on JSON to generate access tokens. ● Contain a header, payload, and signature ● Every microservices can read the data from the passed JWT without having to validate against any other web service.
- 14. API Security ● Where do we validate that the data we are receiving is what we expect? ● How do we ensure that we don’t leak data or exceptions? ● Where do we validate that the access tokens are the ones we expect? ● Where do we authenticate/authorize access to business data? ○ Can she/he view a resource with ID 123456 ?
- 15. ● API Threat Protection ○ Content validation ○ Token validation ○ Traffic management ○ Payload security ○ Threat detection ● API Access Control ○ Access tokens management ○ Autentication ○ Authorization ○ Identity management API Firewall API/Identity Management
- 16. OWASP Top 10 API Security (2019) A1 Broken Object Level Authorization A2 Broken User Authentication A3 Excessive Data Exposure A4 Lack of Resources & Rate Limiting A5 Broken Function Level Authorization A6 Mass Assignment A7 Security Misconfiguration A8 Injection A9 Improper Assets Management A10 Insufficient Logging & Monitoring
- 17. A1: Broken Object Level Authorization Attacker substitutes ID of their resource in API call with an ID of a resource belonging to another user. USE CASES ● API call parameters use IDs of resourced accessed by the API: /api/shop1/financial_details ● Attackers replace the IDs of their resources with different ones, which they guessed: /api/shop2/financial_details • The API does not check permissions and lets the call through • Problem is aggravated if IDs can be enumerated: /api/123/financial_details
- 18. A2: Broken Authentication Poorly implemented API authentication allowing attackers to assume other users’ identities. USE CASES ● Unprotected APIs that are considered “internal” ● Weak authentication not following industry best practices ● Weak, not rotating API keys ● Weak, plain text, encrypted, poorly hashed, shared/default passwords ● Susceptible to brute force attacks and credential stuffing ● Credentials and keys in URL ● Lack of access token validation (including JWT validation) ● Unsigned, weakly signed, non-expiring JWTs
- 19. A3: Excessive Data Exposure API exposing a lot more data than the client legitimately needs, relying on the client to do the filtering. Attacker goes directly to the API and has it all. USE CASES ● APIs return full data objects as they are stored by the database ● Client application shows only the data that user needs to see ● Attacker calls the API directly and gets sensitive data
- 20. A4: Lack Of Resources & Rate Limiting API is not protected against an excessive amount of calls or payload sizes. Attackers use that for DoS and brute force attacks. USE CASES ● Attacker overloading the API ● Excessive rate of requests ● Request or field sizes ● “Zip bombs”
- 21. A5: Broken Function Level Authorization API relies on client to use user level or admin level APIs. Attacker figures out the “hidden” admin API methods and invokes them directly. USE CASES ● Some administrative functions are exposed as APIs ● Non-privileged users can access these functions if they ● know how ● Can be a matter of knowing the URL, using a different ● verb or parameter
- 22. A6: Mass Assignment USE CASES ● API working with the data structures ● Received payload is blindly transformed into an object and stored ● Attackers can guess the fields by looking at the GET request data
- 23. A7: Broken Function Level Authorization Poor configuration of the API servers allows attackers to exploit them. USE CASES ● Unpatched systems ● Unprotected files and directories ● Unhardened images ● Missing, outdated, misconfigured TLS ● Exposed storage or server management panels ● Missing CORS policy or security headers ● Error messages with stack traces ● Unnecessary features enabled
- 24. A8: Injection Attacker constructs API calls that include SQL-, NoSQL-, LDAP-, OS- and other commands that the API or backend behind it blindly executes. USE CASES ● Attackers send malicious input to be forwarded to an internal interpreter: ●SQL, NoSQL ●LDAP ●OS commands ●XML parsers ●Object-Relational Mapping (ORM)
- 25. A9: Improper Assets Management Attacker finds non-production versions of the API: such as staging, testing, beta or earlier versions - that are not as well protected, and uses those to launch the attack. USE CASES ● DevOps, cloud, containers, make having multiple deployments easy (Dev, Test, Branches, Staging, Old versions) ● Desire to maintain backward compatibility forces to leave old APIs running ● Old or non-production versions are not properly maintained ● These endpoints still have access to production data ● Once authenticated with one endpoint, attacker may switch to the other
- 26. A10: Insufficient Logging & Monitoring Lack of proper logging, monitoring, and alerting let attacks go unnoticed. USE CASES ● Lack of logging, monitoring, alerting allow attackers to go unnoticed ● Logs are not protected for integrity ● Logs are not integrated into Security Information and Event Management ● (SIEM) systems ● Logs and alerts are poorly designed ● Companies rely on manual rather than automated systems
- 27. The attack Account take over for any Uber account from a phone number The Breach None. This was a bug bounty. Core Issues First Data leakage : driver internal UUID exposed through error message! Uber (Sept 2019) A2 A3 A4 A5 A6 A10 A9 A8 A7 A1 https://appsecure.security/blog/how-i-could-have-hacked-your-uber-account Hacker can access any driver, user, partner profile if they know the UUID Second Data leakage via the getConsentScreenDetails operation: full account information is returned, when only a few fields are used by the UI. This includes the mobile token used to login onto the account
- 28. A2 A3 A4 A5 A6 A10 A9 A8 A7 A1Equifax 2017 https://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html The attack Remote command injection attack: server executes commands written in ONGL language when a Content-Type validation error is raised. Can also be exploited using the Content-Disposition or Content-Length headers The Breach One of the most important in history: 147 millions people worldwide, very sensitive data Equifax got fined $700 million in Sept 2019 Core Issues Remote command injection vulnerability in Apache Struts widely exploited during months.
- 29. Conclusion ● Micro segmentation ● Segregation of duty ● Privilege account management ● Open API and API Contract
- 30. Contact: Taro Lay email: [email protected] whatsapp: +62 811 189788