Think Like a Hacker!

How to address and prevent security bugs in your software

Part I – Introduction; Cross-Site Scripting

Presented by: Ron Craig, Dmitriy Beryoza

Authored by: Dmitriy Beryoza, Ron Craig, Chris Shepherd IBM CONFIDENTIAL
IBM X-Force Ethical Hacking Team
 @roncraig
Risks to IBM Software

IBM Confidential
 What if Your Security Defect Became Famous?
• Starting with Heartbleed and Shellshock in 2014
software security bugs are making the news
• Recent WikiLeaks exposure of CIA research into
weaponizing iOS, Android and Samsung TV
security bugs
• Security researchers are trying to cash in on the
fame
• Bugs in security software are sensational (it’s the
software that is supposed to protect you)
• IBM is a target
• Costs to reputation and IBM revenue
• Actual security breaches could lead to litigation,
and law enforcement investigations
• Since 2000 the FTC has issued over 45
consent decrees against companies it ruled failed
to institute sufficient security practices while
delivering software or services. Some decrees
last 20 years!

3 IBM Security IBM CONFIDENTIAL

 What, Me Worry?
A Quick Collection of Facts
• Ponemon Institute estimates a business cost of $141 per lost data record in 2017.
• Average total cost of a data breach in 2017 (Ponemon Study) is $3.62 Million
• 58% of Internet users use the same password for multiple sites, including their web mail
• There is a growing black market for zero-day vulnerabilities. Vulnerabilities sell for
thousands to millions of dollars per exploit, earning hackers some serious coin.
Breaches are old news, but have we learned our lesson?
• Jan 2017 Trend Micro: Two researchers found 223 vulnerabilities in just 6 months.
Massive damage to reputation as a cybersecurity vendor.
• Oct 2017 Equifax: 143 M stolen SSNs. CSO, CIO, CEO all “retire” due to the breach.
• Dec 2013 Target: 40+ M credit cards, 70-110 M name, address, phone, email addresses.
Total cost may reach over $1B in fines and other associated costs.
• March 2011 RSA Security: 40 M auth tokens for bank & gov networks ($66M plus loss)
4 IBM Security IBM CONFIDENTIAL
 IBM Software Targeted *

• Significant increase in the number of 3rd

Trend of 3rd Party & Customer party and customer security reports in the
Reported Issues 2013-2017 period 2013-2017:
̶ 3rd party researcher posts YouTube Video of
defect in IBM Security product
69 ̶ Customer threatens to notify Banking Authority
of Cross-Site Scripting and other vulnerabilities
in IBM Security product
̶ Security SAAS offering targeted by 3rd party
pen-testing company hired by ‘anonymous’
56 customer. Reports Cross-Site Scripting.
Suggests all users notified to change
51 passwords.
• Many of these issues were previously
identified by internal pen-test and not
timely/properly fixed.
38
36
* In this presentation we will use data for IBM
Security products, but situation in other BUs is
2013 2014 2015 2016 2017 similar (or worse)

5 IBM Security IBM CONFIDENTIAL

 How Much is There to Report?

• If security researchers put the entire IBM

portfolio in their crosshairs there would
be plenty of newsworthy material.
• In 2017 over 900 individual high and
medium security defects in IBM Security
Software internally identified by X-Force
Ethical Hacking Team.
• Many defects in legacy code but also
some newly introduced.

6 IBM Security IBM CONFIDENTIAL

 Issue Types

• Majority of IBM Security products

have Web UIs: LMIs,
Administrative Interfaces,
Dashboards
• Web vulnerabilities most
commonly reported by 3rd parties
as well as internal pen-testers with
XSS far in the lead.
• Crypto vulnerabilities come next.
• Appliances highly susceptible to
command execution
vulnerabilities.

7 IBM Security IBM CONFIDENTIAL

 Writing Secure Software is Not Easy

• Developers face many challenges:

Developers
Under time pressures to develop and
Time
test huge amounts of functionality
Have to properly develop and protect a
Focus wide surface of functionality, security is
not the primary focus
Responsible for product’s primary
Motivation and
functionality, often not personally
resources
affected by product successes or failures
Specialize in the functionality of the
Specialization
product
Hackers
May have unlimited time
Concentrate on finding security
holes, often just one vulnerability is
enough to compromise the product
Motivated by bragging rights, illicit
profits, politics; sometimes are
supported by nation-states
Specialize in security penetration

• Yet with good security education, and solid design and implementation
practices, we can make sure our products are secure!

8 IBM Security IBM CONFIDENTIAL

 Mitigating Product Security Risk
• Prevent new bugs

̶ Know your SANS 25 Most Dangerous Programming Errors

(Includes majority of Security BU Top 10).

̶ “Think like a hacker”. How can your code be abused?

̶ Build software defenses into your software: Input Validation, Output

Sanitization, Strong Encryption, Strong Authentication and
Authorization.

̶ Choose secure frameworks rather than simply rely on developer

security skills – people make mistakes, frameworks make sure an
accidental bug does not slip through.

̶ Do not think that if your product is isolated from the Internet it is not at
risk.

̶ Do not think that if a file or a database is local it does not need to be

protected. The majority of breaches are launched from INSIDE.

9 IBM Security IBM CONFIDENTIAL

 Mitigating Product Security Risk (continued)

• Address existing bugs

̶ Redesign product front end not only to be good looking and functional,
but also secure

̶ Implement smart architectural changes that fix security flaws at the top

̶ Do not spot-fix issues, think of how the vulnerability can be fixed

across the board and prevented in the future

̶ Security bugs are special! (because of their potential impact) Fix

bugs as quickly as possible, increase their priority (High=Sev. 1,
Medium=Sev. 2).

̶ Deliver security patches with faster release vehicles.

10 IBM Security IBM CONFIDENTIAL

 We are Here to Help!

• X-Force Ethical Hacking Team and security testing teams in other Business
Units are here to help you in your development work.
• Vulnerability reports are not created to pass blame for security holes.
• Our shared goal is to make all our products secure.

• Reach out to your security testing

team for:

̶ Secure product design consultations

̶ Suggestions on choosing secure
technologies and coding practices
̶ Fix advice and verification

• Ask questions on Slack channels #guild-app-security and #ask-a-hacker.

11 IBM Security IBM CONFIDENTIAL

 @dmitriy.beryoza
Cross-Site Scripting

IBM Confidential
 Cross-Site Scripting (XSS)

13 IBM Security IBM CONFIDENTIAL

 Dangers of XSS

14 IBM Security IBM CONFIDENTIAL

 XSS is “Popular”

• XSS is widespread in 3rd party products:

WordPress Drupal
(source: wpwhitesecurity.com) (source: keycdn.com)

• Occurrences of XSS globally (blue bar):

15 IBM Security IBM CONFIDENTIAL

 XSS in the News

16 IBM Security IBM CONFIDENTIAL

 OWASP Top 10

• Cross-Site Scripting is on OWASP Top 10 list

17 IBM Security IBM CONFIDENTIAL

 SANS Top 25

• Cross-Site Scripting is also at the top of SANS Top 25 list

18 IBM Security IBM CONFIDENTIAL

 Common Scenario

• To demonstrate XSS, suppose we have a web application feature that allows

you to add new users:

• Let’s assume we are using Java Server Pages (JSP) and the rendering code is
as follows:

19 IBM Security IBM CONFIDENTIAL

 Common Scenario (continued)

• Regular data input does not cause any problems:

• Generated HTML:

• Rendered HTML:

20 IBM Security IBM CONFIDENTIAL

 Attack Scenario
• Suppose a malicious user enters the following specially crafted string as user’s
full name:
Joe Hacker<script>alert('GOTCHA!')</script>

• Because the entered value is output as-is the generated HTML will look like
this:

• When HTML is rendered, the script that was embedded in the name is
executed:

21 IBM Security IBM CONFIDENTIAL

 Attack Scenario (continued)

• This looks like a neat trick, but is otherwise harmless, right?

• Wrong! It is actually very dangerous.

• Essentially you are letting unauthorized person inject functionality
into your application.

• The trust that users have for your application now automatically
extends to the malicious code

22 IBM Security IBM CONFIDENTIAL

 Attack Scenario (continued)

• Once the record is added, every time it will be loaded, the dialog box will pop
up

• This is called Stored XSS (more dangerous than Reflected XSS)

• Stored XSS is retained by the application and affects other users (e.g.
application administrator)

• Reflected XSS is usually sent as part of an e-mail or a malicious link, and

affects just one user

23 IBM Security IBM CONFIDENTIAL

 Stealing User Credentials – Fake Login Payload

• Consider a more sinister example. Let’s say the new user record is entered
with the following full name:

Jack Evil<div id="login"

style="position:absolute;top:50%;left:50%; margin-right:-
50%;transform:translate(-50%,-50%);z-index:1;overflow:
auto;padding:10px;border:1px solid
#888;width:160px;height:120px; background-color:white;
"><form><p>Your session has expired, please log
in:</p>Username:<input type="text" name="username"
size="10"/><br> Password: <input type="password"
name="password" size="10"/><br> <br><input type="submit"
value="Login"/><input type="reset"
onclick="document.getElementById('login').style.display='none'
;" value="Cancel"/></form></div>

24 IBM Security IBM CONFIDENTIAL

 Fake Login is Rendered

• We know that this string will be rendered as-is. This is how it will look in UI:

• We now have a serious security issue.

• Every time the list of users is rendered this dialog will be displayed, tricking some users
into entering their credentials.
• The stolen usernames and passwords can then be sent to an external site and used for
further exploitation.

25 IBM Security IBM CONFIDENTIAL

 Preventing XSS with HTML Encoding

• Output Encoding works well for sever side generated pages and is quite effective in neutralizing most
XSS payloads.
̶ HTML Encoding for labels and messages
̶ URL Encoding for values stored in links

Enforcing the Charset

• Some XSS attacks take advantage of rare encodings (e.g. UTF7). If the charset of the page is not enforced the
browser will default to auto detect and XSS payloads will execute.
• HTML Encoding alone will not prevent charset attacks
• To enforce the charset output header: Content-type: text/html; charset=UTF8

26 IBM Security IBM CONFIDENTIAL

 How do we fix our example ?

• The proper way to fix this issue is to use functionality that HTML-encodes the
output:

• In the output the special HTML symbols are now properly encoded:

• When HTML is rendered, the script markup is interpreted as harmless text:

27 IBM Security IBM CONFIDENTIAL

 Preventing XSS with JavaScript Escaping
• XSS can be introduced within JavaScript code as seen in the example below

'-alert(1)-'

• Escaping single quotes will prevent injection:

For example: x=''-alert (1)-'' becomes x='\'-alert (1)-\''

28 IBM Security IBM CONFIDENTIAL

 Preventing XSS by using safe DOM elements

• XSS in modern Rich Client UIs is often made possible by unsafe handling of
the DOM.
• Using the innerHtml attribute allows the user input to be rendered as HTML and
XSS with JavaScript events is possible.

<img src=x onerror=alert(1)>

• The safe alternative is to use textContent ( or innerText in some versions of IE)

29 IBM Security IBM CONFIDENTIAL

 Use Eval and Dynamic Code Generation with Care

• JavaScript eval() function which accepts a JavaScript expression as a string argument

and executes it. Use of this function is discouraged. If it is unavoidable, its parameter
must be carefully scrutinized.
• Same care is needed when the code generates pieces of JavaScript dynamically. This
practice is discouraged.
• For example, the code below will simply execute whatever is provided as the “searchObj”
query parameter:

alert(1)

30 IBM Security IBM CONFIDENTIAL

 Input Validation

• Whitelisting – recommended
̶ Reduces the attack surface to a known quantity
̶ If possible most input should be whitelisted to alphanumeric to prevent XSS (and many other
attacks)
̶ In some cases may be relaxed to allow single quotes or other characters (e.g. to allow input of
names like O’Brien)
̶ Special characters should only be allowed on an exception basis.

• Blacklisting – not recommended

̶ Creative attacker may bypass blacklist by trying a previously unknown method.
̶ OWASP XSS Evasion page should give you a good idea on the staggering number of possible XSS
variations that is impossible to cover by blacklists.

• Client Side Input Validation – not recommended

̶ Can only be used to assist with product usability
̶ Attackers can easily bypass it by sending the request directly to the server.

31 IBM Security IBM CONFIDENTIAL

 Use Proven Validation and Encoding Functionality

• Protect both input and output – “Defense in Depth” principle

• As you validate the input and encode the output use proven,
reputable libraries
• It is preferable not to “roll your own” functionality
̶ It is very easy to make a mistake that does not cover some edge case and
that will render your defense ineffective
• It is best to implement a framework that has one central set of
functionality that validates and encodes data
̶ Peppering your code with checks may lead to some missed unprotected
case that attacker will take advantage of

32 IBM Security IBM CONFIDENTIAL

 Key Takeaways

• DO encode all data output as part of HTML and JavaScript

• DO use strict whitelists on accepting the input
• DO NOT use blacklists or rely on client-side validation
• DO NOT roll your own validation or encoding functionality, rely on
proven libraries

33 IBM Security IBM CONFIDENTIAL

 Do you want to know more?

• For additional training:

̶ SANS (https://www.sans.org/security-training)
̶ OSCP (https://www.offensive-security.com)
̶ WhiteHat Security (https://www.whitehatsec.com)
̶ OpenSecurityTraining (https://opensecuritytraining.info)
̶ Deeper Dive into XSS (https://w3-connections.ibm.com/files/app#/file/a5b98445-149d-4103-8fbb-70b9169ab9b9)

• For more generalized security information, including some defensive techniques:

̶ OWASP (https://www.owasp.org)

• For security-related certifications:

̶ EC-Council Certified Ethical Hacker (https://www.eccouncil.org/programs/certified-ethical-hacker-ceh/)
̶ GIAC (https://www.giac.org/certifications/get-certified/roadmap)
̶ OSCP (https://www.offensive-security.com)
̶ WhiteHat Security (https://www.whitehatsec.com)

34 IBM Security IBM CONFIDENTIAL

 Q&A
• Any questions?

• Feel free to reach out to us:

̶ IBMers from IBM Security contact us on Slack channel #ask-a-hacker

̶ All others can write to us at #guild-app-security

35 IBM Security IBM CONFIDENTIAL

THANK YOU
FOLLOW US ON:

ibm.com/security

securityintelligence.com
xforce.ibmcloud.com

@ibmsecurity

youtube/user/ibmsecuritysolutions

© Copyright IBM Corporation 2016. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express
or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of,
creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these
materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and / or capabilities referenced in these materials may
change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, and
other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks
or service marks of others.

Statement of Good Security Practices: IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise.
Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or
product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are
designed to be part of a lawful, comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective.

IBM DOES NOT WARRANT THAT ANYSYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT
OF ANY PARTY.

IBM CONFIDENTIAL