how not to make a hacker friendly application
TRANSCRIPT
www.tothenew.com
How not to make a Hacker friendly application
www.tothenew.com
Table of Contents:1. User input validation:
a. Sql InjectionDiagramVulnerable Code & Common Mistakes
b. Cross Site ScriptingType of XSSCommon Mistakes
c. Unrestricted File uploads Attack Scenario Common Mistakes What fields can be considered as user input? d. Client Side checks and reliability
2. Privacy model:a. IDOR (Insecure direct object reference)b. Privilege escalation
Types of Privilege escalationc. Authorization bypass
3. Infrastructural weaknesses:a. Open ports, really, that's so old schoolb. Credentials are the jackpot…c. Insecure implementations
www.tothenew.com
Why security???
Who will attack me?Are hackers really so much out of work…?
Why will someone attack me?I have nothing to offer….
What the data is actually worth? No one is interested to read my emails, or fb chats…. IMAGE
What all can be hacked?Network, laptops, web apps, mobile apps, routers, DNS….. uffff
Cloud hosting and security?My hosting provider is the GOD OF SECURITY and he has my back….
“I earn so less… I hardly make a living…. why would anyone hack me??”
www.tothenew.com
1. User input:
So, what fields can be considered as user input?
The image above shows a sample POST request.
www.tothenew.com
1. User input validation:
a. Sql injection
● SQL injection is a technique where malicious users can inject SQL commands into an SQL
statement, via web page input.
● Injected SQL commands can alter SQL statement and compromise the security of a web
application.
● The magic string: ’ or 1=1
● A classic example:
SELECT * FROM Users WHERE UserId = ‘105’ or 1=1
---------------------------------------------------------------------------------------------------
Quick Question: SQL injection will not leak any data in case the DB is encrypted. Agree or not? Why?
www.tothenew.com
1. User input validation:
a. Sql injection
Source: ibm.com
www.tothenew.com
1. User input validation:a. Sql injection
Vulnerable Code
Common Mistakes
● Lack of Input Sanitisation
● Absence of Parameterised queries and Stored Procedures
● Dependance upon database or libraries
www.tothenew.com
1. User input validation:
b. Cross Site scripting
● Cross-site scripting (XSS) is a code injection attack that allows an attacker to
execute malicious JavaScript in another user's browser.
● The attacker does not directly target his victim. Instead, he exploits a vulnerability
in a website that the victim visits, in order to get the website to deliver the
malicious JavaScript for him.
● To the victim's browser, the malicious JavaScript appears to be a legitimate part of
the website, and the website has thus acted as an unintentional accomplice to the
attacker.
--------------------------------------------------------------------------------------------
--
https://www.xssexample.com/search?q= >’>”><img src=x onerror=alert(1)>
Quick Question: How is XSS a threat? What can someone do with this?
www.tothenew.com
1. User input validation:
Types of XSS
● Reflected or Non- Persistent XSS
● Stored or Persistent XSS
● DOM Based XSS
---------------------------------------------------------------------------------------------------------------
Quick Question: What is DOM? How can DOM be exploited? How does it affect the application? And how to fix it?
www.tothenew.com
1. User input validation:
Common Mistakes causing Cross Site scripting
● No Input Sanitisation: The application does not check whether the value entered by a user is of the type what it is intended to be.
● No Output Encoding: If a user input is reflected back in the output, and it is not being
encoded, then a malicious user can take advantage of it.
● No Context based Encoding: Sometimes, the application accepts inputs from the user that finally become a part of a script or HTML attribute. If no encoding mechanism has been incorporated, a user may inject script or HTML.
-------------------------------------------------------------------------------------------------
Quick Question: What is a context? How many can you name….?
www.tothenew.com
1. User input validation:
c. Unrestricted File uploads
● Various web applications allow users to upload files. Uploaded files may pose a
significant risk if not handled correctly.
● Attacks using file upload can happen if the Web application is not validating the
file that is being uploaded.
● Attacker tries to upload the file with malicious path or filename so that the server
can execute the file.
------------------------------------------------------------------------------------------
--
Quick Question: How much evil can you think, if you get to upload a php file to a server?
www.tothenew.com
1. User input validation:
c. Unrestricted File uploads
● After successful upload, the attacker tries to find a way to execute his code either on the server side or on the client side.
● Some of the file uploads exploits may happen as:
● Attacker may host malwares, illegal software on the web site.
● Attacker can exploit client side vulnerabilities like Cross-Site Scripting by hosting a script in an HTML file.
● Attacker can exploit the server’s integrity by uploading virus or malicious code that can be executed on the server side.
---------------------------------------------------------------------------------------------
--
Quick Questions: How do you suggest to validate a file upload in your application? Or what else can we do
about it? What all parameters to check?
www.tothenew.com
1. User input validation:
Common Mistakes
● Only Client side validation is used.
● Files are validated only using their extensions and not the content.
● The upload directory have execute permissions.
www.tothenew.com
1. User input validation:
d. Client Side checks and reliability
● Enforcing Client side validation is not reliable at all. ● It is common to see customized client-side input validation implemented within
scripts. Client-side controls of this kind are usually easy to circumvent; it is possible to enter a benign value into the input field in the browser, intercept the validated submission with your proxy(For e.g., Burp Proxy), and modify the data to your desired value.
● Developers must make sure to never trust user input and validate the user entered values at the server side too.
www.tothenew.com
1. User input validation:
Example
As you can see in the image alongside, the quantity of the first product is set to ‘-1’. This was done by bypassing the client side validation using a proxy tool.
Note that this value was not being validated at the server end.
www.tothenew.com
2. Privacy model:a. IDOR (Insecure direct object reference)
● Insecure Direct Object References occur when an application provides direct access to
objects based on user-supplied input. As a result of this vulnerability, attackers can
bypass authorization and access resources in the system directly, for example database
records or files.
● Insecure Direct Object References allow attackers to bypass authorization and access
resources directly by modifying the value of a parameter used to directly point to an
object.
---------------------------------------------------------------------------------------------
--
Quick Question: Can you give me an example of IDOR?
Sample URL: https://www.idorexample.com/userdata/doc/5e072i81nm0as/transaction.aspx
Looks vulnerable?
www.tothenew.com
2. Privacy model:
a. IDOR (Insecure direct object reference)
● Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object.
● Such flaws can compromise all the data that can be referenced by the parameter. Unless
object references are unpredictable, it’s easy for an attacker to access all available data of that type.
● For example, Suppose a user can access his invoice as
http://foo.bar/somepage?invoice=John
Now, if the attacker changes the name in invoice parameter, such as http://foo.bar/somepage?invoice=Jane, he might me able to access the invoice of another user.
www.tothenew.com
2. Privacy model:
b. Privilege escalation
● Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation or changes should have been prevented by the application.
● This is usually caused by a flaw in the application. The result is that the
application performs actions with more privileges than those intended by the developer or system administrator.
www.tothenew.com
2. Privacy model:
● Privilege Escalation can be of two types:
Vertical Privilege Escalation - when it is possible to access resources granted to more privileged accounts (e.g.,acquiring administrative privileges for the application).
Horizontal Privilege Escalation - when it is possible to access resources granted to a similarly configured account (e.g., in an online banking application, accessing information related to a different user).
www.tothenew.com
2. Privacy model: c. Authorization bypass
Authorization Bypass occurs when an unauthorised user is able to access what he cannot normally.
● How do you ensure the session and login? JSESSIONID=absgcfrtena8829nuserid=10983311
● How do you ensure authorization…. ○ Random Paths …??? Really is that it?
● Let’s design a foolproof method of authorization...
www.tothenew.com
3. Infrastructural weaknesses:
● Publicly accessible console (such as Grails)
----------------------------------------------------------------------------------------------------------
Quick Question: What all ports do you block and why? What else do you care to block?
www.tothenew.com
3. Infrastructural weaknesses:
● Publicly accessible Jenkins (or any other CI Tool)
www.tothenew.com
3. Infrastructural weaknesses:
b. Credentials are the jackpot…
● How complex is the credential i.e. password, private key etc.○ What about password policy to administrators?○ How do you create the admin accounts? Or how many does your application has?
● Where are the credentials stored ? i.e. dropbox folder, confluence etc.○ searching GitHub for access key and code
● Let’s guess some passwords.. ○ Ummm…..
● How one access key can make you loose all the money?
www.tothenew.com
3. Infrastructural weaknesses:
c. Insecure implementations: ● Directory listing: logs, backup files, older version of application
www.tothenew.com
3. Infrastructural weaknesses:c. Insecure implementations: ● Directory listing vulnerability in IBM InfoSphere Data Replication
Dashboard (CVE-2012-4861)
www.tothenew.com
3. Infrastructural weaknesses:c. Insecure implementations:
● admin portals: Bruteforcing
The admin portal should only be accessible from certain IP Address (say only from the organization).Publicly accessible admin portal pose a serious threat to the complete infrastructure and all the applications associated with it. Admin portals may be open to brute force attack as it might not have any mechanism to restrict the number of unsuccessful login attempts.
“There is currently a significant attack being launched at a large number of WordPress blogs across the Internet. The attacker is brute force attacking the WordPress administrative portals, using the username “admin” and trying thousands of passwords. It appears a botnet is being used to launch the attack and more than tens of thousands of unique IP addresses have been recorded attempting to hack WordPress installs.”Source: www.mnxsolutions.com
www.tothenew.com
3. Infrastructural weaknesses:
c. Insecure implementations:
● Unprotected/vulnerable sub domains
Domains such as cms.domain.com or cpanel.domain.comA Salesforce subdomain “admin.salesforce.com” used for blogging was affected by a reflected cross-site scripting (XSS) vulnerability that could have been exploited by attackers to distribute malware and carry out phishing attacks.http://www.scmagazine.com/xxs-vulnerability-in-salesforce-subdomain-could-have-been-used-for-malware-distribution/article/432654/
------------------------------------------------------------------------------------------------------------
Quick Question: How do you make sure that no one (out of your team/company) knows about a sub-domain “console.mydomain.com”?
Google search?
www.tothenew.com
3. Infrastructural weaknesses:
c. Insecure implementations:
● Missing headersCORSX-Frame-OptionsX-XSS-ProtectionStrict Transport SecurityContent Security PolicyOrigin Header
www.tothenew.com
3. Infrastructural weaknesses:
c. Insecure implementations: Vulnerabilities in SSH
Vulnerability : CVE-2015-5600
We have servers that use OpenSSH for authentication. Such servers can be exploited to carry out a brute force attack on OpenSSH protocol, making repetitive attempts to login with random passwords.
Preventing Brute Force attacks due to OpenSSH Vulnerability (MaxAuthTries bypass) http://www.tothenew.com/blog/preventing-brute-force-attacks-due-to-openssh-vulnerability-maxauthtries-bypass/
www.tothenew.com
3. Infrastructural weaknesses:
● An auth bypass web vulnerability has been discovered in the official WebComIndia Content Management System 2015Q4.
The vulnerability allows remote attackers to bypass the login mechanism of the web-application to compromise the service.For more details, visit: http://www.securityfocus.com/archive/1/5366484
www.tothenew.com
“Judge a man by his questions rather than by his answers.”
― Voltaire