The document discusses web application security, highlighting the increasing threats and vulnerabilities faced by web apps, particularly in cloud environments. It emphasizes the need for better coding practices, continuous monitoring, and a structured security management approach, including patch management and access control strategies. Additionally, it outlines various hacking methodologies and advocates for integrating security measures throughout the software development lifecycle.

1. WEB APPLICATION SECURITY:
PROTECTING YOUR WEB
APPLICATION
Ryan Holland
Sr. Director, Cloud Architecture

2. Threats by Customer Environment
Source: Alert Logic 2015 Customer Data
48%
23%
21%
2%
6%
CLOUD ATTACKS
APPLICATION ATTACK
BRUTE FORCE
RECON
SUSPICIOUS ACTIVITY
TROJAN ACTIVITY
25%
47%
10%
11%
7%
Brick and Mortar ATTACKS
APPLICATION ATTACK
BRUTE FORCE
RECON
SUSPICIOUS ACTIVITY
TROJAN ACTIVITY

3. Web Apps – Prime Target for Attackers
Source: Cloud Security Spotlight Report 2016 Source: VDBIR 2016
UP 300% SINCE 2014

4. Alert Logic data – Breaking down web app attacks
Source: Alert Logic ActiveWatch analysis Aug 2015 through Dec 2016

5. SQL Injection Last 60 Days

6. 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

7. Web Application Security
Web Apps
Server-side Apps
App Frameworks
Dev Platforms
Server OS
Hypervisor
Databases
Networking
Cloud Management

8. 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. HOW WEB APPLICATION
BECOME VULNERABLE

10. Poor Coding Practices
• Unsanitized Data
- User controlled input
- Web forms
- URL query exposure
• Whitelisting
- Control expected user input
- Accept known, expected data
• Meta-Character Sanitization
- Quotes break up a query
- Names with quotes should be the
exception
Web Apps
Server-side Apps
App Frameworks
Dev Platforms
Server OS
Hypervisor
Databases
Networking
Cloud Management

11. Old Reliable Code and Processes
• Lack of Code Cleanup
- Failed old code
- Decommissioned backend systems
- Account credentials
- Backup systems
- Discovery of application topology (API and static links)
- Unnecessary comments and notes

12. Unpatched and Unsupported Code
• CMS versions are updated
- Vulnerable plug-ins and themes remain
o Still function
o No error codes
o CMS application doesn’t check
• TimThumb Word Press Plug-in
- Library used to resize larger images
- 39 million operational
- Author announced end of support
- Plug-in hacked

13. Lack of Security Oversight
• Security is not longer just advisory
• Inject Security into the SDLC
• Inject Requirements
• Make sure the Technologies are
Secure
• Automatically and Manually review
all code during multiple points
throughout the development
process
• Test, Test, Test
• Continuous monitoring and
scanning

14. HACKER RECON METHODS

15. 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

16. 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

17. 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

18. Google Dork – Example

19. Open Forums
• Vulnerabilities reported to vendors
- Vendors should
o Acknowledge vulnerability
o Provide timeline to fix
o Announce vulnerability to the public
o Provide fix/patch or work-around
o Within a reasonable timeframe
- Some Vendors
o Delay response to reports
o Don’t provide a patch
o Announce vulnerability only to customers
o Bury patches with other “upgrades”

20. Open Forums
• Information sharing
- Researchers post vulnerabilities
o Lack of response from the vendor
o Bypass vendor completely
- Public service to Internet community
o On-going debate
• Bypass the vendors and post vulnerabilities
• Involve the vendor first
o What is a reasonable amount of time
• Some say it should be 24 hours or less
• Some agree to wait 4-6 weeks
• Others somewhere in between
Open forums facilitate vendor due diligence

21. Open Forums - Examples
• Exploit Database - www.exploit-db.com
- A non-profit project that provides a public service to share information
about vulnerabilities and is run by Offensive Security
• Full Disclosure - http://seclists.org/fulldisclosure/
- A public, vendor-neutral forum of vulnerabilities, exploitation techniques
and other events of interest to the community
• Cryptome - https://cryptome.org/
- Collects information about freedom of expression, privacy, cryptology,
dual-use technologies, national security, intelligence, and government
secrecy

22. Open Forums - Example
• Vulnerability details
- Date reported
- Type of vulnerability
- Platform impacted
- Author (not shown)
- Verification (time permitting)
- Link to infected application (some)

23. 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

24. Dark Web - Example

25. ATTACK METHODOLOGIES

26. 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

27. Attacks of Opportunity
• Vulnerability Database Monitoring
• Block Network Vulnerability Scanning
• Google Dorking
• Shodan
• Application Vulnerability Scan

28. 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

29. FROM WEB APPS TO
PRIVILEGED ACCESS

30. 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

31. 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

32. 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

33. REMEDIATION STRATEGIES

34. 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

35. Understand Your Service Providers Security Model

36. Security Management and Monitoring Strategy
• Monitoring for malicious activity
• Scanning Services
• Forensic investigations
• Compliance needs
• System performance
• All sources of log data is collected
• CloudTrail – Use it, Love it.
• WAF
• Correlation logic
• IAM behavior
• IDS Network traffic
• FIM Logs
• Focused security research
• Security content creation
• Review process
• Live monitoring

37. 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

38. 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

39. DevSecOps Release Pipeline Design
• Cloud Insight is a purpose built SaaS platform providing vulnerability
assessment for AWS customers.
• Jinkins and AWS services are used for deployment pipeline.
• Micro-services architecture with several development teams.
• Multiple deployments a week.
• Fully automated deployment pipeline.
• Deployment pipeline consists of 4 environments
• Development
• Integration
• Staging
• Production
• Requirement that vulnerabilities are identified and remediated before
changes push to production.
• Cloud Insight will scan all instances running in Integration every 24
hours.

40. How to Implemented Scanning in the Pipeline
• Scanning a large number of instances takes
time –want to avoid slowing down releases.
• Workflow for Staging environment queries
vulnerability data from scans in Integration.
• Vulnerabilities tracked by AMI, not instance IDs.
• Scan reports are attached to RFCs and stored
in S3.
• Any vulnerability of CVSS > 4.0 triggers a
rollback.
- Scan report with remediation steps are attached to
the report

41. Follow our Research & Stay Informed on the Latest Vulnerabilities
Blog
https://www.alertlogtic.com/resources/blog
Newsletter
https://www.alertlogic.com/weekly-threat-report/
Cloud Security Report
https://www.alertlogic.com/resources/cloud-security-report/
Zero Day Magazine
https://www.alertlogic.com/zerodaymagazine/
Twitter
@AlertLogic
Websites to follow
• http://www.securityfocus.com
• http://www.exploit-db.com
• http://seclists.org/fulldisclosure/
• http://www.securitybloggersnetwork.com/
• http://cve.mitre.org/
• http://nvd.nist.gov/

42. Thank you.