Almost three-quarters of remote workers feel more conscious of their organization's cybersecurity policies during the pandemic, but are still willing to break rules if convenient. As organizations rapidly shift to remote work, they face new challenges around password reuse, risky app installations without approval, and less IT oversight of privileged accounts. The document discusses security best practices for privileged accounts, application security in microservices architectures, API security including JSON web tokens and the OWASP top 10 risks, and concludes with recommendations around microsegmentation, segregation of duties, privilege management, and open API contracts.

1. Keamanan Digital dan Privasi di Masa Pandemi
Taro Lay
Cyber Security Evangelist

2. Pandemic Situation

3. The Ugly Pictures

5. The “New Normal” Challenges

6. “New Normal”
with Old
Paradigm

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)

12. Monolithic vs Microservices

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: tarolay@kalama.id
whatsapp: +62 811 189788