Web application security

1. Rasheed Hussain, PhD
Assistant Professor,
Secure System and Network Engineering
r.hussain@innopolis.ru
https://sites.google.com/site/rasheedinfosec/
Offensive Technologies (OT)
March 30, 2017
Web Application Security
OWASP top 10 (2013)

2.  Motivation
 Causes of data breaches
 OWASP
◦ Top ten attacks
 Now what?
 Do it yourself
 Questions?

3.  In many cases the web application stores:
◦ Credit card details
◦ Personal information
◦ Passwords that also might be used elsewhere
 Media likes hacks
◦ You company doesn’t…
 Governments want to enforce data protection
◦ USA
◦ Russia?
◦ EU will follow soon(?)

4.  Your company
doesn’t like that
Lektober is used as a reference to the
month of October 2011 in which there every
day sensitive data from a federal
government agency, company or
association was announced. The name was
given by the Dutch technology site:
Macworld. The editors of Macworld hacked
the websites of public authorities, business
networks or associations. At the head of the
editorial was Brenno de Winter, Brenno
specializing in IT security and privacy. He
was the leading investigative journalist in
the Lektober project.

6.  Do you share your Phone’s Location Data with
Everyone?
 Do you always stay logged in on social nets?
 Do you log into private services on public
computers?
 Do you share all kinds of data with retailers?
 Do you put too much trust in “secure” apps?
 Do you hook all your online services together?
http://lifehacker.com/how-you-leak-your-privacy-every-day-and-how-to-stop-1547653862

8.  In many cases caused by technical issues:
◦ Poor/no input filtering
◦ Outdated software with known weaknesses
◦ Weak passwords
 Non-techies are creating technical solutions:
◦ Click and play enterprise website
◦ Not aware of security issues
 Techies are also not always aware
◦ What about you?
 In many cases the issues are quite easy to solve
◦ If you know what to do…

9.  The same issues keep on coming back
◦ People make the same mistakes over and over again…
 Open Web Application Security Project (OWASP):
◦ Free and open
◦ Top ten project
 Documents the 10 most critical webapp security flaws
 http://www.owasp.org/index.php/Category:OWASP_Top_Te
n_Project
 Latest version: 2013
◦ Documents solutions
 For all popular webapp environments
https://storage.googleapis.com/google-code-archive-
downloads/v2/code.google.com/owasptop10/OWASP%20Top%2010%20-%202013.pdf

11.  E.g. contact form forwards you to the home page
after submitting your message
◦ http://www.example.com/redirect.jsp?url=/home.htm
 Malicious URLs might be used
◦ http://www.example.com/redirect.jsp?url=malware.com
◦ Download malware from external site after submitting form

12.  Keep your software up-to-date
◦ Patching doesn’t stop at operating system level!
 Database
 Web server
 Libraries
 …
 Lots of automated tools available
◦ Mapping: nmap, …
◦ Scanning: Nessus, Nexpose, …
◦ Exploiting: Metasploit, Canvas, …
◦ Script kiddies can and will do this!

13.  Nmap
◦ Open tcp ports
◦ Open udp ports
◦ OS version
◦ Wildcards
◦ Range
◦ Mask notation

14.  Cross Site Request Forgery (23% by IBM)
 Inject code that:
◦ Runs in the victim’s browser
◦ Open a session to a vulnerable 3rd party service
 Using the victim’s credentials
 Example:
◦ Insert a money transfer in a page
 Forum post
 Email message (phising)
 CSRF made easy!
https://www.youtube.com/watch?v=m0EHlfTgGUU

15.  Server side authorization checks are not
performed on all actions (all functions)
 Attacks:
◦ Escalate from anonymous user to authenticated user
◦ Escalate for authenticated user to admin
 Examples:
◦ If /users/user1/show_accounts/ exists, it might be
worth checking if /users/userN/show_accounts/ also
exists
 Difficult to identify with automated tools

16.  Hidden and unchecked parameter:
◦ Add to POST data when updating a user:
&ctl00%24ContentPlaceHolder1%24dvUser%24cbxUs
erAdmin=on
https://www.youtube.com/watch?v=VMv_gyCNGpk&t=107s

17. Secure transport:
 Sending sensitive information over an
unencrypted link
◦ No encryption / obfuscation
◦ Weak encryption
◦ Downgrade attacks
 Check for no encryption / obfuscation
◦ Sniff data
GET http://target/INSTALL.pgsql.txt HTTP/1.0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Host: target
Proxy-Authorization: Basic YWQxxxxxxxxxxxxxxxxxxxxxxxx=
Connection: Close
Pragma: no-cache
Referer: http://target/robots.txt

18. Secure transport:
 Weak transport encryption
◦ Allowed SSL ciphers
 Known flaws is SSLv2/3
 SSLv2/3 still enabled in many cases
 Weak ciphers can be cracked
 openssl s_client -no_tls1
-connect www.google.com:443 (?)
◦ Weak algorithms
 E.g. MD5, SHA-1
https://mta.openssl.org/pipermail/openssl-
users/2015-December/002399.html

19. Secure transport:
 Downgrade attacks
◦ Strip SSL layer: stripssl
 http://www.blackhat.com/presentations/bh-dc-
09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-
SSL.pdf
 http://www.youtube.com/watch?v=Dd5qGS-5C0I
◦ Hijack e.g. Facebook and Twitter sessions: Firesheep
 http://codebutler.github.com/firesheep/
 http://www.youtube.com/watch?v=O3NAM8oG1WM
◦ IBM’s Appscan (Not Free)
https://www.youtube.com/watch?v=rYlzTQlF8Ws

20.  SSLstrip through hotspot
https://avicoder.me/2016/02/22/SSLstrip-for-newbies/

21.  SSLstrip

22. Secure storage:
 Not encrypting sensitive data
 Using home grown algorithms
 Insecure use of strong algorithms
 Continued use of proven weak algorithms (MD5,
SHA-1, RC3, RC4, …)
 Hard coded keys, and storing keys in
unprotected environments

23.  Real-life example
same passwords
<password>1
<password>2
…
different length
passwords

24.  How to decode the passwords?
◦ Create your own account
◦ Password = ‘aaaaaaaa’
 Store password hash, e.g. 0102030405060708
◦ Password = ‘bbbbbbbb’
 Store password hash, e.g. 0203040506070809
◦ Etc.
◦ Find the link password ↔ hash
◦ Write a decoder
for (i = 0; i < in.length(); i++)
print (alfabet(in.position(i) + i))
◦ Decode all passwords
◦ Dump sensitive information

27.  Out of the box installs
◦ Next, next, next, finish
 Find it using Google:
◦ Web front-end for Oracle
 intitle:iSQL intitle:Release inurl:isqlplus
◦ Indexing of sensitive information
 intitle:"Index of" .mysql_history
 filetype:pdf paspoortnummer koopcontract
 filetype:sql "phpMyAdmin SQL Dump”
◦ Many many useful Google Dorks online
 http://www.hackersforcharity.org/ghdb/

28.  Default passwords
◦ http://www.phenoelit-us.org/dpl/dpl.html

29.  iPhone botnet
◦ Default SSH password after jailbreak
 Routers

30.  User can access and
modify object values
 Example:
◦ Login using your credentials
◦ Link refers to
http://app/details?userid=1
◦ Script download of all files
 userid=[1-9999]
 Hashing doesn’t help
◦ Reverse MD5 hash lookup
◦ http://tools.benramsey.com/md5/

32.  The App uses unverified data in a SQL call
 The attacker modifies the query parameter in
their browser to point to Admin
String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery , � );
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );
http://webapp.com/app/accountInfo?acct=admin

33.  Cross Site Scripting
◦ Attacker can inject untrusted snippets of JS into your
application without validation
◦ JS is then executed by the victim who visits the target
site
◦ 3 types of XSS
 Reflected XSS
 Attacker sends the victim a link to the target app through
email, social media, etc.
 The link has script embedded which executes when target site
is visited
 Stored XSS
 Attacker plants persistent script in target website…

34.  Around 17% of all apps are vulnerable to XSS
according to IBM

35.  Cross Site Scripting Effects
◦ Execute scripts in the victim’s browser
 Hijack user sessions
 Deface web sites
 Insert hostile content
 Conduct phishing attacks
 Take over the user’s browser using scripting malware
◦ In most cases Javascript based
 Also applicable to other scripting languages

36.  Types Revisited
◦ Reflective
 Code injected by e.g. sending phishing email
 victim.com/get.php?id=<script>alert(123)</script>
 E.g. one phishing email per attack
◦ Stored
 Evil code is stored in the database
 Store once, run for all users
 E.g. store <script>alert(123)</script> in record for
welcome message of CMS
◦ DOM-based
 No HTTP request is required, the script is injected as a
result of modifying the DOM of the target site in the
client side code in the victim’s browser and executed

37.  Advanced tools are out there to abuse flaws
◦ Tunnel traffic using XSS
 http://www.portcullis-
security.com/uplds/whitepapers/XSSTunnelling.pdf
 http://www.portcullis-security.com/tools/free/xssshell-
xsstunnell.zip

38.  Prevention
◦ Use vetted libraries or frameworks
◦ Use HttpOnly attribute
◦ Input validation
◦ Demonstration
https://www.youtube.com/watch?v=i38LMZyKIqI

39.  Broken authentication and session management

40.  A vulnerability that allows the capture or bypass
of authentication methods
 Most common authentication
◦ Username and Password
 Approximately 23% of application suffer from
this type of vulnerability

41.  Steps to log in
◦ User provides credentials
◦ Username= john, Password=asdf1234
◦ The information is submitted to the application
◦ Session ID is generated and linked to the credentials
 Sessionid=1gLXXEnpGewaf14LieSDkNVPWL37H7D7Bm

42.  Web apps can fail to protect these values
◦ Unencrypted connections
◦ Predictable Login credentials
◦ Session value does not timeout or does not get
invalidated after logout
◦ User credentials are not protected when stored
◦ Session IDs used in URLs

43.  Predictable sessions IDs allow an attacker to:
◦ Disconnect all users
◦ Hijack existing sessions
 Weak implementations typically use:
◦ Sequential numbers
◦ Hash of sequential numbers
◦ Time elapsed since starting of server / service
◦ Demo
https://www.youtube.com/watch?v=HsExXjBhR0Y

44.  SQL-injection
 Also applicable for other languages
 User input is directly used in a query
◦ Manipulation of database query
◦ User input ‘search’ = alex
◦ Backend uses select details from users where
name=‘alex’
◦ Attacker input ‘search’ = alex’ or 1=1--
◦ Backend uses select details from users where
name=‘alex’ or 1=1
 Display all records

45.  Advanced tools are out there to abuse flaws
◦ File upload
◦ File download
◦ OS command execution
◦ …
 sqlmap
◦ http://sqlmap.sourceforge.net/
◦ http://www.youtube.com/watch?v=ylttGlSkrGU
◦ Tunnel shell over http using SQL-injection!

47.  Example
 Demo (demo.testfire.net)
◦ <% SQLquery=“SELECT * FROM roguetable” Set
Conn=Server.CreateObject(“ADODB.Connection”)Conn.O
pen
“DSN=websql;UID=sa;PWD=pwd;DATABASE=master”
Set rec=Server.CreateObject(“ADODB.RecordSet”)
rec.ActiveConnection=Conn rec.Open SQLquery%>

48.  Example
 Demo (demo.testfire.net)
◦ <% SQLquery=“SELECT * FROM roguetable” Set
Conn=Server.CreateObject(“ADODB.Connection”)Conn.O
pen “DSN=websql;UID=DATA’--
;PWD=pwd;DATABASE=master” Set
rec=Server.CreateObject(“ADODB.RecordSet”)
rec.ActiveConnection=Conn rec.Open SQLquery%>
 Comments
https://www.youtube.com/watch?v=KnQIbyK779I

50.  Detection:
◦ Detection of well-known attacks using IDS
◦ Check web server logs
◦ Check network flows
◦ Difficult to detect all attacks!
 Prevention:
◦ Use good practices
 http://www.owasp.org/index.php/Category:OWASP_Guide_Project
◦ Review and/or test the application before going live
 Source code review
 http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
 Penetration test
 http://www.owasp.org/index.php/Category:OWASP_Testing_Project
 http://www.owasp.org/index.php/Appendix_A:_Testing_Tools

51.  Hacking is not allowed
◦ “Computer Crime Act” (Is there any in Russia?)
◦ Testing without breaking in is also not allowed
 If you want to test your (organization’s) apps:
◦ Use a letter of authorization
 Document the type of activities you will be performing
 Document the IPs that will be tested
 Signed by the system’s owner

52.  More hands on hacking:
◦ Hacking Exposed books
 http://www.webhackingexposed.com/products.html
◦ Certified Ethical Hacker
 https://www.eccouncil.org/certification/certified_ethical_h
acker.aspx