Europe Cloud Summit - Security hardening of public cloud services

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

|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)

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

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

IT infrastructure & landscape
has undergone a paradigm
shift…

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

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

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

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

Europe Cloud Summit - Security hardening of public cloud services

AWS Security, Identity & Compliance
Services

GCP Security Products &
Capabilities

Shared Responsibility Model In
Cloud

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

Solution: Upgrade to OpenSSH 7.8 or later!

Google Cloud ShellAmazon Linux 2

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

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

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

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

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

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

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

Check the Ciphers and Key Exchange Algorithms
now…

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

Confirming the presence of weak cipher
suites

 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

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

Changes are reflected
immediately on re-running a
vulnerability scan

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

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

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

 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

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

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

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

 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

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

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

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

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

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

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

Europe Cloud Summit - Security hardening of public cloud services

More Related Content

Europe Cloud Summit - Security hardening of public cloud services