geneva information security day - immuniweb...on 1st june 2011, lulzsec exploited sql injections to...

©2011 High-Tech Bridge SA – www.htbridge.ch

Geneva Information Security Day

17 September 2013



# whoami

Frédéric BOURLA

Chief Security Specialist

Head of Ethical Hacking & Computer Forensics Departments

High-Tech Bridge SA

~13 years experience in Information Technologies

GXPN, LPT, CISSP, CCSE, CCSA, ECSA, CEH, eCPPT

GREM, CHFI

RHCE, RHCT, MCP

[[email protected]]


# readelf prez

Slides in English.

Talk in French.

3 rounds of 20’ [not including Q&A] focused on the

offensive angle.

No need to take notes, the whole slides and demos will

be published on High-Tech Bridge website.

Given the very short time and the heterogeneous

attendees, slides will not dive to far in the technique.

Nevertheless, I will also publish an additional low

level and step by step guide for all of you who may be

interested by the technical part of those hacking

principles.


# readelf prez

The first two parts are server-side oriented, whereas

the third one focuses on client-side attacks.

If you missed previous conferences, you can learn more

on server-side attacks here:

https://www.htbridge.com/publications/frontal_attacks_fro

m_basic_compromise_to_advanced_persistent_threat.ht

ml

And here are the slides which introduced client-side

attacks:

https://www.htbridge.com/publications/client_side_threat

s_anatomy_of_reverse_trojan_attacks.html

https://www.htbridge.com/publications/frontal_attacks_from_basic_compromise_to_advanced_persistent_threat.html












https://www.htbridge.com/publications/client_side_threats_anatomy_of_reverse_trojan_attacks.html













Table of contents

0x00 - About me

0x01 - About this conference

0x02 - Round 1: Web Servers vs. SQL Injections

0x03 - Round 2: Web Servers vs. Blind SQL Injections

0x04 - Round 3: Web Users vs. Cross-Site Scripting

0x05 - Conclusion


SQL Injection

On 5th February 2011, the security firm HBGary was

compromised by LulzSec using a SQL Injection in their

CMS-driven website.

On 1st June 2011, LulzSec exploited SQL Injections to

steal coupons, download keys and passwords that were

stored in plaintext on Sony's website, accessing the

personal information of million users.

In July 2012 a hacker group was reported to have stolen

450’000 login credentials from Yahoo!. Those logins were

stored in plain text and were allegedly taken from a Yahoo

subdomain, Yahoo! Voices. The group breached Yahoo's

security by using a “Union-Based SQL Injection”

technique.


SQL Injection

The first step to compromise a server is to find a vulnerability.

For web servers you can rely on the efficiency of ImmuniWeb Self-Fuzzer®, a decision-making tool developed to help people know if they need ImmuniWeb®, the next-generation web application security assessment solution with Software-as-a-Service delivery model.

Basically, ImmuniWeb Self-Fuzzer® is a free Firefox browser extension designed to detect Cross-Site Scripting and SQL Injection vulnerabilities in web applications.

To know more on ImmuniWeb Self-Fuzzer®: https://www.htbridge.com/publications/immuniweb_self_fuzzer_firefox_extension.html

https://www.htbridge.com/immuniweb/

https://www.htbridge.com/publications/immuniweb_self_fuzzer_firefox_extension.html












SQL Injection

While browsing the website, ImmuniWeb Self-Fuzzer®

can silently fuzz GET and POST variables, and even

cookies and URL.

During this first round, we will focus on the SQL Injection.


SQL Injection

1

2

4

3


SQL Injection

1

2

3

4


SQL Injection

So basically SQLi is nothing more than a code injection

technique aimed to alter original queries in order to get

unexpected results and/or remotely collect sensitive

database information.

All fields which can be altered by a visitor do

represent an entry point, such as GET and POST

parameters or even cookies.

A bad sanitization of input data can lead to database

exfiltration, information tampering, website defacement

and even full compromise via arbitrary files download.

There are several types of SQLi. Error-Based SQLi

permit to directly read DBMS’ answers in error messages.

[+] https://www.htbridge.com/vulnerability/sql-injection.html


SQL Injection

The concept for database exfiltration is quite simple.

Usually we begin by identifying the DBMS, in order to

optimize our crafted requests. Here an error message

kindly reveals DBMS and Operating System versions.

Attackers can quickly identify MS SQL Server 2012 on

Windows 7 x64 or Windows Server 2008 R2 x64:


SQL Injection

Then we can enumerate tables on the targeted

database, one table at a time:


SQL Injection

We select the first table to enumerate its columns, one

column at a time… Then the second table, and so on:


SQL Injection

Now that we have the remote database structure, we can

finally extract the records which sounds interesting [or

just dump everything in case of a database theft]:


SQL Injection

Here the attacker can directly read the answer to a query

which was specially crafted to reveal admin account

information:


SQL Injection

The SHA1(password+salt) hash of the first customer can

be broken in only 3 seconds with GPU brute forcing:


SQL Injection

The SHA1(password+salt) hash of the second customer

can be broken in less than 9 minutes:


SQL Injection

And depending on the DBMS we can even upload

arbitrary file and deeply compromise the web server.


SQL Injection


system("pause");

End of 1st round


Table of contents

0x00 - About me





0x05 - Conclusion


Blind SQL Injection

On March 27th 2011, the official homepage for MySQL

[mysql.com] was compromised by a hacker who

exploited a Blind SQL Injection

On June 27th 2013, the hacker group known as

“RedHack” compromised Istanbul Administration Site

and claimed to have been able to erase people's debts

to water, gas, Internet, electricity, and telephone

companies.

This kind of attacks has been known for years, but it is

still widely spread today.


Blind SQL Injection

Sometimes hackers are not so lucky, and the results of

their injections are not forwarded as part of the HTTP

answer.

Invisible results do not necessarily mean that the

injection vulnerability will not be exploitable. If the

webpage displays differently depending on the results

of a logical statement injected into the legitimate SQL

query, then attackers are basically facing boolean

answers, and they can therefore think to try as many

yes/no questions as necessary to achieve the same

exfiltration than with classical Error-Based SQL Injections.

For sure it will be far more time consuming, but it is still

exploitable, and the process can often be automated

once the vulnerability has been uncovered.


Blind SQL Injection

2

3

1

+ Is the first char of DBMS version ‘a’ ?

Original query…

+ Is the first char of DBMS version ‘b’ ? …/… + Is the first char of DBMS version ‘m’ ?

4

No page! No page!

Page OK


Blind SQL Injection

A Y/N question which deserves a negative answer will

create a “page not found” or no page at all:


Blind SQL Injection

A Y/N question which deserves a positive answer will

engender the normal page, based on the initial query:


Blind SQL Injection

So it is just a matter of time [and noisy queries]…


Blind SQL Injection

Even with a quick and dirty DOS script of 20 lines, we

can rudimentary automate our Blind SQLi exploitation:


Blind SQL Injection

And with a more powerful exploitation tool, you can quite

quickly exfiltrate the whole database.


Blind SQL Injection

After a quick fingerprinting, we can enumerate tables:


Blind SQL Injection

And then focus on the columns for a given table:


Blind SQL Injection

And finally we can dump records by selecting the

columns of interest in a given table:

Stealing a remote database can take a few minutes up

to several days, depending on the size of the attacked

database.

Generally, the whole exfiltration only last a few hours

once the SQL Injection has been uncovered.


Blind SQL Injection


system("pause");

End of 2nd round


Table of contents

0x00 - About me





0x05 - Conclusion


Cross-Site Scripting

Samy and Yamanner viruses spread on MySpace and

Yahoo! Mail in 2005 and 2006.

During the second half of 2007, nearly 12’000 websites

were documented by XSSed.org. Most of Switzerland

security companies have been recorded on this

website those last 3 years.

In 2010, Apache.org was compromised through XSS.

Yesterday, High-Tech Bridge reported several XSS on

Nasdaq website [cf. http://www.nydailynews.com/]

This kind of vulnerabilities is not new, but still very

widespread nowadays.

http://www.nydailynews.com/










A Cross-Site Scripting, also known as XSS, is a

vulnerability which permits to inject client-side scripts

into web pages viewer by other users.

This very common vulnerability results once again from

bad inputs sanitization during web page generation, and

it basically occurs when untrusted data is inserted into

HTTP response.

An XSS exploits the user's trust in a given website.

Here we will focus on the most common type of XSS, the

Reflected Cross-Site Scripting.

TinyURL may hide the whole XSS payload. Apache.org

website was compromised this way in 2010. An XSS

permitted to bypass anti-XSRF mechanisms.



1

2

3



In a Reflected XSS, victims are most often enticed to

click on a link embedded in email, something similar to:

http://thetarget.com/blog/tag?tagn=e-commerce%3c%42

%52%3e%3c%42%52%3e%3c%68%33%3e%59.

Here it permitted to inject arbitrary HTML code:



Hackers can inject malware links and other malicious

HTML code, such as an IFRAME which points to a third

party server and reproduce a legitimate portal.

Users may therefore give their credentials to the wrong

server:



Arbitrary code can therefore reach users’ computers,

and potentially open the doors to their kingdom:



Here the victim established the connection to attacker’s

server, who got full control of the compromised host:


Blind SQL Injection



For more information about XSS:

https://www.htbridge.com/vulnerability/cross-site-

scripting.html

And here is a very good publication to understand the

danger of XSS & CSRF:

https://www.htbridge.com/publications/xss_csrf_practical_

exploitation_of_post_authentication_vulnerabilities_in_we

b_applications.html

https://www.htbridge.com/vulnerability/cross-site-scripting.html






https://www.htbridge.com/publications/xss_csrf_practical_exploitation_of_post_authentication_vulnerabilities_in_web_applications.html






Table of contents

0x00 - About me





0x05 - Conclusion


Conclusion

There is no single solution which can bring you safety.

People must carry out security in depth, and therefore add

multiple layers of security controls to significantly reduce the

compromise risk.

Firewalls, HIPS, AV and WAF are nearly mandatory to protect

your front-end servers, but you should definitely schedule

pentests, and sometimes think about carrying out source

code review and/or secure coding training.

Escaping special characters, doing pattern checks and

limiting the permissions on the DB is always a good habit.

On workstations, AV, HIPS, application blockers, browser

sandboxing and NoScript like addons are highly advised, but

companies should also schedule security awareness, Social

Engineering and Trojan horse based pentests.


exit (0);

Your questions are always welcome!

[[email protected]]

geneva information security day - immuniweb...on 1st june 2011, lulzsec exploited sql injections to...

Documents