IP: DIMACS Workshop on Network Threats

[Dave Farber <farber () cis upenn edu>]

From: Dave Millar <millar () pobox upenn edu>
To: farber () cis upenn edu (David Farber)
Date: Sat, 7 Dec 1996 12:40:56 -0500 (EST)




Here are my notes from the workshop.  


Dave


DIMACS Workshop on Network Threats
December 4-6
DIMACS Center for Discrete Mathematics & Theoretical Computer Science
Piscataway, NJ


Peter G. Neumann
A Global Perspective on Network Risks


PGN:  Problems include: systems are not designed with full set of 
requirements in mind: e.g. mid-sixties East Coast power grid failure; 
1980 arpanet outage (4 hours); 1988 Bell AT&T long lines failure.  In 
each case the common denominator was that a flaw at one node propagated 
across the network.  Need to develop a systems-oriented view to get 
there: step one is education.  Has the impression that universities are 
not teaching a systems-level view.  PhD in computer science didn't know 
what software engineering was.  There is no hope for technical panaceas a 
la firewalls, IPV6, etc.  They are just tools.  


Simson Garfinkle:  The only hope is strict liability for vendors and 
credible threat of lawsuits for product liability.


Catherine Meadows
A Representation of Protocol Attacks for Risk Assessment


Problem is that it's difficult to prove quantitative measures of 
security.  Attempted to develop non-quantitative techniques to compare 
vulnerabilities.  Attacks are broken down into components, developed a 
taxonomy of stages.  Successive stages enable following stages resulting 
in a "payoff".  Stages are composed of "atomic actions".  Created a 
graphical shorthand to document attacks.


Yvo Desmedt
Network Security Threats in General


Theory of network reliability says that if u hosts are thought to be 
dishonest, and network is 2u+1 vertex connected, receiver can trust the 
message if he receives more than u+1 identical messages.


If hosts authenticate themselves to adjacent hosts with secret key 
technology, the above would tell you that receiving u+1 messages would 
suffice to authenticate the message.  But if you allow for malicious 
hosts that can spoof routes, u+1 identical messages do not suffice.  


However, if hosts authenticate to adjacent hosts with public key, the u+1 
result holds.


Sarvar Patel
Information Leakage in Encrypted Key Exchange


Encrypted Key Exchange was developed to protect against off-line 
dictionary attacks.  EKE includes random padding to protect against a 
class of information leakage that allowed an attacker to eliminate 
unlikely passwords and find the password with less than an exhaustive 
brute-force attack.  However, the padding method chosen does not make all 
numbers equally probable under decryption, giving an attacker information 
to eliminate unprofitable dictionary guesses.


Also proposed a method of transmitting encrypted primes without leakage.  
Rather than encrypt the prime directly, choose j between the chosen prime 
and the next larger prime.  Encrypt and transmit j.  Then the recipient 
decrypts j and picks next smaller number which is prime.


Adam Shostack
Apparent Weaknesses in the Security Dynamics Client/Server Protocol


F2, SecureID's proprietary hash algorithm, has been reverse engineered 
and is available on some sites.  


Shostack found a weakness in SecureID protocol that allows an attacker to 
authenticate as a SecureID cardholder.  First: SecureID basics:


Secure ID card displays a new password every minute.  User enters the 
time-dependent password and a PIN to a host to authenticate to a host.  
The host is running not a normal login, but a modified login that relies 
on Security Dynamics' authentication server ("Ace Server") to 
authenticate the user.  


Shostack's attack has an intruder sniff a legitimate SecureID 
authentication.  Then, with that information, the intruder is able to 
spoof an authorization to the host from the Ace Server.  Intruder needs 
to know the timestamp on the host and needs to be able to spoof the Ace 
server's IP address for the attack to work.  Security Dynamics has fixed 
the problem.


Shostack also mentioned that Security Dynamics' X11 GUI interface for 
managing the server may be weak, and sys admins may want to only 
administer the system locally with the command line interface.  Also 
observed that SecureID does not protect against session hijacking 
attacks, for which encryption is needed (and encryption only protects 
against attacks between the endpoints - not against active attacks at the 
origin or destination hosts).


RSA/Security Dynamics employee was present and noted that they were in 
the process of re-engineering the protocol from the "ground up" and would 
be publishing their protocols for public scrutiny.  


Audience member noted that there's also a denial of service attack:  
seven bad guesses and the account is suspended.






Shi-Kai Chin
Formal Methods Applied to Secure Network Engineering


Hopes that security may be the killer app that brings formal methods into 
wide acceptance for software/systems engineering.  Problem is that other 
disciplines have better analytic techniques e.g. electrical engineers 
model every circuit as a pole-zero diagram or as the ratio of two 
polynomials.  Software engineering needs a comparable discipline.  He's 
trying Higher Order Logic.


Applied Higher Order Logic theorem prover to RFC 1421 - Privacy Enhanced 
Mail specification (specifically message integrity).  Intent was not to 
test for problems in the underlying encryption algorithms but to test 
that the protocol really delivered on its promise of authentic and/or 
private messages assuming that the underlying algorithms could be 
trusted.  Higher Order Logic "proved" that the intent of the message 
integrity function was satisfied (assuming that the hash algorithm did 
not permit collisions.)


Steve Bellovin asked if this approach would have uncovered a problem with 
an early implementation of PEM (DES in CBC mode).  Not at this level of 
abstraction, but perhaps with a lower level.


Michael Merrit suggested running the theorem prover against the boneyard 
of authentication protocols with known problems to see if a.) the known 
problems could be found, and b.) if new, unknown problems could be turned up.




Jean-Jacques Quisquater
Overview and Security Analysis of RSA-type Cryptosystems Against Various 
Attacks


Presented implications of five attacks against RSA and three other 
RSA-type cryptosystems (LUC, KMOV, Demytko)


RSA with low exponents (e<= 33) is vulnerable if attacker can get 1327 
messages (for 1024 bit key) (Hastad attack.)   1024-bit RSA with secret 
key less than 2exp256 is vulnerable to Wiener attack.  


"Garbage Man in the Middle" will crack RSA key with one message: Alice 
encrypts message m to give ciphertext c & sends c to Bob.  Mallory blocks 
the message so Bob doesn't see it.  Mallory intercepts the message and 
transforms ciphertext c into c'.  Then sends c' on its way to Bob, who 
decrypts c' into gibberish message m'.  Bob throws out message m' in his 
garbage.  Mallory retrieves m' from Bob's garbage and using ciphertext 
derives Bob's key.  (This doesn't have to be an active attack, does it?  
As long as Mallory can trick Bob into decrypting gibberish and not 
disposing of it properly, Bob's in trouble without any help from Alice, 
right?)


Michael Merritt suggested that the results be summarized into concrete 
recommendations for sizes of exponent, frequency of key change, key size, 
etc.


Ed Felten 
Spoofing Attacks on the Web


Not talking about DNS or IP spoofing - that's a well-known problem.  
Talking about fooling users into making security-relevant decisions -  by 
fabricating for them a contrived, deceptive context.  This is not a 
protocol attack.  It's more of a social engineering attack, but with a 
technical spin.


Most trivial form of spoofing:  Pop up a dialogue box asking for a 
password/credit card number.  Make it look like a real dialogue box.  


More sophisticated attack:  Pop up a dialogue box just when a user is 
expecting it from a legitimate source.  E.G. run a hidden javascript on 
the user's machine waiting for him to go to a site to download software.  
When he goes to the site, pop up a dialogue box asking him if he wants to 
download something.  If you choose the name right, chances are user might 
choose to accept it.  


Next level of attack is mirroring a site:  make a copy of a sensitive 
site on the attacker's web server.  Maybe collect passwords, if the user 
is accustomed to entering passwords into the site.  


Next level up is "whole-web mirroring"  Kind of a "twisted, evil twin" of 
the web.  Rely on the look and feel of the real web to make the user 
believe s/he is seeing the real web.  


This is a powerful attack:  It handles forms, cgi scripts, can mirror 
search engines, handles almost all types of content.  Gets nasty with 
bookmarks since problem will persist across sessions unless the user 
looks in the bookmark file and notices the real address.  SSL doesn't 
help:  attacker can still spoof a blue key.  (Seems to me user could 
check the certificate, no? but who checks certificates)


How to combat mirroring:  
1.  Have *servers* authenticate *clients*.  Use SSL (assuming SSL key 
exchange really prevents man-in-the middle attack).


2.  Provide obvious unspoofable context - i.e. if virtually all web pages 
were signed and displayed on the window border (this is probably a long 
way off).  


Once user is aware of this problem, its easy to trace, but attackers will 
probably use throw-away hacked sites.  Also - trouble is most people 
aren't suspicious and may not notice for a while if ever.  


Drew Dean
Web Security: High Level Overview


Digitally-signed applets help some, but:
-Signed code can still attack you & you don't know it.
-The fact that 100,000 people have used the signed code without incident 
is not necessarily proof that the code is safe: it could be that the code 
is targeted somehow (e.g. in time or in address-space).  
-Still relies on a digital certificate infrastructure which still does 
not exist.


In spite of this, digitally signed code may help organizations achieve a 
measure of security in running internally developed code where there is 
some good way of distributing the organization's certificate (along with 
the browser, say) and where there is an additional basis for trust apart 
from technical.


"Servlets" are coming: client uploads executable to the server.  Database 
searches and agents will use this approach very likely.  Should raise 
some interesting security problems.




Avi Rubin
Blocking Java Applets at the Firewall


Rubin's first remark:  Should have been titled "Blocking Java Applets at 
the Firewall - Not"


Why try to block applets?  protect against malicious code, denial of 
service, high-level spoofing (trojan horses, e-mail/smtp/sendmail abuse), 
covert channels, undermining firewalls)


There are several strategies to block a java applet in an application 
gateway:  prevent all GETS on "*.class", prevent any gets on <applet> 
tags, don't allow in anything starting with "cafe babe" (first few bytes 
of every java applet?).  


However - every strategy can be bypassed:


-Express <applet> as <%41pplet>
-Applet might come in as compressed MIME type.  Firewall would be unable 
to uncompress.


When contacted vendors who claimed that they blocked applets, every one 
answered either:
-"It's proprietary" or
-"We use *.class, cafe babe and <applet>."  When weaknesses were 
described they said "Oh - that's interesting."


Considered giving up on firewall and giving users a custom  browser which 
will only run digitally-signed applets, but two problems:  who will 
distribute all the software, and how do you stop someone from installing 
their own browser?  (Answer - force all external web access through an 
internal web proxy server)  ((But someone in the audience thought the 
anonymizer could get around any firewall attempts to implement this.)


Conclusion:  even if firewalls could block applets, it seems like there 
will likely be problems when you try to merge the two policies:
Firewall says trust insiders, control outsiders capabilities through the 
firewall
Java says trust no one; control their actions on the platform.


Audience: why are you so worried about outsiders?  Every study says your 
biggest problem is insiders.  Others in audience questioned the studies:  
how current are those numbers, are organizations reporting outside 
incidents at the same rate they report internal incidents, etc.?  




Steve Bellovin
Java - Threat or Menace?


Problem is:  we want absolute security.  We want "do what I mean" 
security.  e.g. when I want to pay for a book over the web, grab my 
credit card number out of a file without me having to remember it, but 
don't let anyone get at it.  


Problem:  most functions that are needed are the very functions that can 
be exploited with bad consequences:  file I/O can be used to read 
sensitive files, popup windows can be used to coax me to type passwords.


Browsers see bytecode - not java source.  Bytecode verifier purports to 
enforce rules over java source, but not true:  Bytecode verifier permits 
a "goto", e.g. which can not be coded in java.  Bytecode verifier and 
class loader are complicated (3500 LOC for BC verifier).  This model is 
too complex to be trusted.


There is nothing like a system call that permits one to know entry and 
exit points.  Everything is an "invoke"


Java relies on DNS for enforcement.  DNS has problems.  In fact DNS has 
been used to compromise the model.  DNS queries leak information by going 
around the model.


Denial of service not even considered in security model.


Digitally-signed certificates are no worse than store-bought software in 
theory.  But: doesn't scale on the web.  Also - if software distributors 
are not careful about signatures and certificates (i.e. if they're 
signing, creating certificates on their web server) there could be 
trouble.  Also - unlike store-bought software, the attacker knows the 
buyer and can target an attack.  Will people really look at certificates?


Next best thing:  add local admin tools so that a site can control policy 
site-wide (Netscape says they've got it already.)  Eliminate reliance on 
the bytecode verifier.


Dan Wallach explained some of Netscape's plans.  Classes of permissions 
are being created (e.g. typical game permissions).  Game will then ask 
for game permissions which might be more meaningful to users.


Drew Dean: bytecode is very hard to verify.  Requires dataflow analysis.  


Belovin:  Java is probably here to stay.  There are no economic forces to 
alter the outcome.


Not many reports of malicious applets.  Some present had heard of some 
reports of problems that might have been caused by applets.


Steve Bellovin (standing in for Bill Cheswick)
Stupid Net Tricks


When sniffing incidents first got big 2-3 years ago, many ISPs were 
sniffed for months because of insecure workstations on the backbone.  Not 
widely reported at the time.


Network 18 was down for several hours: someone broadcast that they 
were that network on an ISP.  If you were closer to that ISP's router 
than to 18 you got the bogus route.


Millicent Watts
Network Security: Where does the real threat lie


Review of types of threats, need for vigilance.  Reported on some 
failures of voice recognition (failed safe).  Surveillance technology - 
Yvo Desmedt noted "Things that think" - technology where more and more 
consumer goods/personal articles have chips in them.  E.G.  your 
shoes trigger elevator doors and such, but can be 
used for more nefarious purposes.  (Anyone know if Italian shoemaker Bruno 
Magli is using them yet?)


Cindy Cullen
Demonstration of Hacker Techniques


Demonstrated rootkit which replaces key unix binaries with ones which 
hide intruder's presence.  No longer chosen tool of the elite hackers - 
available easily and being modified, sometimes carelessly.  


Also demonsrated ttywatcher.  Run on a host it will display connections 
to any tty (in or out).  Encrypted passwords/data are displayed (because 
intrusion is at the endpoint), connection can be taken over by root user 
with ttywatcher.




Alexis Rosen
Understanding and Defending Against SYN Attacks


Sorry to say I had to miss this one, though I understand the 
recommendations were same as those shared on the security 
lists:  trim down the timeout parameter, etc.


Robert J. Hall
Channels: Avoiding unwanted electronic mail


Another one I hated to miss.  The approach was to add a new sendmail 
header which included some cryptographic authentication information.  
Different headers, taken together with your email address allow you to 
create different personas: one for private discussion with trusted 
correspondents, one for "send only" to public mailing lists.  For more 
info, the paper is available at:
ftp://ftp.research.att.com/dist/hall/papers/agents/channels-long.ps


Many thanks to the presenters, organizers and to DIMACS (Rutgers, 
Princeton, AT&T Bell Labs, BellCore, NFS) for an excellent workshop.