5. Vulnerabilities
+ Change
+ Shortage
Complexity of defending web applications and workloads
Risks are moving up the stack
1. Wide range of attacks at every
layer of the stack
2. Rapidly changing codebase can
introduces unknown vulnerabilities
3. Long tail of exposures inherited
from 3rd party development tools
4. Extreme shortage of cloud and
application security expertise
Web App
Attacks
OWASP
Top 10
Platform /
Library
Attacks
System /
Network
Attacks
Perimeter & end-point security tools
fail to protect cloud attack surface
Web Apps
Server-side Apps
App Frameworks
Dev Platforms
Server OS
Hypervisor
Databases
Networking
Cloud Management
6. Web Application Security
Web Apps
Server-side Apps
App Frameworks
Dev Platforms
Server OS
Hypervisor
Databases
Networking
Cloud Management
7. Web Application Vulnerability Example
CVE-1999-0278 – in IIS, remote attackers can obtain
source code for ASP files by appending “::$DATA” to the
URL
Patch MS98-003
Web Apps
Server-side Apps
App Frameworks
Dev Platforms
Server OS
Hypervisor
Databases
Networking
Cloud Management
9. Hacker Recon Methods
Crawling Target Website
Mass Vulnerability Crawl
Open Forums
Dark Web
Web Apps
Server-side Apps
App Frameworks
Dev Platforms
Server OS
Hypervisor
Databases
Networking
Cloud Management
10. Crawling Target Website
• Manual
- Browse the website as a normal user
- Gather email addresses, related domains and domain info
- Web application code language
o Revision
o Plug-ins
- Web server OS
- User input pages
- Directory structure
- Backend systems
• Software tools
- Find hidden forms, software version, js files, links and comments
11. Mass Vulnerability Crawl - Example
• Google Dorking – (aka Google hacking) Uses the search engine to find
difficult information using complex, detailed search queries
- Plug in search string to find vulnerable websites
- Some have preset search strings
- Search results are dynamic
- Timing is everything
o Target system could be patched
o Other hackers got there first
12. Open Forums - Example
• Vulnerability details
- Date reported
- Type of vulnerability
- Platform impacted
- Author (not shown)
- Verification (time permitting)
- Link to infected application (some)
14. Dark Web
• Encrypted network
• Restricted access between Tor servers and clients
• Collection of DBs and communication channels
• Hidden from conventional search engines
• Shares some features with Open Forums
• Tor browser required
• More advanced resources and tools
16. Attack Methodology
• Attack of opportunity
- Hacker finds vulnerability within skillset
- Target system and organization irrelevant
• Targeted attack
- Specific to people or organization
- System resources
• Low cost of entry
- Open list of vulnerabilities
- Targets easy to find
- Hacker’s skill-set varies
18. Targeted Attacks
• Scanning IP Internet Assets
• Application/Network Vulnerability Scan
• Careers Page
• Research Technologies
• Social Media Profiling
• Phishing Email
• Escalate Privileges
• Maintain Access
• Exfiltration of Data
21. From Web Apps to Privileged Access
• How hacking a web app can lead to system compromise
- Code analysis
o Review of code to reveal unintended system information
- System scanning
o Other software could have vulnerabilities
- Session Hijacking
o Exploiting a current, valid session
- Social Engineering
o Deception used to manipulate behavior
22. From Web Apps to Privileged Access
• Code analysis
- Account information
o Usernames and passwords
o Plain text or hashed
- Software tools
o Web search
o Scan to identify
• Usernames & passwords
o Brute force to crack encryption
o Throttle tools to avoid detection
o Offline may be an option
23. From Web Apps to Privileged Access
• Session Hijacking
- Obfuscated code
o Embedded in images
o Mouse-over techniques
- Proxy replay
- Malicious binary
- Session cookies
- Java script injection
- Cross-site scripting
- Routine system maintenance
- Bind shell
25. Secure Your Code
• Test inputs that are open to the Internet
• Add delays to your code to confuse bots
• Use encryption when you can
• Test libraries
• Scan plugins
• Scan your code after every update
• Limit privileges
• DevSecOps
26. Create Access Management Policies
• Identify data infrastructure that requires access
• Define roles and responsibilities
• Simplify access controls
• Key Management System (KMS)
• Continually audit access
• Start with a least privilege access model
27. Adopt a Patch Management Approach
• Constantly scan all production systems
• Compare reported vulnerabilities to production
infrastructure
• Classify the risk based on vulnerability and
likelihood
• Test patches before you release into production
• Setup a regular patching schedule
• Keep informed, follow bugtraqer
• AMI and Golden Images
• Reference Architecture, Formation Templates
Why are web apps the #1 source of breaches? It starts with the complexity of your app and infrastructure stack. Applications are becoming more complex due to requirements for user and system interaction, the insatiable need for innovative capabilities, and usage of open source and 3rd party libraries. They are continually developed and deployed, and they are no longer ring fenced by traditional firewalls.
Cloud-based applications gain the benefit of sitting within more hardened environments – a good thing for risk reduction.
But as Cloud service providers are tightening, hardening, and integrating controls at the bottom of the stack, attackers are now capitalizing on the paths of least resistance – the more dynamic, more interconnected, more complex apps…that are inherently more exposed. And they are using more sophisticated methods that leverage multiple layers of the stack, and often times use methods that look like legitimate transactions.
Why are these apps hard to protect from the swath of methods used to gain access?
Wide range of attacks at every layer of the stack
Rapidly changing codebase introduces unknown vulnerabilities
Long tail of exposures inherited from 3rd party development tools
Extreme shortage of cloud and application security expertise
Discovery:
(If app audience) Which of these components are in your application portfolio? How often are you scanning and patching vulnerabilities in your components/libraries?
(if opps audience) How often do you assess your application portfolio for exposures in both code and configurations? Are you satisfied that development teams are continually assessing their code and patching/rewriting as new vulnerabilities are published? How are you protecting your applications today?
How often are you releasing new code?
What’s the outlook for your adding staff to secure your application workloads and web apps?
Have portal to have technologies that link to each layer that we cover.
The search results are dynamic, so they are always changing. When an attacker attempts to hack the vulnerable website it’s possible that the website has already installed the patch for this exploit. This is something that can be quickly identified and the hacker can easily move down the list of search results for the next target. It’s also possible that another hacker has already compromised that system and has locked other attackers (and administrators) out of the system. So a major challenge in the hacking community is not only whether they can exploit these vulnerabilities before they are patched, but also whether you can exploit the vulnerability before other hackers.
Discussion behind motivations is important
Risks of deploying Web Applications or using SaaS in the Cloud
Use this slide to tee up Paul and tye an example with detection that matches these stages
Video – This video is an example of a Word Press XML-RPC attack.
Narrative – The attacker checks to see if XML-RPC is enabled (it’s on by default since WP 3.5). The attacker then opens MetaSploit, searches and finds the exploit to run. Runs the command on the target website and brute forces the admin account password, then gains privileged access to the website.
Length – 2:23
Hacking a web application allows an attacker to compromise the functionality of the application, but that doesn’t mean they’ve compromised the system. How can a hacker gain privileged system access by exploiting web applications?
This slide includes a video, for the full version to go: https://alertlogic-my.sharepoint.com/personal/scoty_alertlogic_com/_layouts/15/WopiFrame2.aspx?sourcedoc=%7Be9d0eb83-288d-494c-8fc0-60ee0ebbcf04%7D&action=default
Privilege account information may be in plain text or may be listed in a hashed format. Information about privileged accounts may also be found using a simple web search or using software tools. If usernames and passwords are identified, but they are hashed/encrypted, then brute force software can be used to crack the encryption.
Video – This video is an example of an attacker getting privileged access via remote shell.
Narrative – The attacker starts by using WP Scan (highlights configuration info) to gather system data. The attacker then opens MetaSploit, searches and finds the exploit to run. Runs the command on the target website and brute forces the admin account password. The attacker now runs the exploit using the stolen credentials on the target website. Delivers the payload, finds the open TCP port to communicate with the target website. Starts the session, runs the exploit and gains privileged access using a remote shell.
Length – 3:10
Session hijacking is the exploitation of a current and valid session to gain unauthorized access. There are many types of session hijacking techniques.
This slide includes a video, for the full version to go: https://alertlogic-my.sharepoint.com/personal/scoty_alertlogic_com/_layouts/15/WopiFrame2.aspx?sourcedoc=%7Be9d0eb83-288d-494c-8fc0-60ee0ebbcf04%7D&action=default
User account behavior, system account behavior, network traffic flow baseline