Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Web Attacks: Essential Attack Tactics

Two hour session walking through WebGoat 7, emphasizing practical grouping of mechanics into tactics.

Fabio Arciniegas

on 15 September 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Web Attacks: Essential Attack Tactics

Web Attacks: Essential Tactics
A walkthrough of key ideas using Webgoat 7.1 Fabio Arciniegas, Infosec 2017
Assuming input is valid
"Overflows"/Size Limits
Modifying parameters in a naive application
2. Abstract mechanics into general concepts
3. Get comfortable with essential tools
1.Understand the Mechanics of Key Attacks
A word about technical setup
This session involves hacking a vulnerable web application.

A copy of that application has been provided for each of you.

We will take 5 minutes to show you how to access it.

Not much theory.
Not a magic show.
Not a list of recipes for power tools.
- Can we speak of reasonable
commonalities across these attacks?

- Is there a hope of defending without
being an expert on every single attack?

A note about Software/Application Security
Web attacks training is only one piece in the Software/Application Security Practice

No one piece is enough. We have to be diligent through out the lifecycle to really prevent issues.
http://softwaresecurity.trendmicro.com when you get a chance

Senior Security Architect at Trend's Infosec. In the 12 years before that, I've worn many hats:

Security consultant for Fortune 500 companies
Project manager, Technical lead
Standards Contributor
Book Author
...so I get the perspective of different roles (why developers want to go code, managers want save time, and consultants want to sell).

My role here, thankfully, is just to cut through the FUD
(Fear Uncertainty Doubt) and make this clear.
A note about me
Parameter manipulation
Magic shows are fun.
...but more about the magician
Power tools are good
...but a lot better when you know what they're doing

We'll look at the basic mechanics, point you to the power tool that automates them. In that order.
A bad habit of making strange lists....
"Animals are divided in beasts, small animals, snakes, worms, fish, birds, and small winged animals.
The crocodile is amongst
the fish."

-Etymologies, Isidore of Seville
We'll try to do better and group by easy-to-remember root causes.
1. Eliminate FUD. You can address the root cause.

2. Translate the ideas to other technologies/scenarios like exploiting a different technology.
Take a moment now to look at the cheatsheet.

If you remember nothing from today except to always look for tactics around those four root issues, you are good.
We will beat ALL the webgoat 7.1 with two prototypical tools.

All solutions are recorded in individual videos for later.
1. A Proxy - OWASP ZAP
2. Browser Debugging - Chrome Dev Tools
Defense Approaches
HTTP Response Splitting
Answer: yes.
Assuming data is just data
Assuming custom security feature has the right properties
Assuming default configuration is good enough
Session Fixation
Insecure Direct References
Session Hijacking
Weak Password Recovery
SQL Injection
SQL Injection: other input vectors, other encodings, same idea
Cross-Site Scripting (XSS)
Stored XSS
Other kinds of injection
XPath queries
LDAP queries
Old timey Server Side Includes
XXE XML External Entities
SSRF (So called "Server Side Request Forgery)
Even DSLs

PHP Partial Objs, SSL conf, Rails Constructors etc. etc. etc.
Authentication with Session ID:
Hijacking a session:
Key property exploited:
ID should be really random.
In this case is not, so we can guess somebody
else's and just submit a request with the
right cookie.
Bypassing HTML field restrictions:
This app relies on hiding an option from the interface.
We modify the parameter in the actual request:
In the webgoat lesson the term buffer overflow is abused a bit. In webgoat the app is just expecting a buffer shorter than 4096 chars and will spew other people's data otherwise.

It's a somewhat artificial lesson but we can use the opportunity to learn the basics about using the fuzzer/generating dynamic payloads:

The classic example is stack traces which expose some of the code structure through an exception.
hardcoded passwords
and keys happen too:
The most common component is a web server of course. Default weak configs can be quickly revealed by scans:
Naturally, many other components will vary
per project.

Weak default configurations must be watched for. Good news is there's always a quick check tool or checklist for it. e.g.
Version 7 of webgoat doesn't have the http splitting lesson but a video of 5.4 (by another party) is provided here:
Interesting to note is encoding:
Play also with "Encoding Basics"
See your cheatsheet, appsec.trendmicro.com, and owasp page.
but because we are in the context of product hack, we will continue here concentrating on attack tactics.

Payloads have been sophisticated and automated to a huge degree. See:
<open zap, we will walk through interface>
<open chrome dev tools, we will walk through interface>
Final Mantras: Summarizing Tactical Attack Mentality
Because people sometimes assume data is valid
- Send invalid data on every input
- Make use of every channel

Because people sometimes assume data is just data
- Inject commands to fit every interpreter the app uses

Because people sometimes make their own security features
- Look for missing properties. A good starting point is feature sets of standard implementations.

Because people allow default configurations and old components
- Identify technologies used, check hardening holes in each

Do not use any of the tools or techniques in any system other than the sandbox provided without written authorization from the owner and the hosting environment.
Command Injection (defacing webgoat)
challenge 3: defacing webgoat
Home made crypto
Two fail modes:
- Making your own (don't)
- Using the wrong primitive (ask)
Which of these do I want to achieve?
- Confidentiality
- Authentication (entity or origin)
- Integrity
- Non-repudiation
Does the primitive/protocol provide it?
e.g. hash of username as sessionid. Good enough?
Had the token not been cryptographically random and unique, finding the next video in the channel would have been no different from our first parameter tampering exercise
Such a tricky guarantee to
The app must generate the
session ids.
Much easier to keep a framework up to date than to implement a safe mechanism.
Home-made password recovery function in webgoat doesn't guarantee a lockout after 3 tries:
Code Disclosure through error messages (debug)
No HTTP ONLY cookies etc.
Integrating checkers and hardening verification on builds
A note for some other time: good practices need not be a one-time check. See More at dev sec ops class. e.g.
No http only cookies and no HTTP header: Content-Security-Policy are the most typical
web server misconfigs
some of you might be thinking
"what good is just sending yourself
many of you might have seen the
typical <script>alert('hi')</script>.
Lets do something more interesting:
To "divide" XSS in these is typical bad taxonomy.
One refers to the fact that the payload is saved, the other that the paylod comes from the Document Object Model rather than a GET/POST parameter.
Other Tools that enhance/automate this idea
Generate payloads:
- Sully, Peach Fuzzing Framework, others
- Microsoft MiniFuzz/Regexp fuzzer
Identify vectors:
- ZAP's, W3AF or any other scanner spider/scan function.

Also: Burp, W3AF, Arachni

Anything that processes instructions.
Defense Approaches
See your cheatsheet, appsec.trendmicro.com, and owasp page.
Other Tools that enhance/automate this idea

arachni, w3af, zap, any other web application
security scanner will do SQL injections and XSS
payloads of all kinds

Tools that automate these ideas
Googling best practices, common misconfigurations given a technology.

Tools to identify technologies:
- Server Side/command line: whatweb
- Client and server: wappalyzer
Throwing tools at the wall to see what sticks is very limited. You want a guiding attacking mentality to identify tactics as they present themselves:
Full transcript