The sweet and the bitter of cloud computing

Sze Siong Teo | CyberCentral Summit 2019

about me

programming - 22 years

devops - 5 years

security - 8 years


industry exp. - 14 years


  • On-premise vs public cloud
  • Real world cloud security issues
  • Mitigation techniques

on-premise vs public cloud

  • Compute - whose app. runs there?
  • Network - who uses the same ASN?
  • Storage - where is your data?
  • How wide is the system trust chain?

REAL WORLD cloud security issues

#1 Credential leak

Credential leak: Example #1

Credential leak: Example #2

Credential leak: Example #3

Credential leak: Example #4

Credential leak: Example #5

github hackerone program's hacktivity (as of 24th March 2019)

gitlab hackerone program's hacktivity (as of 24th March 2019)

Common saas CI/CD config filenames

  • .travis.yml
  • .circleci/config.yml
  • .gitlab-ci.yml
  • shippable.yml
  • fastlane/Fastfile (iOS/Android)

REAL WORLD cloud security issues

#2 Rogue supply chain

compromised supply chain

typosquatting: sneak attack on supply chain

  1. npm, PyPI, CPAN, Rubygems, maven, Packagist, etc..
  2. ISO files, VMDK, VDI, Docker Hub, AMI marketplace
  3. Lambda layers -
  4. AWS Serverless Application Repository
  5. Application download website / software update repository

different types of software supply chain

REAL WORLD cloud security issues

#3 Misconfigured cloud resources

most common s3 bucket acl confusion

how attackers get your bucket name?

  1. Use public SecLists (mainly web path lists)
  2. Sometimes gather OSINT to build custom SecLists​​
  • customer-transaction-backup
  • customer-profile-backup
  • cybercentral-wordpress-backup
  • cybercentral-wordpress-snapshot
  • cybercentral-backup-20190405 (date, etc.)
  • banking-transaction-kafka-backup
  • user-transaction-kafka-logs

how attackers get your bucket name?

Brute force with SecLists on below URL format:

  • mysql-dump.tar.gz, mysql-dump.bz2
  •, users.tar.gz
  • consumer-service-spring-config.xml
  • test.tar.gz
  • all.tar.gz,, all.bz2
  • db-backup.tar.gz, db_backup.bz2, etc.

Same approach for filenames when directory listing not available:

(Under the hood: aws s3 ls [target_bucket_name])

overbroad IAM permission

  1. IAM policy read+write common fallacy
    • If you have write permission, then you should be able to read from it too
  2. IAM principal with:
    • Wildcard on S3, SQS policy, etc.
    • Trust to the root of other account
  3. IAM policy with wildcard in:
    • IAM actions
    • AWS resources

Ssrf exploit in Google cloud that leads to rce

Ssrf exploit in AWS that leads to rce

misunderstood zero trust model

“The strategy around Zero Trust boils down to don’t trust anyone. We’re talking about, ‘Let’s cut off all access until the network knows who you are. Don’t allow access to IP addresses, machines, etc. until you know who that user is and whether they’re authorized.’”

  1. Usage of default VPC & default security group
  2. EC2/RDS with public IP and open security group

unnecessary exposure to public network

misconfigured mongodb server in public

mitigation techniques

  1. Never store any plaintext credential in source control
  2. Always keep the servers fully patched
  3. Use only libraries from official  sources and pin the package version
  4. Don't use S3 bucket ACL, use S3 bucket policy instead
  5. Don’t use access keys that ties to IAM user, always use IAM role
  6. Always provide "just sufficient" IAM permission for all service
  7. Never use AWS root user, go for split account model if multiple teams
  8. Limit egress traffic to known host only if possible
  9. Use private DNS zone for internal systems whenever possible
  10. Strong password policy and make MFA mandatory
  11. CloudTrail must be enabled and app. level logging is essential for SIEM
  12. SSO for all system is mandatory in large organization
  13. Rate limit request by cookie and by IP or trigger reCaptcha
  14. Never perform any HTTP request based on unsanitized input

thank you