Pfleeger, C. P., Pfleeger, S. L., Margulies, J., Security In Computing, 5th Edition. Pearson, 2015

In this chapter, we look at attacks:

• against browsers
• against and from websites
• seeking sensitive data
• through email

Here we look at specific code that supports user interaction with the Internet, specifically, web browsers. The same potential problems that occur in programs can occur in Internet code, eg malicious code, buffer overflows, and trapdoors.

Internet access does however have its own specific types of security threats and vulnerabilities, and we focus on harm that can happen to a user when they interact with the Internet: in the next section, using a browser.

We all know that a browser is software we use to connect to a web address, display content, and transmit data. Despite this, there can be complications:

• a browser can connect to more than one address at the same time in the same session
• data can be fetched from multiple locations (pictures, audio, videos, ads etc)
• browser software code can be intentionally malicious or hacked
• browsers support extensions and plugins, which can be malicious
• displaying content within a browser uses HTML and CSS which can render, position, layer, and hide elements
• the browser can potentially access any data on a user’s computer
• data transfers are invisible and can happen without the user’s knowledge

Using local software means users have more control over what these apps can access; this is not possible with browsers as users cannot monitor network connections or content; nor can they control what the website they choose to view does.

Browsers expose users to greater security threats than other programs, and browser attacks are common. Secunia released data showing the number of vulnerabilities discovered in popular browsers, shown below:

One interesting point to note is that when vendors release patches, these involve browsers.

4.1 Browser Attacks

There are three attacks that can occur against a browser:

• target the operating system so it will prevent the browser functioning securely
• target the browser itself or one of its components or plugins to alter what they do
• intercept or modify data transferring to or from a browser

Browser Attack Types

It is natural for people to assume that browsers, like a book or television, has a ‘what you see is what you get’ operation, but this isn’t the case: many browsers are transmitting thousands of bits of information a user is not aware of. It is not a case of simply tuning in to a channel. Looking at a website is a bi-directional process, with personal details being potentially exposed.

The following is a list of types of attacks passed through browsers:

Man-in-the browser

A type of man-in-the-middle attack, where a hacker can use malicious code in a user’s browser to read, copy, and redistribute any data a user enters. Man-in-the-browser attacks like Banker are banking trojans, which hide in the browser and wait until a user is logged into their bank account, and then can move funds out of that account and into another. Also known as ‘session hijacking’.

Examples: Gozi, Banker (specifically, SilentBanker), Zeus, SpyEye, Carberp

Online financial transactions are usually protected using encrypted sessions or SSL/HTTPS protocols. Because a man-in-the-middle attack is embedded in the browser, it acts as part of the browser, and can circumvent this process, getting to the data before it is encrypted.

An interesting article on the Zeus Trojan: How the ZeuS Trojan info stealer changed cybersecurity

SSL encryption is applied in the browser; data are vulnerable before being encrypted.

p252

Other Banker malware can display a custom ‘bank login’ which asks the user to type in their banking details: because the URL and UI look authentic, the user types in their credentials meaning the attacker now has this information and can access the user’s bank account at will.

Keystroke logger

A keystroke logger can be hardware connected to or software installed on a computer which tracks a user’s keystrokes – anything typed on the keyboard can then be read by the attacker. Software is more difficult to track, while hardware can be seen plugged in to the computer. Keylogger hardware is more risky as it is highly visible, and means the attacker requires physical access to the computer.

Page-In-The-Middle

A man-in-the-browser attack is an infected browser that captures information presented by the user. A page-in-the-middle is where the user is redirected to another page – say they click ‘login’ and instead of going to the intended site they are sent to the attacker’s web page set up specifically to obtain user’s credentials.

It is relatively simple for a hacker to overlay a legitimate link with a malicious one by changing the webpage’s code, and it would be unlikely the user would check the URL of every page to verify they were on the correct site.

Program download substitution

This can be coupled with a page-in-the-middle attack, where an attacker has a file download on their page that purports to be something the user wants to install: instead, it is malware. This can also happen with legitimate website code which can be hacked and the file location changed, so the user is downloading a malicious file from what appears to be a safe page.

You would think that users have been taught to be wary of downloading software from the web, and only do this from trusted sources. And should a warning message appear, it is very common for users to simply ignore this and download the file regardless.

User-in-the-middle

This type of attack has the innocent user in the middle this time, sandwiched between two automated processes, to enable attackers to sign up for email accounts that can be used to send spam. The attacker ‘tricks’ the user into filling out a CAPTCHA so the attacker can sign up for a free email account:

• the attacker creates an inviting website encouraging users to sign up
• users sign up and are presented with a CAPTCHA (little do they know this is actually a Hotmail or Yahoo CAPTCHA which, once completed, will create a new email account for the attacker)
• the attacker has spliced together an account creation thread into a sign up thread, thereby tricking the email provider into giving them multiple user accounts, verified by multiple strangers

The book references Petmail, where the Design Document details that he has created Petmail with a view to eliminating Spam.

How Browser Attacks Succeed: Failed Identification and Authentication

Human Authentication

Authentication is about confirming somebody is ‘authentic’ by using something they know, are, or possess.

As humans, we use different methods to authenticate each other: a drivers license with a photo, a letter of introduction, a shared secret, or a password. If a person was wearing a police officer’s uniform and hold a valid ID, we can safely assume that person is a police officer. We use judgement to assess if our assumption is correct; for example, if the police officer is not behaving the way we expect, or driving a vehicle that is not a police car, we would consider that authentication to be inadequate. Humans can easily be fooled however.

Human-computer interaction uses many different types of authentication but are limited to the field of usability. Humans are unlikely to remember long complicated passwords for example, or not like to give massive amounts of personal data to authenticate themselves. Techniques such as biometrics and duo-factor authentication look to increase usability and security.

Computer-to-computer authentication is a different matter, as we examine next:

Computer Authentication

When a user interacts with their bank online, the communication is both user-to-browser and computer-to-computer. The bank has authenticated the user, but the user is unable to authenticate the bank. The browser and computer perform an unseen data transfer with the bank’s computer which is not seen by the user, forcing us to simply ‘trust the process’.

Any computer process can be hijacked in the following ways:

• malicious software can save a user’s password
• cryptographic authentication techniques can be corrupted meaning the key can be obtained by an attacker
• software can interfere with the authentication-checking code, thereby compromising authentication

Your bank takes steps to authenticate you, but how can you authenticate your bank?

p258

Initial authentication means that subsequent parts of the process are vulnerable to attack, meaning computers should use continuous authentication, constantly monitoring the exchange for exploits. Without continuous authentication, neither computer can trust the other.

However, once we are logged in to our bank, we then trust the website to perform our needs and keep our data safe, but the user, despite being authenticated by the bank, is unable to authenticate the bank itself. This is how phishing works: users naively input their credentials into false UIs, or give them to impersonators stating to be from their bank, demonstrating attackers can easily pretend to be a system that cannot be authenticated by the user.

Authentication is vulnerable through:

• usability – customers require services to be easy to use, which means weak passwords, simple authentication techniques, etc.
• computer-to-computer interaction is based on stored data: if a user password or key matches that stored or calculated within the system, it can be compromised.
• malicious software such as spyware can intercept authentication data meaning it can be used by the attacker and appear to be legitimate access by the user. Session hijacking can mean attackers can interfere with user’s private sessions once logged in.
• computer interchange needs authentication from both sides, this is also true for human-to-computer interaction

Successful Identification and Authentication

Appealing to everyday human activity gives some useful countermeasures for attacks against identification and authentication.

Shared secret

A shared secret is a piece of information you give your bank to prove your identity, or your email provider when you forget your password. Common ‘shared secrets’ are data like mother’s maiden name, street you grew up on, or name of first pet. A human man-in-the-middle attack can be foiled if you and end user ask questions that only the other person would know: the attacker would not have this information.

To be effective, a shared secret must be something no malicious middle agent can know.

p259

One-time password

A one-time password can only be used once, then it is deleted. The SecurID token generates a new number every minute, meaning you can constantly affirm the connection has not been compromised.

Out-of-band communication

When you request a new credit card from your bank, they will send the card itself and the password in separate envelopes, so should either of these be intercepted, they cannot be used in isolation. Out-of-band is using a different method of communication to the one being used: for example, when spending money, the banking app on your phone may request verification via the app as well as on the card payment machine.

The US Defense Department used to use a secure phone called the STU-III. It was a typical office landline phone, but with a secure transmission function. Once the button is pushed to initialise, the call is then encrypted meaning anyone tapping in is unable to hear the conversation.

Continuous authentication

Despite encryption, it is possible for attackers to enter into a session either before or after the encryption takes place, meaning there is a need for continuous authentication. If a session is constantly encrypted, an attacker would have to break the encryption or cause it to be reset, resulting in users and computers noticing. Encryption does work, but can give a false sense of security.

Encryption can provide continuous authentication, but care must be taken to set it up properly and guard the end points.

p261

4.2 Web Attacks Targeting Users

Web content can be changed by attackers seeking to mislead or harm the viewer, and this can be achieved, respectively, by false or misleading content, and malicious content.

False or Misleading content

It can be difficult to tell if a piece of work is authentic or not: the book cites the controversy over Shakespeare and whether we actually wrote all the works he ‘authored’, and efforts to prove it using computerised analysis of text still continues to this day. This is also how Donald Foster found out Joe Klein wrote Primary Colors. Lying takes some skill, and it is not just fielding questions or disguising your handwriting: your telephone records, bank account records, travel details, nosy neighbours all can prove you’re not telling the truth. See Peter Neumann’s “Primary Colours and computer evidence“.

We can use our primal sense of judgement to decide whether or not a website’s content is true and accurate, however some false content is so accomplished it can be deceiving.

This can be achieved by defacing websites, creating fake websites, and fake code.

How do we protect websites against unauthorised change?

• integrity checksums that can detect altered content on a website, for example Tripwire
• signed code or data – a digital signature from a trusted third party can vouch for the authenticity of a program, update, or dataset
  • However, it is possible for hackers to ‘steal’ valid certificates to sign their malware, see this article about Adobe.

Malicious Web Content

The following are all examples of intent to cause harm by web attackers.

substituted web content – unlike simply defacing a website, actually substituting legitimate downloads for dodgy malware that users then unwittingly install on their computers.

web bug, or tracking bug – a tiny image that collects information on individuals. Similar to an online shop saving a cookie on your computer to recognise you as a repeat customer, a web bug allows this across all sites, and is not harmful but still an invasion of privacy.

clickjacking is where the user expects to click on a button that performs an action, but is tricked into clicking a link that actually does something else, ie, downloads a malicious file, permits access to the web cam and mic, allows a hacker to remotely access the computer etc. Read about a clickjacking attack on Facebook.

drive-by download – when a user visits a webpage and instead of the webpage asking permission to download a file, it automatically does so, without authorisation and usually the user’s knowledge. Eric Howes describes an attack here (p5).

How do we protect against malicious web pages?

Access control is the most basic way to protect users: an administrator on a network can use the least privilege principle, whereby users cannot download unauthorised files. This means people who don’t know any better won’t be fooled into installing malware on their computers. This doesn’t work for sole individuals however who have the means to use administrative privileges: many people do not even read warning popups and simply click ‘allow’ to get on with what they were doing.

Access control achieves SOD (Separation of Duty); this is similar to the concept of OOB communication, where one person sorts invoices and another pays them. This prevents people being tricked or misusing the system.

Website owners also need to be responsible for the content available on their websites. Although the code may be clean on initial upload, the site should be monitored to ensure it has not been corrupted. Secure and safe code is difficult to define and enforce however – we have seen in the exercises that developers often take shortcuts that contain security flaws, and many website owners simply do not have the time to regulate their own code.

User vigilance and common sense can also prevent against malicious code, but alas, it can only reduce the likelihood, because the methods mentioned above can be exceedingly clever and easily trick the user into acceptance.

4.3 Obtaining User or Website Data

Here we examine attacks designed to extract sensitive data. It is more common for bad actors to target web servers rather than individuals as servers hold far more data than one person.

Databases are stored on servers, and are managed by Database Management Systems. DMS use a language called SQL (Structured Query Language) to process commands, and anyone can learn this language.

Injection attacks involve passing SQL commands through the UI to trick the database into revealing sensitive information.

Scripting attacks are where attackers type a malicious script into a web interface to gain access to sensitive information.

Scripting attack: forcing the server to execute commands (a script) in a normal data fetch request

p276

NB: When we talk about ‘executable code’ within data, we actually mean ‘interpretable code’, because SQL is an interpreter, but it is generally accepted that the terms are interchangeable.

Type of Attacks

• Cross-Site Scripting (XSS) – when malicious scripts are injected into ‘safe’ websites and executes on an end user’s computer
  • https://owasp.org/www-community/attacks/xss
• SQL Injection – inserting an SQL query into a data input on a web interface to trick the server into execute otherwise disallowed actions.
  • https://owasp.org/www-community/attacks/SQL_Injection
• Dot-Dot-Slash – otherwise known as path or directory traversal, a user can use the address bar to access files within the public HTML folder.
  • https://owasp.org/www-community/attacks/Path_Traversal
• Server-Side Include – injects scripts into HTML or executes code remotely via dynamic web page elements
  • https://owasp.org/www-community/attacks/Server-Side_Includes_(SSI)_Injection

Website Data: A User’s Problem Too

Foiling Data Attacks

All of the above attacks rely on passing commands disguised as input, and there a few ways in which you can prevent it:

• Use modern web frameworks to build websites, and know it works to prevent XSS attacks.
• Ensure all input goes through validation and sanitisation
• Output encoding changes characters that could be part of an attack into a safe format before being displayed
• Use web vulnerability scanners such as BurpSuite to test your own websites
• Use HTTP Security Response Headers to prevent the browser executing rogue HTML or Javascript code
• Use Content Security Policy (CSP) headers¹ which specifies the origin of content that is allowed to be loaded, preventing unauthorised sources from injecting malicious content.

4.4 Email Attacks

References

1. https://portswigger.net/web-security/cross-site-scripting
2. https://www.imperva.com/learn/application-security/content-security-policy-csp-header/
3. https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
4. https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html