Web Security
SSL
Dr. K. Kulothungan, Assistant Professor(Sr. Gr)
Outline
Web Security Considerations
Secure Socket Layer (SSL) and Transport Layer
Security (TLS)
Secure Electronic Transaction (SET)
Attacks in SSL
Why is the Internet insecure?
Host security
Client
Server (multi-user)
Transmission security
Passive sniffing
Active spoofing and
masquerading
Denial of service
Active content
Java, Javascript, ActiveX, DCOM
C
Eavesdropping
A
Denialofservice
B
C
A
C
B
Interception
C
Replay/fabrication
A
B
C
E-Commerce Security
Authorization, Access Control:
protect intranet from hordes: Firewalls
Confidentiality, Data Integrity:
protect contents against snoopers: Encryption
Authentication:
both parties prove identity before starting transaction:
Digital certificates
Non-repudiation:
proof that the document originated by you & you only:
Digital signature
Certification authority
Web Security Considerations
The WEB is very visible.
Complex software hide many security flaws.
Web servers are easy to configure and manage.
Users are not aware of the risks.
Henric Johnson
Major security issues
Prevent unauthorized users from accessing
sensitive data
Authentication: identifying users to determine if they
are one of the authorized ones
Access control: identifying which resources need
protection and who should have access to them
Prevent attackers from stealing data from
network during transmission
Encryption (usually by Secure Sockets Layer)
Web Application Security
Authentication
Collect user ID information from end users (logging
in)
usually by means of browser dialog / interface
user ID information normally refers to username and
password
Transport collected user ID information to the web
server
unsecurely (HTTP) or securely (HTTPS = HTTP over SSL)
Web Application Security
Authentication
Verify ID and passwd with backend Realms
(security database)
Realms maintain username, password, roles, etc., and can
be organized by means of LDAP, RDBMS, Flat-file, etc.
Validation: the web server checks if the collected user ID &
passwd match with these in the realms.
Keep track of previously authenticated users for
further HTTP operations
What is Secure Sockets Layer (SSL)?
A protocol developed in 1996 by Netscape for
securely transmitting private web documents over
the Internet.
It employs private and public key to encrypt data
thats transmitted over the SSL connection.
By convention, URLs that require SSL connection
start with https: (port 443) instead of http: (port 80).
Web Application Security
10
Why use SSL?
SSL is necessary if
There is a login or sign in (to protect user name
and passwd)
It transmits sensitive data online, such as credit
card information, Banking ID # etc.
You need to comply with privacy and security
requirements
Web Application Security
Source: www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/index.html
11
Use of an SSL Certificate
To enable secured SSL connections, the server needs an
SSL certificate signed by a Certificate Authority (CA).
CA verifies the ID of the certificate owner (e.g., www.hsbc.com.hk)
when an SSL certificate is issued.
Each SSL Certificate contains unique and authenticated
information about the certificate owner, such as ID (in
X.500 format), location, public key, and the signature of
the CA.
It confirms that you are who you say you are in the Internet.
An SSL certificate enables encryption of sensitive
information during online transactions by means of using
hybrid cryptosystem.
Web Application Security
12
A Sample Certificate
This is a certificate issued by Ace CA:
Data
Version: v1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: OU=Ace Certificate Authority, O=Ace Ltd, C=US
Validity: Not Before: Fri Nov 15 00:24:11 1996
Not After: Sat Nov 15 00:24:11 1997
Subject: CN=Jane Doe, O=Ace Industry, C=US
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key:
00:d0:e5:60:7c:82:19:14:cf:38: F7:5b:f7:35:4e:14:41:2b:ec:24:
33:73:be:06:aa:3d:8b:dc:0d:06: 35:10:92:25:da:8c:c3:ba:b3:d7:
lf:1d:5a:50:6f:9a:86:53:15:f2: 53:63:54:40:88:a2:3f:53:11:ec: 68:fa:e1:f2:57
Public Exponent: 65537 (0x10001)
Signature
Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
12:f6:55:19:3a:76:d4:56:87:a6: 39:65:f2:66:f7:06:f8:10:de:cd:
1f:2d:89:33:90:3d:a7:e3:ec:27: ac:e1:c0:29:c4:5a:69:17:51:dc:
1e:0c:c6:5f:eb:dc:53:55:77:01: 83:8f:4a:ab:41:46:02:d7:c8:9a: fe:7a:91:5c
In Real World
In Real World
In Real World
In Real World
How SSL Works?
Good video tute at http://www.viddler.com/explore/sdennis/videos/5/
SSL handshake
Browser connects to SSL port 443 on the web server, and Hello msg
exchange btn browser & server on key-exchange, encrypt alg, etc
Web server sends back its SSL certificate. Web browser decides if it
wants to trust the web servers SSL certificate
Web Browser
Web browser and web server both calculate a session key by agreed
key-generation method
Web browser and web server negotiate an encryption cipher
Web Server
Web browser and web server exchange information encrypted by the
session key and the agreed encryption algorithm
More details at https://ssl.trustwave.com/support/support-how-ssl-works.php
18
CA Root Certificate
Web browser needs the root certificate of the CA that issued the
SSL certificate to the web-server to verify if the web server is
trustable.
If the browser does not have/trust the CA root certificate, most web
browsers will warn you
Web Application Security
19
Steps to Enable SSL in Apache Tomcat
1.
Obtain an SSL certificate for Apache Tomcat from a CA.
https://knowledge.verisign.com/support/ssl-certificatessupport/index?page=content&id=AR227
2.
Install CAs root certificate and Apache Tomcats SSL certificate to
Apache Tomcats keystore.
https://knowledge.verisign.com/support/ssl-certificatessupport/index?page=content&id=AR234
3.
Set up SSL parameters (port #, count, timeout, etc) by adding
<Connector scheme="https" secure="true">...</Connector>
XML block in conf/server.xml.
https://knowledge.verisign.com/support/ssl-certificatessupport/index?page=content&id=SO5306
Web Application Security
20
What is SSL/TLS?
Transport Layer Security protocol, version 1.0
De facto standard for Internet security
The primary goal of the TLS protocol is to provide privacy and
data integrity between two communicating applications
In practice, used to protect information transmitted between
browsers and Web servers
Based on Secure Sockets Layers protocol, ver 3.0
Same protocol design, different algorithms
Deployed in nearly every Web browser
SSL / TLS in the Real World
Application-Level Protection
applicati
on
presentati
on
sessio
n
transpo
rt
networ
k
data
link
physic
al
email, Web,
NFS
RP
C
TC
P
IP
802.1
1
Protects against application-level
threats (e.g., server
impersonation), NOT against IPlevel threats (spoofing, SYN flood,
DDoS by data flood)
History of the Protocol
SSL 1.0
Internal Netscape design, early 1994?
Lost in the mists of time
SSL 2.0
Published by Netscape, November 1994
Several weaknesses
SSL 3.0
Designed by Netscape and Paul Kocher, November 1996
TLS 1.0
Internet standard based on SSL 3.0, January 1999
Not interoperable with SSL 3.0
TLS uses HMAC instead of MAC; can run on any port
Request for Comments
Network protocols are usually disseminated in
the form of an RFC
TLS version 1.0 is described in RFC 2246
Intended to be a self-contained definition of the
protocol
Describes the protocol in sufficient detail for readers
who will be implementing it and those who will be
doing protocol analysis
Mixture of informal prose and pseudo-code
TLS Basics
TLS consists of two protocols
Familiar pattern for key exchange protocols
Handshake protocol
Use public-key cryptography to establish a shared
secret key between the client and the server
Record protocol
Use the secret key established in the handshake
protocol to protect communication between the
client and the server
We will focus on the handshake protocol
SSL Protocol Architecture
SSL
Handshake
Protocol
SSL
Change
Cipher
Spec
Protocol
SSL Alert
HTTP, other
Protocol
apps
SSL Record
Protocol
TCP
SSL/TLS Handshake Protocol
Two parties: client and server
Negotiate version of the protocol and the set of
cryptographic algorithms to be used
Interoperability between different implementations of
the protocol
Authenticate server and client (optional)
Use digital certificates to learn each others public
keys and verify each others identity
Use public keys to establish a shared secret
SSL Handshake
Client hello
Server hello
Present Server Certificate
*Request Client Certificate
Server Key Exchange
Client
Client Finish
*Present Client Certificate
Client Key Exchange
*Certificate Verify
Change Cipher Spec
Server Finish
Change Cipher Spec
Application Data
Server
Handshake Protocol Structure
ClientHello
ServerHello,
[Certificate],
[ServerKeyExchange],
[CertificateRequest],
ServerHelloDone
[Certificate],
ClientKeyExchange,
[CertificateVerify]
switch to negotiated cipher
Finished
Record of all sent and
received handshake
messages
switch to negotiated cipher
Finished
ClientHello
ClientHello
Client announces (in plaintext):
Protocol version he is running
Cryptographic algorithms he
supports
ClientHello (RFC)
Highest version of the
protocol supported by the
client
struct {
ProtocolVersion client_version;
Session id (if the client
Random random;
wants to resume an old
session)
SessionID session_id;
Set of cryptographic
algorithms supported by the
RSA or DiffieCipherSuite cipher_suites; client (e.g.,
Hellman)
CompressionMethod
compression_methods;
} ClientHello
ServerHello
Versionc, suitec, Nc
ServerHello
Server responds (in plaintext) with:
Highest protocol version
supported by
both client and server
Strongest cryptographic suite
selected
from those offered by the client
ServerKeyExchange
Versionc, suitec, Nc
Versions, suites, Ns,
ServerKeyExchange
Server sends his public-key
certificate
containing either his RSA, or
his Diffie-Hellman public key
(depending on chosen crypto suite)
ClientKeyExchange
Versionc, suitec, Nc
Versions, suites, Ns,
sigca(S,Ks),
ServerHelloDone
ClientKeyExchange
Client generates some secret key
material
and sends it to the server encrypted
with
the servers public key (if using RSA)
Core SSL 3.0 Handshake
Versionc=3.0, suitec, Nc
Versions=3.0, suites, Ns,
sigca(S,Ks),
ServerHelloDone
{Secretc}Ks
If the protocol is correct, C and S share
some secret key material (secretc) at this point
switch to key derived
from secretc, Nc, Ns
switch to key derived
from secretc, Nc, Ns
Core SSL 3.0 Handshake
(Contd)
The book shows the above protocol which is the same as the protocol
in the previous slide. Find out the correspondence between the
different notations that denote the same thing in these two protocols.
Version Rollback Attack
Versionc=2.0, suitec, Nc
Server is fooled into thinking
he is communicating with a
client who supports only SSL
2.0
Versions=2.0, suites, Ns,
sigca(S,Ks),
ServerHelloDone
{Secretc}Ks
C and S end up communicating using SSL 2.0
(weaker earlier version of the protocol that
does not include Finished messages)
SSL 2.0 Weaknesses (Fixed in 3.0)
Cipher suite preferences are not authenticated
Cipher suite rollback attack is possible
Truncation attack
Weak MAC construction
MAC hash uses only 40 bits in export mode
No support for certificate chains or non-RSA algorithms,
no handshake while session is open
Chosen-Protocol Attacks
Why do people release new versions of security
protocols? Because the old version got broken!
New version must be backward-compatible
Not everybody upgrades right away
Attacker can fool someone into using the old, broken
version and exploit known vulnerability
Similar: fool victim into using weak crypto algorithms
Defense is hard: must authenticate version early
Many protocols had version rollback attacks
SSL, SSH, GSM (cell phones)
Version Check in SSL 3.0
Versionc=3.0, suitec, Nc
Versions=3.0, suites, Ns,
sigca(S,Ks),
Embed version
number into
secret
{Versionc,Secretc}Ks
ServerHelloDone
Check that received version is
equal to the version in ClientHello
If the protocol is correct, C and S share
some secret key material secretc at this point
switch to key derived
from secretc, Nc, Ns
switch to key derived
from secretc, Nc, Ns
SSL/TLS Record Protection
Use symmetric keys
established in handshake proto
SSL Handshake Protocol Additional Features
SSL Handshake Protocol supports session
resumption and ciphersuite re-negotiation
Allows authentication and shared secrets to be reused
across multiple connections.
Eg, next webpage from same website.
Allows re-keying of current connection using fresh
nonces.
Allows change of ciphersuite during session.
ClientHello quotes old SessionID.
Both sides contribute new nonces, update secretc.
All protected by existing Record Protocol.
Session resumption
Public key operation is avoided
Other SSL Protocols
Alert protocol.
Management of SSL session, error messages.
Fatal errors and warnings.
Change cipher spec protocol.
Not part of SSL Handshake Protocol.
Used to indicate that entity is changing to recently agreed
ciphersuite.
Both protocols run over Record Protocol (so peers of
Handshake Protocol).
SSL/TLS Applications
Secure e-commerce using SSL/TLS.
Client authentication not needed until client decides to buy
something.
SSL provides secure channel for sending credit card
information.
Client authenticated using credit card information, merchant
bears (most of) risk.
Wildly successful (amazon.com, on-line supermarkets,)
Some famous disasters (boo.com, webvan), nothing to do with
security though.
SSL/TLS Applications
Secure e-commerce: some issues.
No guarantees about what happens to client data (including
credit card details) after session: may be stored on insecure
server.
Does client understand meaning of certificate expiry and
other security warnings?
Does client software actually check complete certificate
chain?
Does the name in certificate match the URL of e-commerce
site? Does the user check this?
Is the site the one the client thinks it is?
Is the client software proposing appropriate ciphersuites?
SSL/TLS Applications
Secure electronic banking.
Client authentication may be enabled using client
certificates.
Issues of registration, secure storage of private keys,
revocation and re-issue.
Otherwise, SSL provides secure channel for sending
username, password, mothers maiden name,
What else does client use same password for?
Does client understand meaning of certificate expiry and
other security warnings?
Is client software proposing appropriate ciphersuites?
Enforce from server.
Some SSL/TLS Security Flaws
(Historical) flaws in random number generation for SSL
Low quality RNG leads to predictable session keys.
Goldberg and Wagner, Dr. Dobbs Journal, Jan. 1996.
Flaws in error reporting.
(differing response times by server in event of padding failure and
MAC failure) + (analysis of padding method for CBC-mode) =
recovery of SSL plaintext.
Canvel, Hiltgen, Vaudenay and Vuagnoux, Crypto2003.
Timing attacks.
analysis of OpenSSL server response times allows attacker in
same LAN segment to derive servers private key!
.
Comparing IPsec and SSL/TLS
Both have initial (authenticated) key
establishment then key derivation.
IKE in IPsec
Handshake Protocol in SSL/TLS (can be
unauthenticated!)
Both protect ciphersuite negotiation.
Both use keys established to build a secure
channel.
Comparing IPsec and SSL/TLS
Operate at different network layers.
This brings pros and cons for each protocol suite.
Recall `Where shall we put security? discussion.
Naturally support different application types, can all be used to
build VPNs.
Both practical, but not simple.
Complexity leads to vulnerabilities.
Complexity makes configuration and management harder.
Comparing IPsec and SSL/TLS
Complexity can create computational bottlenecks.
Complexity necessary to give both flexibility and security.
Security of both undermined by:
Implementation weaknesses.
Weak server platform security.
Worms, malicious code, rootkits,
Weak user platform security.
Keystroke loggers, malware,
Comparing IPsec and SSL/TLS
Limited deployment of certificates and
infrastructure to support them.
Especially client certificates.
Lack of user awareness and education.
Users click-through on certificate warnings.
Users fail to check URLs.
Users send sensitive account details to bogus websites
(phishing) in response to official-looking e-mail.
SSL/TLS
Applications
Commerce
Commerce: Exchange of Goods / Services
Contracting parties: Buyer and Seller
Fundamental principles: Trust and Security
Intermediaries:
Direct (Distributors, Retailers)
Indirect (Banks, Regulators)
Money is a medium to facilitate transactions
Attributes of money:
Acceptability, Portability, Divisibility
Security, Anonymity
Durability, Interoperability
E-Commerce
Automation of commercial transactions using
computer and communication technologies
Facilitated by Internet and WWW
Business-to-Business: EDI
Business-to-Consumer: WWW retailing
Some features:
Easy, global access, 24 hour availability
Customized products and services
Back Office integration
Additional revenue stream
E-Commerce Steps
Attract prospects to your site
Positive online experience
Value over traditional retail
Convert prospect to customer
Provide customized services
Online ordering, billing and payment
Keep them coming back
Online customer service
Offer more products and conveniences
Maximize revenue per sale
E-Commerce Participants
E-Commerce Problems
Snoope
r
Unknown
customer
Unreliable
Merchant
E-Commerce risks
Customer's risks
Stolen credentials or password
Dishonest merchant
Disputes over transaction
Inappropriate use of transaction details
Merchants risk
Forged or copied instruments
Disputed charges
Insufficient funds in customers account
Unauthorized redistribution of purchased items
Main issue: Secure payment scheme
Electronic payments: Issues
Secure transfer across internet
High reliability: no single failure point
Atomic transactions
Anonymity of buyer
Economic and computational efficiency: allow
micropayments
Flexiblility: across different methods
Scalability in number of servers and users
E-Payments: Secure transfer
SSL: Secure socket layer
below application layer
S-HTTP: Secure HTTP:
On top of http
S-HTTP: Secure HTTP
Application level security (HTTP specific)
"Content-Privacy-Domain" header:
Allows use of digital signatures &/ encryption
Various encryption options
Server-Browser negotiate
Property: cryptographic scheme to be used
Value: specific algorithm to be used
Direction: One way/Two way security
Secure end to end protocols
E-Payments: Atomicity
Money atomicity: no creation/destruction of money
when transferred
Goods atomicity: no payment w/o goods and
viceversa.
Eg: pay on delivery of parcel
Certified delivery: the goods delivered is what was
promised:
Open the parcel in front of a trusted 3rd party
Anonymity of purchaser
Payment system types
Credit card-based methods
Credit card over SSL
First Virtual
SET
Electronic Cheques
NetCheque
Anonymous payments
Digicash
CAFE
Micropayments
SmartCards
Encrypted credit card payment
Set secure communication channel between buyer and
seller
Send credit card number to merchant encrypted using
merchants public key
Problems: merchant fraud, no customer signature
Ensures money but no goods atomicity
Not suitable for microtransactions
First virtual
Customer assigned virtual PIN by phone
Customer uses PIN to make purchases
Merchant contacts First virtual
First virtual send email to customer
If customer confirms, payment made to merchant
Not goods atomic since customer can refuse to pay
Not suitable for small transactions
Flood customers mailbox, delay merchant
Cybercash
Customer opens account with cybercash, gives
credit card number and gets a PIN
Special software on customer side sends PIN,
signature, transaction amount to merchant
Merchant forwards to cybercash server that
completes credit card transaction
Pros: credit card # not shown to server, fast
Cons: not for microtransactions
SET:Secure Electronic Transactions
Merge of STT, SEPP, iKP (IBM (iKP). Mastercard (SEPP). Microsoft and Visa (STT))
Secure credit card based protocol
Common structure:
Customer digitally signs a purchase along with price and
encrypts in banks public key
Merchant submits a sales request with price to bank.
Bank compares purchase and sales request. If price match,
bank authorizes sales
Avoids merchant fraud, ensures money but no goods
atomicity
SET Participants
Henric Johnson
72
Dual Signature
DS E KRc [ H ( H ( PI ) || H(OI))]
73
Payment processing
Cardholder sends Purchase Request
74
Payment processing
Merchant Verifies Customer Purchase Request
75
Payment processing
Payment Authorization:
Authorization Request
Authorization Response
Payment Capture:
Capture Request
Capture Response
76
Electronic Cheques
Leverages the check payments system, a core
competency of the banking industry.
Fits within current business practices
Works like a paper check does but in pure
electronic form, with fewer manual steps.
Can be used by all bank customers who have
checking accounts
Different from Electronic fund transfers
How does echeck work?
Exactly same way as paper
Check writer "writes" the echeck using one of
many types of electronic devices
Gives" the echeck to the payee electronically.
Payee "deposits" echeck, receives credit,
Payee's bank "clears" the echeck to the
paying bank.
Paying bank validates the echeck and
"charges" the check writer's account for the
check.
Anonymous payments
1.Withdrawmoney:
cyrpographicallyencoded
tokens
customer
5.Deposittokenatbank.
Ifdoublespentreveal
identityandnotifypolice
3.Sendtokenafteradding
merchantsidentity
4.Checkvalidityandsendgoods
2.Transformsomerchantcancheck
validitybutidentityhidden
merchant
Problems with the protocol
Not money atomic: if crash after 3, money lost
if money actually sent to merchant: returning to bank
will alert police
if money not sent: not sending will lead to loss
High cost of cryptographic transformations: not
suitable for micropayments
Examples: Digicash
Micropayments on hyperlinks
HTML extended to have pricing details with each
link: displayed when user around the link
On clicking, browser talks to E-Wallet that
initiates payment to webserver of the source site
Payment for content providers
Attempt to reduce overhead per transaction
Micropayments: NetBill
Customer & merchant have account with NetBill server
Protocol:
Customer request quote from merchant, gets quote and
accepts
Merchant sends goods encrypted by key K
Customer prepares & signs Electronic Purchase Order having
<price, crypto-checksum of goods>
Merchant countersigns EPO, signs K and sends both to
NetBill server
NetBill verifies signatures and transfers funds, stores K and
crypto-checksum and
NetBill sends receipt to merchant and K to customer
Recent micropayment systems
Company
Compaq
IBM
France
Telecom
Payment
system
Millicent
Unique
code
mcent
IBM payment
system
Micrommerce
mpay
microm
Smartcards
8-bit micro, < 5MHz, < 2k RAM, 20k ROM
Download electronic money on a card: wallet on a
card
Efficient, secure, paperless, intuitive and speedy
Real and virtual stores accept them
Less susceptible to net attacks since disconnected
Has other uses spanning many industries, from
banking to health care
Mondex
Smart card based sales and card to card transfers
Money is secured through a password and
transactions are logged on the card
Other operation and features similar to traditional
debit cards
Card signs transaction: so no anonymity
Need card reader everywhere
Available only in prototypes
Comparison of SSL V2.0 and V3.0
SSL 2.0 is vulnerable to man-in-the-middle attack. The hello
message can be modified to use 40 bits encryption.
SSL 3.0 defends against this attack by having the last handshake
message include a hash of all the previous handshake message
SSL 2.0 uses a weak MAC construction
In SSL 3.0, the Message Authentication Hash uses a full 128 bits of
key material for Export cipher, while SSL 2.0 uses only 40 bits
86
Comparison of SSL V2.0 and V3.0
SSL 2.0 only allows a handshake at the beginning of
the connection. In 3.0, the client can initiate a
handshake routine any time
SSL 3.0 allows server and client to send chains of
certificate
SSL 3.0 has a generalized key exchange protocol. It
allows Diffie-Hellman and Fortezza key exchange
SSL 3.0 allows for record compression and
decompression
87
Problem Free?
Side channel attack discovered by Swiss Federal Institute of
Technology in Lausanne
http://www.newsfactor.com/perl/story/20843.html
Information leak in encrypted connections. Vulnerable openssl
versions do not perform a MAC computation if an incorrect block
cipher padding is used.
An active attacker who can insert data into an existing encrypted
connection is then able to measure time differences between the
error messages the server sends.
This information can make it easier to launch cryptographic attacks
that rely on distinguishing between padding and MAC verification
errors, possibly leading to extraction of the original plaintext.
88
SSL Attacks
SSLstrip, Slowloris & Scary
SSL Attacks
sslstrip Steals passwords from mixed-mode Web
login pages
Slowloris Denial of Service Stops Apache Web
servers
Scary SSL Attacks--ways to completely fool
browsers
sslstrip
The 15 Most Popular Web 2.0 Sites
1. YouTube
HTTPS
2. Wikipedia HTTP
3. Craigslist
HTTPS
4. PhotobucketHTTP
5. Flickr HTTPS
6. WordPress MIXED
7. Twitter MIXED
8. IMDB HTTPS
The 15 Most Popular Web 2.0 Sites
9. Digg HTTP
10. eHow
HTTPS
11. TypePad HTTPS
12. topix HTTP
13. LiveJournal
Obfuscated HTTP
14. deviantART
MIXED
15. Technorati HTTPS
From http://www.ebizmba.com/articles/user-generated-content
Password Stealing
Medium
ssltrip
Hard
Spoofing Certificates
Easy
Wall of Sheep
Mixed Mode
HTTP Page with an HTTPS Logon Button
sslstrip Proxy Changes HTTPS to
HTTP
To
Internet
HTTPS
HTTP
Target
Using
Facebook
Attacker:
sslstrip
Proxy
in the
Middle
Ways to Get in the Middle
Physical Insertion in a Wired
Network
To
Internet
Attacker
Target
Configuring Proxy Server in the
Browser
ARP Poisoning
Redirects Traffic at Layer 2
Sends a lot of false ARP packets on the LAN
Can be easily detected
DeCaffienateID by IronGeek
http://k78.sl.pt
ARP Request and Reply
Client wants to find Gateway
ARP Request: Who has 192.168.2.1?
ARP Reply:
MAC: 00-30-bd-02-ed-7b has 192.168.2.1
ARP Request
ARP Reply
Client
Gateway
Facebook.com
ARP Poisoning
Attacker
ARP Replies: I
am the
Gateway
Forwarded &
Altered Traffic
Traffic to
Facebook
Client
Gateway
Facebook.com
Demonstration
slowloris
HTTP GET
Send Incomplete HTTP Requests
Apache has a queue of approx. 256 requests
Each one waits approx. 400 seconds by
default for the request to complete
So less than one packet per second is enough
to occupy them all
Low-bandwidth DoS--no collateral damage!
OSI Model
OSI Model
DoS Attack
7 Application
Slowloris Incomplete HTTP Requests
6 Presentation
5 Session
4 Transport
SYN Flood Incomplete TCP Handshakes
3 Network
2 Data Link
1 Physical
Cut a cable
DDoS Attacks in the Wake of French
Anti-terror Demonstrations
DDoS Attacks in the Wake of French Anti-terror Demonstrations
On January 15th, Frances chief information systems defense
official, Adm. Arnaud Coustilliere, announced a sharp rise in online
attacks against French web sites:
Calling it an unprecedented surge, Adm. Arnaud Coustilliere, head
of cyberdefense for the French military, said about 19,000 French
websites had faced cyberattacks in recent days, [1].
As weve done in the recent past for North Korea [2], Hong-Kong [3],
and Israel [4], we can leverage Arbors ATLAS initiative to observe
how real world conflict []
North Korea Goes Offline
North Korea Goes Offline
It was reported earlier today that North Korea was having Internet
connectivity issues.
Given recent events involving Sony Pictures Entertainment (SPE),
these reports are of particular interest. The first question when
you see this type of report is whether its purely a connectivity
issue or whether an attack is behind it. While visibility into North
Korean Internet is quite difficult, we are able to see quite a few
attacks over the last few days.
Demonstration
Scary SSL Attacks
Man in the Middle
To
Internet
HTTPS
HTTPS
Target
Using
https://gmail.com
Attacker:
Cain: Fake
SSL
Certificate
Warning Message
Certificate Errors
The message indicates that the Certificate
Authority did not validate the certificate
BUT a lot of innocent problems cause those
messages
Incorrect date settings
Name changes as companies are acquired
Most Users Ignore Certificate Errors
Link SSL-1 on my CNIT 125 page
Fake SSL With No Warning
Impersonate a real Certificate Authority
Use a Certificate Authority in an untrustworthy
nation
Trick browser maker into adding a fraudulent CA to
the trusted list
Use a zero byte to change the effective domain
name
Wildcard certificate
Impersonating Verisign
Researchers created a rogue Certificate
Authority certificate, by finding MD5 collisions
Using more than 200 PlayStation 3 game consoles
Link SSL-2
Countermeasures
Verisign announced its intent to replace MD5 hashes
(presumably with SHA hashes), in certificates issued
after January, 2009
Earlier, vulnerable certificates would be replaced only if
the customer requested it
Link SSL-4
FIPS 140-1 (from 2001) did not recognize MD5 as
suitable for government work
Links SSL-5, SSL-6, SSL-7
CA in an Untrustworthy Nation
Link SSL-8
Unknown Trusted CAs
An unknown entity was apparently trusted for
more than a decade by Mozilla
Link SSL-9
Zero Byte Terminates Domain Name
Just buy a certificate for Paypal.com\0.evil.com
Browser will see that as matching paypal.com
Link SSL-10
Thank You
[email protected]
