Session on security hardening of public cloud services focused around AWS and GCP presented at Europe Cloud Summit

1. Security Hardening – Public Cloud Services
22-OCT-2020 | EUROPE CLOUDS SUMMIT Runcy Oommen

2. |Today’s Agenda|
Generic cloud security overview
Security services from GCP, AWS & Azure
Shared Responsibility Model
Categories of services for hardening
Cloud OS
Load Balancer
DNS Security
API Gateway
Platform (PaaS)
Serverless (FaaS)

3. Career
 Principal SDE, SONICWALL, 17+ yrs. industry experience
primarily in systems, cloud (private/public), security, networking
 10x multi-cloud certified (GCP, AWS, Azure, CNCF)
 Patent (India) in cloud security around distributed data storage
 Interested in serverless, containers and cloud native offerings.
Firm believer of a multi-hybrid cloud future
Community
 Organizer of GDG Cloud, AWS user Group and Cloud Native
meetup groups in Bangalore
 Regular speaker at domestic and international cloud, tech &
security conferences
 Multiple hackathon wins in cloud/security topics.
 Recognized by Google as a community influencer
[~]$ whoami
runcyoomme
n
https://runcy.
me
roommen

4. Let’s define “Cloud
security”
Cloud Security refers to a broad set of policies,
technologies, applications and controls utilized to
protect virtualized IP, data, applications, services and
the associated infrastructure of cloud computing
Reference:
https://en.wikipedia.org/wiki/Cloud_computing_secur

5. IT infrastructure & landscape
has undergone a paradigm
shift…

6. Traditional view

7. PaaS
Modern view

8. So, how exactly should cloud
security differ from traditional
network security?

9. Ubiquitous
The cloud is always reachable
from anywhere, any time, any
device
Scalable
You can add new features and
thousands of users without breaking
a sweat
Integrated
Security and other services talk
to each other for full visibility
Comprehensive
The Cloud scans every byte –
ingress and egress – including SSL
& CDN
Intelligent
The cloud learns from every user and
connection; any new threat is blocked for
all
Important facets of
cloud

10. Early days of
cloud
Move
Fast
O
R
Stay
SecureModern day
cloud
Move
Fast
AN
D
Stay
Secure

11. Cloud Features v/s Security
Balances
 Agility
 Self-service
 Scale
 Automation
 Gate
Keeper
 Standards
 Control
 Centralized

13. AWS Security, Identity & Compliance
Services

14. GCP Security Products &
Capabilities

15. Azure Security
Posture

16. Shared Responsibility Model In
Cloud

17. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

18. Hardening #1 – Cloud OS:
Amazon Linux 2, Google Container Optimized OS & Cloud Shell is
shipped with OpenSSH v7.4/v7.5 which is outdated and vulnerable to
multiple attacks

19. Solution: Upgrade to OpenSSH 7.8 or later!

20. Google Cloud ShellAmazon Linux 2

21. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
SITUATION RIGHT NOW!

22. What to do now? Here’s the elaborate
way…
Default package managers from AWS & GCP
does not even have a higher version of SSH!!!
 Extract the contents
 Install the compiled package to upgrade
 Install all the relevant dependencies
 Compile package from
source
 Download the latest package from openbsd.org
runcyoomme

23. Amazon Linux 2
Google Cloud Shell
Get the scripts - https://tinyurl.com/sshupdate runcyoomme

25. Hardening #2 – SSH Settings:
Default SSH settings (Ciphers & Key Exchange algorithms)
in Google Cloud Shell & Amazon Linux are deprecated and
weak

26. Confirming the presence of weak/deprecated Ciphers & Key
Exchanges
Amazon Linux 2
Google Cloud Shell
Amazon Linux

27. Search for ‘Ciphers’ & ‘KexAlgorithms’ in the man
page
Solution:
Check for new ciphers and kex after OpenSSH
upgrade
runcyoomme

28.  Edit the /etc/ssh/sshd_config file
 Add default Ciphers and KexAlgorithms in preferred
order
Restart the sshd service
runcyoomme

29. Check the Ciphers and Key Exchange Algorithms
now…

30. YAYYY!!!

31. Hardening #3 – Load Balancer:
TLS 1.0 and TLS 1.1 that have weak cipher suites
are set as the default when provisioning Elastic
Load Balancers

32. Confirming the presence of weak cipher
suites

33.  Select a stricter and recent security policy for the ELB
Solution:
 Force the latest ‘security policy’ on the Elastic Load
Balancer, instead of the default lenient one
 Navigate to Load Balancer (EC2)  Listeners (tab)
 Edit
runcyoomme

34. Reference chart
of security
policies with
SSL Options
and Ciphers
Reference:
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-

35. Changes are reflected
immediately on re-running a
vulnerability scan

37. Hardening #4 – DNS Security:
Certificates generated by ACM or Google Trust
Services and managed by Route53 or Cloud DNS
does not force create a ‘CAA’ record to prevent re-
issuance

38. Solution:
Create an entry in Route 53 for CAA when
certificates are issued by Amazon Certificate
Manager (ACM)
Equivalent entry to be created in Cloud DNS for CAA
record when certificates are issued by Google Trust
Services
Re-run a SSL scan (Qualys online SSL should be
sufficient)
runcyoomme

40. Hardening #5 – API Gateway:
AWS API Gateway by default, provides
support for TLS 1.0 and TLS 1.1 with weak
cipher suites

41.  Pick and choose the minimum required SSL for CloudFront
 Select the appropriate security policy for strong cipher
selection
 Create a CloudFront distribution with the ‘Origin Domain
Name’ as the API Gateway stage
Solution:
 Don’t serve the traffic directly from the API Gateway URL
runcyoomme

43. Hardening #6 – Platform (PaaS):
AWS BeanStalk and Google AppEngine supports
TLS 1.0/1.1 and TLS 1.2 with weak cipher suites
by default to ensure backward compatibility with
older clients

44. Solution:
 For AWS BeanStalk, solution would be place it behind a
ELB and attach stricter/recent TLS policy as discussed
previously
 For Google AppEngine, create a
custom policy that supports just
TLS 1.2 and strong cipher suites
 Now attach these with the Cloud
LB which will server traffic for
AppEngine runcyoomme

46. Hardening #7 – Serverless
(FaaS):
Incorrect or non-existent input validations, might
lead to elevated privileges in FaaS configuration
 Sub-process invocation at will from the execution context
 Access function handler of serverless function
 Access to /tmp to manipulate contents during execution time
 Full internet access from within FaaS environment
 Execution of os.system() commands at will

47.  Resources provisioned in cloud reside inside a Virtual
Private Cloud (VPC)
 FaaS should also be provisioned within this SDN
wrapper dictated by network routes/configs/firewall rules

49. Functionality
CV filtering app that accepts
PDF file to perform text
analysis
Assumption
Users will provide legitimate
PDF filenames for processing
Weakness
Filename embedded into shell
for direct shell command
invocations
https://tinyurl.com/infoleaksample runcyoomme
Exploit Example

50. (Sub-process invocation at will from the execution context)
AWS
Lambda
Google Cloud
Function
https://tinyurl.com/faasexploits runcyoomme

51. (Access function handler of serverless function)
AWS
Lambda
(Access to /tmp to manipulate contents during execution time)
Google Cloud
Function
https://tinyurl.com/faasexploits

52. Let’s do some “Monkey Patching”
What?
Technique to dynamically
update the behavior of a piece
of code
Why?
Extend the behavior of modules,
classes or methods without
actual modification of source
code
When?
• Extend or modify behavior at
runtime of libraries/methods
• During testing to mock
behavior of libs, modules,
objs
• Quickly fix issues, if we don’t
have resources to roll proper
fix
runcyoomme

53. https://tinyurl.com/faasexploits
 Eclipsed the original
definition of os.system()
with a custom one
 Created a new safe
os.system() which is
known only by us
 Repeat this for other
definitions that are not
required to be
supported for your FaaS
runcyoomme

55. Questions | Comments |
Discussions
runcyoomme
n
https://runcy.
me
roommen