new security issues related to embedded web servers

1

New Security Issues related toEmbedded Web Servers

Eric Vétillard, Trusted Labs

© 2009 Trusted Logic S.A.

All Cards are Servers

3

Card characteristics

Reacts to external requests

▪ a.k.a. APDU command

Is accessible to the attacker

▪ Provided that the attacker has the card handy

▪ A bit more remotely with contactless cards

Of course, most cards use specific protocols


4

Card functions

Store, use, and protect secrets

Store private user data

Authenticate users

Establish secure communication links


How is a Web Server Different ?

6

A Web server is standard

There are many standards to be followed

▪ Protocols: HTTP, HTTPS, SSL, …

▪ Data formats: HTML, XML, CSS, …

▪ Languages: JavaScript, …

Web clients are standardized

▪ Browsers

▪ JavaScript-based AJAX clients


7

A Web server is complex

At least, more complex than a typical card

Several layers of complexity

▪ TCP/IP is more complex than ISO7816-3

▪ Data exchange formats more complex

▪ XML more complex than TLV

▪ Processes often more complex

▪ In particular, GUI provided by the server

But, complexity mostly handled by browser

▪ The server provides a description but no rendering

© 2009 Trusted Logic S.A

8

A Web server is accessible

Most Web servers are on Internet

▪ They are widely accessible by everybody

The most sensitive servers are not

▪ They are on various kinds of Intranets

▪ Think of your SVN servers

▪ Think of your router’s/printer’s internal server

Some servers are local to a device

▪ Only accessible from the device that hosts them


9

An attacker’s point of view

Standard

▪ Good reusability of attack efforts

▪ Widely deployed standard clients are vulnerable

Complex

▪ More complex, more buggy, more vulnerable

Accessibility

▪ Easy to reach and reproduce

▪ Possibility to evade law enforcement


Web attacks

11

What makes a good attack?

A vulnerability

▪ Widely deployed is better

▪ Hard to fix is very good

▪ design flaw vs. implementation flaw

▪ Requiring significant work from developer

Opportunities for exploitation

▪ Stealing/abusing authentication credentials

▪ Compromising users’ machine


12

State-of-the-art

Web attacks are not static

OWASP regularly updates its “Top 10”

▪ Old (under control) attacks are downgraded

▪ New (uncontrolled) attacks are added/upgraded

Let’s look at their latest release

▪ Can they be applied to smart cards?


13

OWASP’s Top 10 Vulnerabilities

Cross-site scripting (XSS)

Injection flaws

Malicious file execution

Insecure direct object reference

Cross site request forgery

Information leakage and improper error handling

Broken authentication and session management

Insecure cryptographic storage

Insecure communications

Failure to restrict URL access


14

A1 – Cross-Site Scripting (XSS)

Cross-site scripting is a subset of HTML injection

▪ XSS allows attackers to execute a script in a browser

Reflected XSS

▪ Returns user-provided data to the same user

▪ Without checking it

out.println(" Successfully added " +

request.getParameter("id") ;


15


Why is this vulnerable?

▪ Because of possible user entries

out.println(" Successfully added " +

request.getParameter("id") ;

<IMG SRC="javascript:alert('XSS');"> ;

<SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT>


16


Stored XSS stores data before to display it back

▪ Potentially to another user (a.k.a. the victim)

▪ Very useful in “social” sites

DOM-based XSS modifies the DOM tree

▪ Usually in combination of Ajax

out.println("New friend added: " +

friend.getParameter("id") ;


17


Recommended countermeasures include

▪ Input validation

▪ Use white-list validation (accept only limited input)

Validate length, type, syntax, business rules, …

▪ Avoid black-list validation, which can be bypassed

▪ Strong output encoding

▪ Encode all user-input directly

▪ Specify the output encoding explicitly

ISO8859-1 or UTF-8

▪ Watch out for canonicalization errors

▪ If possible, use standard library


18


Does it apply to Smart Card Web Servers ?

Yes, it definitely does

▪ Query data will be used by the server

▪ Resources are scarce

Strong requirement for

▪ Input validation

▪ Output canonicalization


19

A2 – Injection flaws

Every interpreter can fall victim of injection flaws

▪ SQL is the most well-known victim

▪ HTML is also very common (see XSS)

▪ Any other interpreter can be attacked

▪ LDAP, XPath, XSLT, OS Command, …

▪ Your own proprietary language

The danger comes from the interpreter itself

▪ Security is orthogonal to Java’s security


21


Recommended countermeasures include▪ Input validation

▪ White lists, no black lists

▪ Use standard libraries if available

▪ Design validation carefully for proprietary frameworks

▪ Make exploits as difficult as possible

▪ Enforce least privilege principles

▪ Avoid detailed error messages

Many countermeasures for specific interpreters▪ SQL is the most common


22


Does it apply to Smart Card Web Servers?

Not really, or not directly

▪ No interpreter, no problem

But … a TLV format is a kind of interpreter

▪ Be careful as soon as data becomes structured

▪ Apply standard countermeasures


23

A3 – Malicious File Execution

The attacker executes a malicious OS command

▪ When runtime.exec() is used

▪ When files are created and/or updated

Small example exploitable on a weak platform

String file = request.getParameter("file") ;

File f = new File(dir + "/"+ file) ;

http://www.example.com/banking?file=../../web.xml


24

A3 – Malicious File Execution


No it doesn’t

▪ Advantage of a “bare metal” implementation

▪ No operating system to be abused

But … there may still be an operating system

▪ Control all interfaces with Web server


25

A4 – Insecure Direct Object Ref

Never expose reference to implementation objects▪ Files, directories, records, keys, etc.

An attacker may modify or abuse such references

String language = request.getParameter("language") ;

ResourceBundle rb = context.getResources("rsrc-"+language);

<select name=“language”>

<option value=“fr”>Français</option>

</select>

int cartId = Integer.parseInt(request.getParameter("cartID");

String query = "SELECT * FROM table WHERE cartID=" + cartId);


26


Recommended countermeasures include

▪ Establish a standard way to refer to app objects

▪ Avoid exposing private object references to users

No primary keys, no filenames

▪ Validate any private object references extensively

An “accept know good” approach is here easy

▪ Verify authorization to all referenced objects

▪ Make sure that input does not contain attack patterns

For instance, “../” and “%00”


27




▪ Think about the “cart Id” example

▪ Short identifiers are likely on smart cards

▪ These identifiers may be easy to guess

Countermeasures are seen as expensive

▪ Map external references to internal ones


28

A5 – Cross Site Request Forgery

Cross-site request forgery steals user privileges

▪ The attacker sends a request from the victim’s browser

▪ The browser will use the victim’s privileges

▪ For instance, if the victim is logged in to a bank

The browser provides some protection

▪ There is a “same origin” policy

▪ It is not possible (easy) to directly steal content

▪ But, requests can be sent and interpreted on server


31

A5 – Cross Site Request Forgery



A few countermeasures are simple enough

▪ Insert random token in URL’s

▪ Re-authenticate for sensitive transactions

▪ More generally, limit the validity of authentication


32

A6 – Information Leakage and Improper Error Handling

Applications frequently use error messages

▪ They often try to be “helpful” for the user

As a result, some information is leaked

▪ Results are often too differentiated

▪ “Wrong username” vs. “Wrong password”

▪ Debugging information is often included

▪ Stack traces

▪ Failed SQL statements


34

A6 – Information Leakage and Improper Error Handling


Yes, but not really

Default output is likely to be scarce

▪ Tools are unlikely to include detailed information

▪ Applications are likely to have simple error mgmt

▪ Debugging code is the most likely culprit

▪ Override errors with standard response


35

A7 – Broken Authentication and Session Management

Many flaws are possible in authentication

▪ We know them quite well

Flaws are often found in ancillary functions

▪ Logout that doesn’t work, password management, no timeout, etc.

Session management is provided by the platform

▪ Don’t try to design one yourself


38

A7 – Broken Authentication and Session Management


Yes, it does

▪ All errors can be done on a card application

Java Card 3.0 provides some tools

▪ They are not sufficient on their own

▪ Be careful if you write authenticators


39

A8 – Insecure Cryptographic Storage

Sensitive data should be stored encrypted

▪ First, the data should actually be encrypted

▪ Then, the cryptography should be efficient

▪ Using well-known, accepted algorithms

▪ Protecting the keys adequately

Sensitive data should be well qualified

▪ Don’t forget some sensitive data

▪ Don’t store data that you don’t need

▪ If you don’t have it, attackers can’t get it


40

A8 – Insecure Cryptographic Storage


Not really, at least for card developers

▪ Java Card 3.0 is not as exposed as other platforms

▪ Many mechanisms are readily accessible

▪ The storage is tamper-proof to some level

Still, some recommendations apply

▪ Use the platform’s algorithms and key storage

▪ Ensure that your encryption cannot be bypassed

▪ Don’t store data unnecessarily


41

A9 – Insecure Communications

Sensitive data should be encrypted

▪ Secure channels need to be used

▪ HTTPS, SSL, TLS, …

Encryption is not sufficient

▪ Session establishment is crucial

▪ Authentication of other party is mandatory


42

A9 – Insecure Communications


Yes it does

▪ SSL may be unusual and hard for smart card guys

▪ Mutual authentication may be hard to get

▪ How can you be sure that your user has actually authenticated you (i.e., that phishing won’t work) ?

▪ All Web designers face the same issues


43

A10 – Failure to Restrict URL Access

Flaws are linked to accessible URLs

▪ Hidden or specials URLs, proposed only to privileged users, but in fact accessible to all users

▪ Pages used during development that perform administrative functions (without authentication)

▪ Sensitive data hidden by “Security through Obscurity”

▪ Out-of-date access control policies

▪ Some pages remain accessible to too many users

▪ Code that evaluates privileges on the client


45

A10 – Failure to Restrict URL Access


Yes, to a certain degree

▪ Smart Card Web Servers are likely to be simple

▪ Less temptation to have “hidden URLs”

▪ But … Smart Card Web Servers may be administered through the Web interface

▪ We can see a chicken and egg problem

▪ There is no “console” on a smart card


Defending Ourselves

47

A Local Server?

A Smart Card Web Server may be local

▪ Basic assumption in SCWS

▪ Not an assumption in Java Card 3.0

Some applications don’t need Web access

▪ Being local greatly reduced the risk of attacks

▪ Physical access becomes a prerequisite

Smart cards may very often be local


48

Basic defenses

Validate input, encode outputs

▪ Standard libraries can’t be directly used

▪ Be ready to sacrifice flexibility for security

Follow recommendations for encoding

▪ Don’t use internal identifiers in the interface

▪ Include random data in URL’s

Follow recommendations for access control

▪ No hidden URL’s

▪ Authenticate user after opening secure channel

▪ …


49

Reproduce Web server architecture

Web servers are not monolithic

▪ They usually are “n-tier” systems

▪ The Web server is the presentation tier

▪ The actual data is on another (Intranet) server

Smart card servlets can be structured

▪ The Java Card firewall guarantees some isolation

▪ Data is best kept outside of the servlet

▪ Attacks then need to be performed through servlet

▪ Management uses a different security policy


Where do we go from here ?

51

Try it out !

When trying SCWS/Java Card 3.0

▪ Think about Web security

▪ Develop appropriate countermeasures

▪ At least, list what you should do

▪ Assess the performance impact

Now, you should realize the problem

▪ Web security is not easy


52

Build reference code ?

The specification is not the right place

▪ Security code is by essence variable

▪ Security code usually is the result of a trade-off

▪ Input validation is much easier if you only accept alphanumerical characters and spaces

Yet, this is not really a competitive area

▪ A broken Web server is bad news for all

Would there be a use for a reference code?

▪ Bring the Web spirit to smart cards


53

Thank you !

Eric Vétillard

[email protected]


new security issues related to embedded web servers

Technology