The DIMACS Workshop on Network Threats was held at The Center for Discrete Mathematics and Theoretical Computer Science (DIMACS) in Piscataway , NJ from December 4-6, 1996.
The program, with links to abstracts for many of the talks, can be found at: http://dimacs.rutgers.edu/Workshops/Threats/program.html.
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 Garfinkel: The only hope is strict liability for vendors and credible threat of lawsuits for product liability.
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.
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.
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.
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.
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.
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.
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.
Digitally-signed applets help some, but:a
-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.
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 tags]."
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.?
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.
Bellovin: 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.
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.
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?)
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.
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.
Many thanks to the presenters, organizers and to DIMACS (Rutgers, Princeton, AT&T Bell Labs, BellCore, NFS) for an excellent workshop.