A presentation at the Sydney WebApp meeting for the security stream. Covers some easy to follow examples of more common things found and general recommendations for development teams.
2. Started off doing web-dev, sysadmin, programming
90‟s
Traditional
web-dev
Modern
web-dev
Now
3. Started off doing web-dev, sysadmin, programming
90‟s
Have been doing security research for 10+ years
Traditional Designing/developing custom sec-tech.
web-dev Security assessments (code review, pentesting, etc.)
Consulting related to security defense, etc.
Modern
web-dev
Now
4. Started off doing web-dev, sysadmin, programming
90‟s
Have been doing security research for 10+ years
Traditional Designing/developing custom sec-tech.
web-dev Security assessments (code review, pentesting, etc.)
Consulting related to security defense, etc.
Over the past several years, the term „web‟ has well
and truly changed, and now encompasses:
HTML-based user-interfaces for apps
Mobile phone applications
Modern
Web-based SaaS, web-services, etc.
web-dev
Now ChromeOS, etc.
6. However:
• Text-book vulnerable code (e.g. SQL injection) is not so common
• Flaws are becoming more complicated (or at least abstracted)
7. However:
• Text-book vulnerable code (e.g. SQL injection) is not so common
• Flaws are becoming more complicated (or at least abstracted)
• Showing exploitation of vulnerabilities is useful to illustrate the risk
• But also takes away from explaining how these bugs surface
8. However:
• Text-book vulnerable code (e.g. SQL injection) is not so common
• Flaws are becoming more complicated (or at least abstracted)
• Showing exploitation of vulnerabilities is useful to illustrate the risk
• But also takes away from explaining how these bugs surface
• Vulnerability statistics can be interesting
• But can also be quite misleading
9. Provide example flaws based on recent web-related assessments
Often developers making a small (sometimes understandable) mistake
10. Provide example flaws based on recent web-related assessments
Often developers making a small (sometimes understandable) mistake
Run through several defensive steps
A few processes and mitigation methods to consider
General guidance, recommended reading, etc.
11. Provide example flaws based on recent web-related assessments
Often developers making a small (sometimes understandable) mistake
Run through several defensive steps
A few processes and mitigation methods to consider
General guidance, recommended reading, etc.
I have only have 20 minutes for this, but I‟ll be touching on quite a lot
These slides will be put online with all of the references, links, etc.
Also happy to chat about any of this over a drink
12. Interpretation
• Languages/compilers behaviors and annoying technicalities
Logic Flaws
• Logic issues that don‟t have an immediate security impact
Technology Layers
• How technology layers can have interesting technicalities
Defensive Measures
• Several approaches to help manage webapp risks
16. Technology Functionality Test Cases
PHP & Apache Web Upload & Compile Test
& Linux Execute Binary Case Sets
17. 1. How is the PHP Upload working?
1. How is the uploaded file stored?
2. How are file extensions validated?
Technology Functionality Test Cases 3. …
2. How is it executing the binary?
1. Queued in a database?
2. via PHP popen(), system()?
3. Pushing to other web-services?
4. …
PHP & Apache Web Upload & Compile Test 3. What is returned to the user?
& Linux Execute Binary Case Sets
1. Is user-controlled input correctly
encoded (filename, etc.)
2. …
4. …
21. A few minutes later…
Pop a www-user shell over a reliable
and encrypted channel
Determine the entry-point flaw
Start a white-box code review of the
application
Start a review of the host environment
and surrounding infrastructure
23. Simplified Code The Bug
param is attacker-controlled
param is not explicitly cast as a
numeric value, thus:
param = „0.1‟ = PASS
param = „1.1‟ = FAIL
param = „and hi‟ = FAIL
param = „1.1 and hi‟ = FAIL
param = „0.1 and hi‟ = PASS
Resulting in arbitrary command
execution on the system
24. Simplified Code Explanation
param is attacker-controlled
param is validated as a numeric value
between 0 and 1
param = „0.1‟ = PASS
param = „1.1‟ = FAIL
param = „and hi‟ = FAIL
param = „1.1 and hi‟ = FAIL
param = „0.1 and hi‟ = FAIL
The shellescapearg() function is also
used to escape the argument to popen()
26. This example is a bit dumb, but: The Bug
strcmp() accepts two strings and
returns 0 if they match
The return value of strcmp() is
checked using the type-unsafe equality
operator of „==„
If either parameter is not a string (for
example an array) strcmp() will fail and
return 0/NULL
27. The Fix Explanation
strcmp() accepts two strings and
returns 0 if they match
The return value of strcmp() is
checked using the type-safe equality
operator of „===„
28. A lot of higher level languages are quite lax about data-types
This is dangerous for web-languages and affects many applications
Be explicit and remove assumptions about data-types
29. A lot of higher level languages are quite lax about data-types
This is dangerous for web-languages and affects many applications
Be explicit and remove assumptions about data-types
A common trend is for developers to lower their guard post-validation
“This user-controlled data is now trusted” is a very dangerous assumption
30. A lot of higher level languages are quite lax about data-types
This is dangerous for web-languages and affects many applications
Be explicit and remove assumptions about data-types
A common trend is for developers to lower their guard post-validation
“This user-controlled data is now trusted” is a very dangerous assumption
It can be dangerous hopping between programming languages
Programmers of different backgrounds make various (risky) assumptions
Get proficient at the languages you spend most time in
Every single language has its “gotchas” to be aware of
31. How logic flaws can be much more serious than a security hole
33. The interface performed (adequate) client-side and server-side validations
34. Later on, discovered an (almost) identical interface
35. Later on, discovered an (almost) identical interface
Oh, snap
36. Explanation
Payment
Resource Virtually identical payment resources were
A
implemented separately
Payment One (the lesser visible) resource missed a
Gateway server-side validation for negative sums
Bridge The flaw allowed an attacker to credit an
arbitrary account (i.e. receive money)
Payment
Resource
B
37. “Safe” applications can still suffer from application-specific risks
This was a relatively well written .NET application with minimal security risks
Yet, this single logic bug raised more immediate concern than if I had popped a shell
38. “Safe” applications can still suffer from application-specific risks
This was a relatively well written .NET application with minimal security risks
Yet, this single logic bug raised more immediate concern than if I had popped a shell
The nature of new software functional requirements should be treated with caution
Hacked on components/interfaces without proper system and integration analysis
39. “Safe” applications can still suffer from application-specific risks
This was a relatively well written .NET application with minimal security risks
Yet, this single logic bug raised more immediate concern than if I had popped a shell
The nature of new software functional requirements should be treated with caution
Hacked on components/interfaces without proper system and integration analysis
There are huge risks when critical validation/integration isn‟t centralized
Often has a higher chance of inconsistent validation rules
Makes it more expensive and inefficient to both implement and later fix issues
Less efficient to review critical code when it‟s scattered erratically
41. Data transferring from higher level
A couple of basic examples:
languages down to the OS-level
introduce certain risks
Technicalities such as how NULL bytes
are treated for certain functions affect
almost all languages
.NET/Java
iOS Applications
PHP, …
So far this year have found such
issues in two jobs (.NET and Java)
Arbitrary file write to full server
compromise
42. XSS is very common and affecting
more technologies and devices
UIWebView in iOS, etc.
Many interesting attacks possible
Attacking internal network infra.
Triggering client-side vulnerabilities
Targeted phishing attacks that are
executing specific payloads
Increasingly used for decently
executed targeted attacks
Such as using XSS to own apache.org
43. Secure, Open, Convenient
Pick two
Frameworks are great for many
obvious reasons
It‟s clear frameworks do help limit or
remove certain risks
But there‟s a lot of functionality that‟s
supported and/or exposed
Ruby on Rails is a recent target by
researchers
It will take some time for it to mature
Louis from PentesterLab gave a great
overview on the recent issues
45. Mitigations are about raising the cost
of an attack
Try avoiding things that add an attack
surface (e.g. WAF‟s)
Explicit inbound/outbound network
trusts should be part of provisioning
End-point threats affect almost
everyone these days
Review the DSD‟s Top 35
See what big targets are doing:
Facebook talk from Ruxcon
46. Threat Modeling
It‟s important to spend some time to
think about your potential adversaries
Threats aren‟t just bots and kids
scanning your network and webapps
People focusing on your apps
Social engineering (remote or physical)
Internal staff
(the list goes on...)
A basic way to get started in-house is to
try Microsoft‟s card-game !
47. Unfortunately, it‟s still common for
things to be out of date/vulnerable
Subscribe to a freely available
vulnerability alerting service
Regularly review your external internet
presence and services
Try to lean on auto. updates, or test
with a prod clone with them enabled to
see if things break
If it‟s not essential, don‟t run it
48. During code reviews I usually map out
developer comments
Frequency of comments vs. mood
The use of specific keywords (e.g. XXX,
TODO, dropping the f-bomb)
Instead of venting in code, keep a risk
register for risky/uncertain spots
Have a peer-review process and/or
periodically bring in an external
specialist to help go over it
49. Some basic changes to QA testing can
pick up some low-hanging fruit
Fixing issues internally during
development is a lot cheaper
Lots of excellent resources for learning
and testing, such as PentesterLab.com
There are good guides for different
languages, such as the Ruby guide by
Meder@Google
50. Keep up with research relevant to you,
there‟s new things every day
I develop a tool called „Talkback‟ that
tracks news/research
There are free monthly seminars called
„Ruxmon‟ in Sydney
Consider attending the annual Ruxcon
security conference in Melbourne
51. Bugs happen. It‟s okay.
Dedicate some time to think about:
Your potential threats
How you can introduce security tests
during your development lifecycle
If you get external security people in
Think about what you want to get exactly
Organise it to be as efficient as possible
Remember that:
functionality = attack surface
KISS is a security feature in itself
The devil is in the details