\iffalse "Security Loophole Found in Microsoft Windows" University of Haifa (11/12/07) A group of researchers in Israel notified Microsoft that they have discovered a security loophole in the Windows 2000 operating system. The researchers say they have found a way to decipher how Windows' random number generator works, compute previous and future encryption keys used by a computer, and monitor private communication. The security loophole jeopardizes emails, passwords, and credit card numbers entered into a computer. "This is not a theoretical discovery," says Dr. Benny Pinkas from the Department of Computer Science at the University of Haifa, who headed the research initiative. "Anyone who exploits this security loophole can definitely access this information on other computers." The researchers say the newer versions of Windows may also be vulnerable if Microsoft uses similar random number generator programs. They say Microsoft should improve the way it encodes information and even consider publishing its code for random number generators so outside computer security experts can test them. The researchers' findings were presented at the ACM Conference on Computer and Communications Security in Alexandria, Va., Oct. 29-Nov. 2, 2007, in a paper titled "Cryptanalysis of the Windows Random Number Generator." http://media.haifa.ac.il/index.php?option=com_content&task=view&id=2898&Itemid=60 Stanford University Ph.D. student Adam Barth participated in a study that determined that Web browsers are still vulnerable to DNS rebinding. He says in an interview that rebinding attacks are successful because browsers and plug-ins employ DNS host names to distinguish between different origins, but browsers do not really communicate with the hosts by name--they must first use DNS to align the host name with an IP address and then communicate with the host through its IP address. DNS rebinding can be used to bypass firewalls or to temporarily commandeer a client's IP address to issue spam email or defraud pay-per-click advertisers. Barth says the solution used to fix the classic DNS rebinding vulnerability--DNS pinning--no longer effectively defends against the vulnerability because today's browsers contain many different technologies that allow network access, such as Java and Flash. These technologies support separate pin databases, but are allowed to communicate within the browser. Barth says an effective defense against firewall circumvention is the configuration of DNS resolvers not to bind host names to internal IP addresses, while host name authorization can prevent DNS rebinding vulnerabilities in the longer term. "I'm hopeful the vendors will reach a consensus to fix these issues using host name authorization, but this requires the vendors to cooperate with each other," he notes. Barth says DNSSEC offers no protection against DNS rebinding attacks because it is designed to prevent pharming not rebinding. Barth and fellow members of the Stanford Web Security Lab are presenting a paper on DNS rebinding at the 2007 ACM Conference on Computer and Communications Security, Oct. 29-Nov. 2, in Alexandria, Va. For more information about the conference, visit http://www.sigsac.org/ccs.html http://www.securityfocus.com/columnists/455 From: Laurent DAVERIO Subject: Re: scans SSH intensifs To: Georges-André Silber CC: Fabien COELHO , Responsables systemes du CRI Date: Mon, 22 Oct 2007 10:37:58 +0200 > Si si si, moi ça m'intéresse notamment pour la dedibox où il y a LHEO, > mais je n'ai pas encore eu le temps de regarder. > Il y a aussi babel qui sert en Debian... Franchement, il n'y a pas vraiment de boulot : # apt-get install fail2ban => A ce stade, il est installé et lancé. iptables -L pour voir le résultat. # vi /etc/fail2ban.conf (pour rajouter quelques IP en whitelist, par précaution, et éventuellement modifier les seuils de blocage) # /etc/init.d/fail2ban restart Mais je reconnais tout à fait qu'il est plus prudent de l'installer d'abord sur des machines auxquelles on a physiquement accès :-) Laurent. http://it.slashdot.org/article.pl?sid=07/10/14/0115251 The Washington Post has an article detailing what is known of the workings of the Russian Business Network, a shadowy entity based in St. Petersburg that hosts a good fraction of the world's spammers, identity thieves, bot herders, and phishers. RBN is not incorporated anywhere and may not technically even be violating Russian law. It provides "bulletproof hosting" for about $600 a month to a wide range of bad guys.The author of the Post story, Brian Krebs, supplements it with two blog posts. One provides more detail and back story including a look at one ISP's security admin who decided last summer to ban all RBN traffic from his network, with outstanding results. The other post maps some of the RBN's upstream suppliers and details the extent of the RBN's involvement in recent cyber-attacks: "Nearly every major advancement in computer viruses or worms over the past two years has emanated from or sent stolen consumer data back to servers" in the RBN. http://it.slashdot.org/article.pl?sid=07/08/26/1558245&from=rss """ We've gotten a number of submissions about the new tricks the massive Storm botnet has been up to. Estimates of the size of this botnet range from 250K-1M to 5M-10M compromised machines. Reader cottagetrees notes a writeup at Exploit Prevention Labs on a new social engineering attack involving YouTube. The emails, which may be targeted at people who use private domain registrations, warn the recipient that their "face is all over 'net" on a YouTube video. The link is to a Storm-infected bot that attacks using the Q4Rollup exploit (a package of about a dozen encrypted exploits). And reader thefickler writes that the recent wave of "confirmation spam" is also due to Storm, as was the earlier, months-long "e-card from a friend" series of attack emails. """ http://it.slashdot.org/it/07/09/07/122200.shtml Stony Stevenson writes to mention that some security researchers are claiming that the Storm Worm has grown so massive that it could rival the world's top supercomputers in terms of raw power. "Sergeant said researchers at MessageLabs see about 2 million different computers in the botnet sending out spam on any given day, and he adds that he estimates the botnet generally is operating at about 10 percent of capacity. 'We've seen spikes where the owner is experimenting with something and those spikes are usually five to 10 times what we normally see,' he said, noting he suspects the botnet could be as large as 50 million computers. 'That means they can turn on the taps whenever they want to.'" From: Serge ALGAROTTI Subject: [RESPINFO] [SECURITE] web Nikto To: Respinfos Date: Thu, 30 Aug 2007 13:40:09 +0200 Bonjour, cet outil me semble intéressant pour faire une première analyse de la sécurité des serveurs webs: Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 3300 potentially dangerous files/CGIs, versions on over 625 servers, and version specific problems on over 230 servers. Scan items and plugins are frequently updated and can be automatically updated (if desired). Nikto is not designed as an overly stealthy tool. It will test a web server in the shortest timespan possible, and it's fairly obvious in log files. However, there is support for LibWhisker's anti-IDS methods in case you want to give it a try (or test your IDS system). Not every check is a security problem, though most are. There are some items that are "info only" type checks that look for items that may not have a security flaw, but the webmaster or security engineer may not know are present on the server. These items are usually marked appropriately in the information printed. There are also some checks for unknown items which have been seen scanned for in log files. http://www.cirt.net/code/nikto.shtml "AT&T Invents Programming Language for Mass Surveillance" Wired News (10/29/07); Singel, Ryan AT&T researchers have developed Hancock, a C language-based programming language designed to mine the company's telephone and internet records for surveillance data. A recently discovered AT&T research paper published in 2001 shows how the phone company uses Hancock-based software to process tens of millions of long distance phone records to create "communities of interest," or calling circles that show who people are talking to. Hancock was developed in the late 1990s to develop marketing leads and as a security tool to see if new customers called the same numbers as previously disconnected fraudsters, which the research paper called "guilt by association." Hancock-based programs work by analyzing data as it enters a data warehouse, a significant difference from traditional data-mining tools that tend to look for patterns in static databases. A 2004 paper published in ACM Transactions on Programming Languages and Systems demonstrates how Hancock can sort through calling card records, long distance calls, IP addresses and Internet traffic dumps, and even track the movement of a cell phone as it switches between signal towers. http://blog.wired.com/27bstroke6/2007/10/att-invents-pro.html Pour nos propres besoins, nous avons essayé de faire un point sur les mesures à prendre pour protéger nos utilisateurs des attaques XSS qui pourraient utiliser nos applications. Ce travail de David Verdin a été mis en ligne car nous pensons qu'il peut vous aider dans vos propres démarches : http://www.cru.fr/documentation/analyses/xss http://www.zdnet.fr/actualites/informatique/0,39040745,39370224,00.htm Sécurité - D'ici à la fin de l'année, le grand public et les PME disposeront d'un portail dédié à la sécurité informatique. Selon les informations de ZDNet.fr, ils accéderont à des alertes de sécurité, des fiches pratiques et des outils pour se protéger. http://www.theregister.co.uk/2007/09/26/gmail_backdoor_vulnerability/ From: Jose Marcio Martins da Cruz Subject: [RESPINFO] Home Users: A Public Health Problem? To: respinfo Date: Tue, 25 Sep 2007 15:36:21 +0200 Paru dans Crypto-Gram de semptembre : http://www.schneier.com/crypto-gram-0709.html ***************************************************** Home Users: A Public Health Problem? To the average home user, security is an intractable problem. Microsoft has made great strides improving the security of their operating system "out of the box," but there are still a dizzying array of rules, options, and choices that users have to make. How should they configure their anti-virus program? What sort of backup regime should they employ? What are the best settings for their wireless network? And so on and so on and so on. How is it possible that we in the computer industry have created such a shoddy product? How have we foisted on people a product that is so difficult to use securely, that requires so many add-on products? It's even worse than that. We have sold the average computer user a bill of goods. In our race for an ever-increasing market, we have convinced every person that he needs a computer. We have provided application after application -- IM, peer-to-peer file sharing, eBay, Facebook -- to make computers both useful and enjoyable to the home user. At the same time, we've made them so hard to maintain that only a trained sysadmin can do it. And then we wonder why home users have such problems with their buggy systems, why they can't seem to do even the simplest administrative tasks, and why their computers aren't secure. They're not secure because home users don't know how to secure them. At work, I have an entire IT department I can call on if I have a problem. They filter my net connection so that I don't see spam, and most attacks are blocked before they even get to my computer. They tell me which updates to install on my system and when. And they're available to help me recover if something untoward does happen to my system. Home users have none of this support. They're on their own. This problem isn't simply going to go away as computers get smarter and users get savvier. The next generation of computers will be vulnerable to all sorts of different attacks, and the next generation of attack tools will fool users in all sorts of different ways. The security arms race isn't going away any time soon, but it will be fought with ever more complex weapons. This isn't simply an academic problem; it's a public health problem. In the hyper-connected world of the Internet, everyone's security depends in part on everyone else's. As long as there are insecure computers out there, hackers will use them to eavesdrop on network traffic, send spam, and attack other computers. We are all more secure if all those home computers attached to the Internet via DSL or cable modems are protected against attack. The only question is: what's the best way to get there? I wonder about those who say "educate the users." Have they tried? Have they ever met an actual user? It's unrealistic to expect home users to be responsible for their own security. They don't have the expertise, and they're not going to learn. And it's not just user actions we need to worry about; these computers are insecure right out of the box. The only possible way to solve this problem is to force the ISPs to become IT departments. There's no reason why they can't provide home users with the same level of support my IT department provides me with. There's no reason why they can't provide "clean pipe" service to the home. Yes, it will cost home users more. Yes, it will require changes in the law to make this mandatory. But what's the alternative? In 1991, Walter S. Mossberg debuted his "Personal Technology" column in The Wall Street Journal with the words: "Personal computers are just too hard to use, and it isn't your fault." Sixteen years later, the statement is still true -- and doubly true when it comes to computer security. If we want home users to be secure, we need to design computers and networks that are secure out of the box, without any work by the end users. There simply isn't any other way. This essay is the first half of a point/counterpoint with Marcus Ranum in the September issue of "Information Security." You can read his reply here: http://www.ranum.com/security/computer_security/editorials/point-counterpoint/homeusers.htm RFC 4086 : Randomness Requirements for Security http://www.bortzmeyer.org/4086.html http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml#RELRO http://www.owasp.org http://www.ssi.gouv.fr http://www.ssi.gouv.fr/fr/confiance/methodologie.html http://www.betanews.com/article/OneCare_Deletes_Users_Outlook_Files/1173474996 http://www.brynosaurus.com/pub/net/p2pnat/ Peer-to-Peer Communication Across Network Address Translators Bryan Ford http://www.php-security.org/index.html Message (or rather MML) currently support PGP (RFC 1991), PGP/MIME (RFC 2015/3156) and S/MIME. Covert and Side Channels due to Processor Architecture. Zhenghong Wang, Princeton University Ruby Lee, Princeton University Regarder mes notes sur ACSAC regarder workshop de ACSAC 2006 mitre.org cve.mitre.org : vulnérabilités cce.mitre.org : configuration settings cpe : software and packages and platforms cme : malware threats checklists.nist.gov Parler du cross-site scripting (XSS) stunnel, httptunnel, openvpn, nstx http://www.cl.cam.ac.uk/~rja14/book.html http://www.cours.polymtl.ca/inf6420/Documentation.htm Compromissions de la semaine -------------------------- Deux cas de compromission de serveur web via des failles du serveur web Apache ou d'une application PHP ont ete signale. Un cas de modification de site web via une faille deja signalee dans les STAT06 sur le forum phpbb a ete identifie. L'attaque a permis au pirate d'utiliser les droits de l'administrateur du forum. Elle se fonde sur utilisation non prevu du champ referer pour sniffer et recuperer le session ID (SID) apres que l'administrateur du forum soit alle consulter le profil ou un post contenant une image hebergee chez le pirate. Ainsi il devient possible de recuperer le SID de l'admin ou du moderateur pour modifier la page d'accueil ou saboter le forum via des requetes du type: "POST /forum/admin/admin_users.php?sid=b1c8e3c144...eb23 HTTP/1.1" 200 "POST /forum/admin/admin_board.php?sid=b1c8eb3214...6ab9 HTTP/1.1" 200 [CC 02] Critères Communs pour l évaluation de la sécurité des technologies de l information. Parties 1, 2 et 3. Version 2.2. Janvier 2004. [CC 99] Common Criteria for Information Technology Security Evaluation. Norme ISO 15408. Version 2.1. Aout 99. : Jacques Beigbeder Subject: [ensnet] [IMPORTANT] à propos de Spamcop To: ensnet@ens.fr Date: Tue, 3 Jan 2006 11:14:49 +0100 Bonjour et meilleurs voeux. La semaine dernière, le serveur de mails sortants de l'ENS a été dans la blacklist gérée par Spamcop. Dans la page: http://www.spamcop.net/fom-serve/cache/297.html il est écrit: * The SCBL is an aggressive spam-fighting tool. By using this list, you can block a lot of spam, but you also may block or filter wanted email. Because of this limitation, one should strongly consider using the SCBL as part of a scoring system and explicitly whitelist wanted email senders (e.g., mailing lists and other IPs from which you want to receive email). Hélas plein de sites refusent les mails si le serveur qui émet est dans Spamcop. Exemples: cegetel.net, umd.edu, weizmann.ac.il, uni-koblenz.de. ===================================================================== Spamcop dit donc être "aggressive" et il considère tout retour de mail comme un souci. Cela va loin: ( http://www.spamcop.net/fom-serve/cache/329.html ) Problem: The traditional auto-responder Description: A message is sent in response to inbound email informing the purported sender that you are on vacation, listing FAQs or otherwise sending a standard message - all too often, to the wrong person. Donc tout message géré par vacation(1) est un souci: vacances, message indiquant une nouvelle adresse, etc. Oui, on confine à l'absurde... ===================================================================== Jusqu'en novembre, on avait reçu quelques annonces de bounces de spamcop. Depuis il faut deviner... plus d'info ne filtre. Leurs raleries précédentes: 1/ les bounces sur 'User unknown'. J'ai supprimé début 2005 via milter-ahead sur nef.ens.fr. 2/ des messages d'antivirus mal configurés. Normal, on a corrigé. 3/ les bounces sur spam reçus. Maintenant en extinction. 4/ un bounce de sympa and co. A savoir un spammeur écrit une c...rie à , et sympa@ens.fr répond: Command not recognized Idem si un spammeur écrit un message à une liste fermée. Sympa répond: You are not a subscriber. ou Votre message pour la liste XXXX a été transmis aux modérateurs. Parade: mettre un anti-spam en frontal de sympa. Mais problème non trivial! Sinon, en lisant la mailq sur nef, j'ai relevé un certain nombre de fautes. Et je vais aviser les administrateurs locaux de ce qui peut (doit!) être supprimé. ---- Autres remarques: - Spamcop est géré par une société commerciale (Ironport), qui vend des services de mail: émission en masse, filtrage. D'ici à ce que la multiplication des incidents soit dans leur stratégie commerciale... - le 19 décembre, on a reçu 7 spams de adt@0926.com, émis par des machines en Turquie. Bizarrement 0926.com a comme MX bl.spamcop.net! Un de leurs spamtrap?? - le 1er janvier, un mail émis par , mais transmis par cpe-69-203-117-221.nyc.res.rr.com !! - Spamcop a des méthodes secrètes. La page: http://www.spamcop.net/w3m?action=blcheck&ip=129.199.96.40 indiquait System has sent mail to SpamCop spam traps in the past week (spam traps are secret En termes de volumes, un incident précédent indiquait uniquement 3 mails en 3 jours, suffisant quand même... --Jacques Beigbeder http://www.sans.org/top20/ http://www.eff.org/deeplinks/archives/004138.php http://www.cert.org/stats/cert_stats.html * rootkit hunter http://www.rootkit.nl/ * chkrootkit http://www.chkrootkit.org/ http://slashdot.org/articles/05/03/05/2242213.shtml?tid=126&tid=98&tid=201 http://lcamtuf.coredump.cx/newtcp/ From: Serge ALGAROTTI Subject: [RESPINFO] [SECURITE] Rapport CLUSIF 2004 To: Respinfos Date: Thu, 27 Jan 2005 17:56:00 +0100 Bonjour, je vous conseille la lecture de: Panorama de la Cybercriminalité - année 2004. 13 janvier 2005 Le CLUSIF a dressé le panorama de la cybercriminalité en 2004 en dégageant les dernières tendances et en mettant en évidence l'émergence de nouveaux risques liés au développement des technologies de l'information, etayé par de nombreux cas concrets. cf https://www.clusif.asso.fr/fr/infos/event/index.asp http://www.cs.uu.nl/people/henkp/henkp/pgp/pathfinder From: Serge ALGAROTTI Subject: [RESPINFO] SEC Info : seminaire SPAMs To: Respinfos Date: Tue, 18 Jan 2005 13:35:34 +0100 Bonjour, === Le séminaire Aristote du 20 Janvier sera retransmis en direct sur Renater, comme d'habitude. Le programme du séminaire : Comment lutter contre les SPAMS et autres formes de pollution électronique. Organisateur : Jean-Luc Parouty (CNRS). Détails : voir : http://www.aristote.asso.fr/sem/semnext.html Il y a des gens connus ;-) La retransmission : voir : http://www.aristote.asso.fr/sem/SXA_Retransmission.htm === On a pas à se plaindre :-) : "Les filtres d'AOL bloquent jusqu'à 2, 6 milliards de mails par jour" !!! -- Serge ALGAROTTI [http://www-cemef.cma.fr/] Ecole des Mines de Paris / CEMEF UMR CNRS 7635 [tel 04 93 95 74 02] http://www.techworld.com/security/news/index.cfm?NewsID=2983&Page=1&pagePos=19 20 January 2005 Linux servers safer than ever That's according to honeypot security researchers. By Matthew Broersma, Techworld Attackers are no longer bothering to attack average Linux systems, because there's so much more money to be made from invading Windows, according to security researchers. The Honeynet Project, which sets up ordinary seeming Linux networks in order to observe attack activity, found that the life expectancy of such systems has dramatically increased from a year or two ago. Its 2004 findings, published recently, found an unpatched Linux system lasts, on average, three months before it is compromised, compared to about 72 hours for 2001-2002. Some of the project's systems were exposed to the Internet for nine months without a successful attack. The project's "honeynets" - networks of two or more "honeypots" - are designed to detect random attacks on the Internet, carried out on targets detected through random searching, scanning and hacking systems such as worms and autorooters, rather than particular attacks focussed on specific, high-value targets. A honeypot is a system set up for the purpose of attracting random attack activity. Since overall Internet attacks don't seem to be going down, the project's researchers theorised that the focus of hacking activity has shifted to Windows systems, simply because the platform is so widespread that it presents an irresistible target. "It's now easier to hack the end user than hacking the bank," Honeynet Project president Lance Spitzner told Techworld. "Banks are well protected, end users are not. Hack enough end users, and you can make as much, if not more, than hacking the bank." While the project didn't carry out comparative research using Windows, Spitzner pointed out that research from security organisations such as Symantec and and the Internet Storm Center (ISC) has found no shortage of attacks on Windows honeypots. For example, an ISC project measuring the survival time for Windows systems, found here, measures survival time in minutes rather than hours. The average survival time for the systems the ISC tests has declined from about 55 minutes in the autumn of 2003 to just under 20 minutes at the end of 2004, although the figures have been improving gradually from a low of 15 minutes in the spring of 2004. Microsoft says survival rates for Windows should decline as Windows XP Service Pack 2 becomes more widely used - the update is designed to make Windows' default configuration more secure. The project deliberately focussed on average systems that didn't present any particular attraction to attackers - in the real world, the equivalent would be home networks or small and medium-sized businesses. The project deployed 12 honeynets in eight countries (the US, India, the UK, Pakistan, Greece, Portugal, Brazil and Germany), consisting of a total of 24 unpatched Unix and Unix-like honeypots. Nineteen of the systems were Linux, mostly Red Hat, including one Red Hat 7.2 system, five Red Hat 7.3, one 8.0, eight 9.0 and two Fedora Core 1 systems. Other deployments included one Suse 7.2, one Suse 6.3, two Solaris Sparc 8, two Solaris Sparc 9 and one Free-BSD 4.4 Services such as SSH, HTTPS, FTP, SMB were enabled, with inbound connections to these services allowed; some of the systems also used insecure or easily guessed passwords. The systems weren't registered in DNS or search engines, so they could only be found by automated means. The situation for high-value Linux systems, such as company Web servers, CVS repositories or research networks is potentially very different, Spitzner said. "I'm sure these high-value Linux systems are prime targets and are attacked every day, if not every hour. If vulnerable, they would be hacked very soon," he said. Older Linux systems were more likely to be successfully attacked than newer deployments, when left unpatched, probably because more vulnerabilities have been uncovered and attackers have had time to learn which exploits work, the project found. This also reflects the fact that default Linux installations are becoming more secure, the project said. Once compromised, attackers used the systems mainly for IRC bouncing, bots and to host phishing scams, the project found. On at least one of the systems attackers attempted to set up a fake bank in order to harvest bank and credit card information. The Honeynet Project is a non-profit research organisation supported by a number of security companies, including Foundstone, Counterpane, SecurityFocus.com and SourceFire. From: Jose Marcio Martins da Cruz Subject: [RESPINFO] Politique de gestion de traces au CNRS To: respinfo@ensmp.fr Date: Tue, 18 Jan 2005 12:24:54 +0100 Organization: Ecole des Mines de Paris Bonjour, Pour information. Sur le site du CNRS, l'on trouve la strategie du CNRS en ce qui concerne la gestion des fichiers de log et des traitement. https://intranet.cnrs.fr/extranet/cnrs/fsd/index.htm Les deux premiers liens : Decision... et Politique de gestion de traces. Le deuxieme document est tres interessant. Grosso modo, les labos du CNRS qui se cadrent dans cette politique n'ont pas besoin d'effectuer des declarations a la CNIL, mais informer les instances concernes (conseil de laboratoire, information dans la charte, ...). Si les traitements ne rentrent pas dans ce moule, il faut alors effectuer une declaration a la CNIL. Amities, Jose-Marcio Les droits ugo arrivent trop tard, Devrait arriver avant x et s https://www.urec.cnrs.fr/securite/corres-secu/index.html From: Francois IRIGOIN Subject: Fwd: Government Uses Color Laser Printer Technology to Track Documents To: all@cri.ensmp.fr Cc: JudyIrigoin@hotmail.com, stevemosser@btinternet.com, Olivier_Krumeich@hp.com Date: Thu, 25 Nov 2004 11:52:36 +0100 (MET) Reply-To: Francois IRIGOIN "Government Uses Color Laser Printer Technology to Track Documents" Medill News Service (11/22/04); Tuohey, Jason For decades, color laser printers from Xerox and other companies have been modified to embed their serial number and manufacturing code on each document the machines produce for the purpose of tracking down forgers. Xerox research fellow Peter Crean says his company's printers code these numbers in millimeter-sized yellow dots that are invisible to the naked eye, but are revealed through close examination when shining a blue LED light on the printout. "It's a trail back to you, like a license plate," he notes. Crean says his company originated the technology about 20 years ago to address concerns that Xerox color printers could be easily employed to forge bills. He says the encoding is performed by a chip positioned deep within the printer's innards, close to the laser, that cannot be disabled by "standard mischief." Crean says that law enforcement in the United States and other countries use the technology to trace counterfeiters. The embedded serial numbers could also be used to track down any person or business that printed a document, but Lorelei Pagano with the U.S. Secret Service insists that the government only authorizes the use of the technology for information-gathering in the case of criminal acts. This has done nothing to assuage the fears of lawyer John Morris with The Center for Democracy and Technology, who argues that consumers must at the very least be notified of the technology's presence in the machines. http://it.slashdot.org/it/04/10/29/1353206.shtml?tid=179&tid=172&tid=3 "The National Security Agency has just released a Security Configuration Guide for Apple Mac OS X (pdf). The guide mostly contains common sense configuration information that applies to many Unix systems. It also includes specific discussion for Apple's unique features such as Keychain and FileVault. It should be useful to most Mac OS X users and will be particularly useful for US Government organisations that use Mac OS X and for commercial IT Departments that are supporting Mac OS X. A range of other NSA Security Configuration guides for other operating systems, applications, and IT kit are also available." === mi2g a déjà publié plus d'une étude fantaisiste par le passé, il faut donc prendre celle qui suit avec les précautions d'usage : Study Recommends Mac OS X as Safest OS http://it.slashdot.org/it/04/11/02/1722237.shtml?tid=172&tid=179&tid=190 The British security firm mi2g has concluded a comprehensive 12-month study to identify the safest 24/7 computing environment. In the end, the open source BSD and Mac OS X came out on top with the fewest security breaches against permanently connected machines worldwide in homes, small businesses, large enterprises and governments. The study found Linux to be the most breached environment 'in terms of manual hacker attacks overall and accounts for 65.64% of all breaches recorded'. Windows was the most breached environment in government computing and led Linux, BSD and Mac OS X by far in economic damage caused by breaches." We mentioned their previous study too. As before, the study ignores the thousands of automatically-spreading viruses for Windows. http://www.easynews.com/virus.html A signaler une étude du SANS: un PC sous Windows XP non patché tient en moyenne 20 minutes avant d'être tombé (ver, virus, etc.). Ceci est plus court que le temps nécessaire pour faire une mise à jour! Donc les particuliers à domicile sans protection doivent se faire du souci: http://www.securityfocus.com/columnists/262 http://isc.sans.org/survivalhistory.php Une autre étude a aussi montré la vulnérabilité des téléphones portables, de plus en plus intelligents car programmables. Un cas a même été programmé en vrai: il "sautait" de téléphone en téléphone dans la rue, en détectant les autres appareils Bluetooth qui passaient à côté... Critères communs /www.wordiq.com/definition/Diffie-Hellman From: Nicolas FISCHBACH Subject: [FRnOG] Les FAI face aux virus et aux vers To: frnog@frnog.org Date: Thu, 06 May 2004 14:51:00 +0200 Reply-To: frnog@frnog.org Bonjour, Suite aux demandes hors liste, j'ai mis les transparents de la presentation faite lors de la JSSI2004 de l'OSSIR en ligne: PPT: http://www.securite.org/presentations/ddos/JSSI2004-NF-FAIVirusVers-v1.ppt PDF: http://www.securite.org/presentations/ddos/JSSI2004-NF-FAIVirusVers-v1.zip Nico. -- Nicolas FISCHBACH (nico@securite.org) Senior Manager - IP Engineering/Security - COLT Telecom Securite.Org Team Une conf de Marc Espie sur OpenBSD ? http://www.onlamp.com/pub/a/bsd/2004/03/18/marc_espie.html From: Jacques Beigbeder Subject: [enssec] la semaine du 12 au 18 mars To: enssec@ens.fr Date: Mon, 22 Mar 2004 11:06:09 +0100 Pour la petite histoire: http://story.news.yahoo.com/news?tmpl=story&cid=1804&ncid=738&e=6&u=/washpost/20040321/tc_washpost/a11310_2004mar20 http://xforce.iss.net/xforce/alerts/id/167 Ou comment le firewall d'ISS est détourné par un virus pour écrire aléatoirement sur le disque dur, ce qui a un bel effet destructeur! Ver/virus Mydoom Nous avons deja evoque le ver/virus MyDoom dans ses versions A et B, ces deux dernieres semaines. On connait deja les ravages perpetres par le A et la relative discretion du B. MyDoom-A a contamine un nombre impressionnant de machines de par le monde laissant sur chacune une backdoor permettant a un intrus sachant s'y connecter de penetrer chaque systeme infecte a sa guise. Voici maintenant que cette semaine non pas un, ni deux mais quatre vers/virus exploitant les failles de securite ouvertes par MyDoom-A ou B ont fait leur apparition sur l'Internet. Le premier Vessel/DeadHat-A scanne le reseau et tente de se connecter sur les ports 3127/tcp, 3128/tcp et 1080/tcp de systemes infectes par MyDoom. Lorsqu'il infecte une machine il la nettoie de toute trace de MyDoom mais installe une nouvelle backdoor. Il se met en ecoute sur le port 2766/tcp et attend les connexions clientes. Si un client reussit a s'authentifier, il lui est alors possible de transferer sur le systeme un programme de son choix que le ver executera. Il cherche egakement a se par le biais de l'utilitaire de partage de fichiers SoolSeek. Une version B de ce ver est apparue depuis peu. Elle est tres similaire a la precedente. Ensuite est venu DoomJuice/MyDoom.C qui lui ne repere ses cibles qu'au moyen de scans sur le port 3127/tcp. Ce ver n'elimine pas le ver MyDoom mais serait programme pour lancer une attaque en deni de service sur le site www.microsoft.com. Qui plus est il depose sur chaque system qu'il infecte le code source du ver MyDoom.A. Depuis, une version B tres similaire a emerge qui elle, ne dissemine pas le code source du ver MyDoom.A. Enfin, DoomHunter est un ver qui comme DeadHat va tenter de nettoyer les systemes infectes par MyDoom.A ou .B. Il met aussi fin a des processus associes au ver Blaster. Aucun de ces nouveaux vers/virs ne se propage par le biais de la messagerie electronique. Leur processus est donc transparent pour l'utilisateur. On note depuis le debut de cette activite une tres forte augmentation des scans sur les ports 3128/tcp mais surtout 3127/tcp. http://www.dshield.org/port_report.php?port=3127 Si ce n'est pas deja fait, mettre en place les mesures de filtrage adequates. Qui plus est, en plus des vers, il est fort probable que des individus tentent aussi de tirer parti de ces portes providentielles ouvertes par MyDoom.A ou .B sur nombre reseaux. Soulignons le fait que de plus en plus de vers introduisent de tels mecanismes sur les systemes qu'ils infectent. Liens: MyDoom.A http://securityresponse1.symantec.com/sarc/sarc-intl.nsf/html/fr-w32.mydoom.a@mm.html Doomjuice.A http://www.sarc.com/avcenter/venc/data/w32.hllw.doomjuice.html Vesser/DeadHat-A http://www.f-secure.com/v-descs/vesser.shtml Deadhat-B http://www.symantec.com/avcenter/venc/data/w32.hllw.deadhat.b.html Doomjuice.B http://vil.nai.com/vil/content/v_101012.htm DoomHunter http://vil.nai.com/vil/content/v_101022.htm http://nomines.bigbrotherawards.eu.org/index.php?rp=1 http://www.shorewall.net/ From: Fabien COELHO Subject: Netcraft News - Tuesday, February 3, 2004 (fwd) To: Ronan KERYELL Date: Tue, 3 Feb 2004 15:00:33 +0100 (CET) Reply-To: Fabien COELHO reaction M$ au niveau du DNS vis-a-vis de mydoom.B -- Fabien. ---------- Forwarded message ---------- Date: Tue, 3 Feb 2004 00:10:08 UT From: announce@beta.netcraft.com To: coelho@cri.ensmp.fr Subject: Netcraft News - Tuesday, February 3, 2004 Microsoft shorten www.microsoft.com TTL in anticipation of MyDoom.B payload In anticipation of the MyDoom.B payload striking www.microsoft.com tomorrow, Microsoft have shortened the TTL [time to live] on its DNS entry to 60 seconds. Yesterday the TTL was set to just under an hour. Essentially, Microsoft is accepting the significantly higher load on its name servers [outsourced to Akamai] as the premium of an insurance policy in the event that it wants to move www.microsoft.com very quickly. http://news.netcraft.com/archives/2004/02/02/microsoft_shorten_wwwmicrosoftcom_ttl_in_anticipation_of_mydoomb_payload.html SCO to use new domain for the duration of MyDoom DDoS The SCO Group will use www.thescogroup.com as an alternate web site while www.sco.com remains under a denial of service attack from machines infected with the MyDoom worm, the company said today. http://news.netcraft.com/archives/2004/02/02/sco_to_use_new_domain_for_the_duration_of_mydoom_ddos.html Subscription Details To Subscribe: Send a message with " SUBSCRIBE webserver-survey " in the message body to majordomo@netcraft.com To Unsubscribe: Send a message with " UNSUBSCRIBE webserver-survey " in the message body to majordomo@netcraft.com http://www.theregister.co.uk/content/55/35145.html Faire une citation des conf juridiques http://www.stud.ntnu.no/~shane/stasj/pics/humor/div/294.html http://lists.gnupg.org/pipermail/gnupg-users/2003-November/020772.html http://www.urec.cnrs.fr/geret/03.09.garde_barriere_vpn/Programme.html 6) Disaster recovery planning. Jon William Toigo. Bulletin hebdomadaire du CERT Renater (certsvp@renater.fr) ================================================================ Bonjour, Durant la semaine du 19/09/2003 au 26/09/2003, 3 machines compromises nous ont ete signalees dont une a pu etre analysee. 1) Les pots de miel ------------------ Le principe en est simple, attirer la mouche, sa mise en application peut se reveler complexe, voire a double-tranchant. Je ne rentrerai pas dans le detail, d'autres l'ont fait auparavant et certainement mieux que je ne le ferai, vous pouvez notamment consulter le site web du projet HoneyNet, http://www.honeynet.org, et ses fameux "challenges", ou bien le numero 8 du magazine MISC qui leur est consacre (vivement le prochain SSTIC), le numero 62 de Phrack, les sites web de honeyd, VMware, UML, ... Compromission sur Solaris 7 -------------------------- Cette machine a ete compromise par l'acquisition du mot de passe d'un utilisateur distant et son utilisation pour rentrer sur un compte en SSH. A partir de ce compte, le pirate a utilise un exploit local pour obtenir les droits root. Un programme de prise de controle a distance a ete lance avec le port 55444 en ecoute. Un rootkit a ete installe par le pirate dans /kernel/sys/.xp Ce rootkit comprennait un scanner destine a reperer des demon RPC vulnerables (sur Solaris), un proxy IRC baptise xp dans /kernel/sys/.xp/bnc , un jeu de commandes alteres dans /kernel/sys/.xp/nkit et un sniffer fonctionnant comme un module systeme dans /kernel/sys/.xp/snf/ De plus, le pirate avait installe deux outils, qui s'ils avait ete operationnel, aurait rendu la vie de l'administrateur "interessante". Le premier etait un module systeme baptise Administrator's NightMare qui genere des erreurs systemes aleatoires. Le second, nomme Solaris Integrated Trojan Facility, devait permettre de doubler la fonction du rootkit en permettant une prise de controle plus discrete de la machine. From: Jacques Beigbeder Subject: [enssec] la semaine du 10 au 16 octobre To: enssec@ens.fr Date: Sat, 18 Oct 2003 10:13:37 +0200 1. Les scans à la mode sont les ports 901 et 17300. 901: c'est le port 'samba-swat'. Je vais dorénanant le bloquer en entrée de site. 2. Le Cert allemand nous a informé d'une machine attaquée dans leur domaine. Quelques commentaires: - les écoutes réseaux marchent moins, plein de gens sont en SSH ou autre forme de cryptage. Simple alors: on modifie les clients SSH ou le serveur SSHD. - la machine attaquée en Allemagne était un Linux. Tout y était bien caché via un rootkit: se promener dans les fichiers (ls, find, ...), dans les process (ps, top, ...), sur les connexions réseaux (netstat, ...) ne montrent plus rien: les attaques se sont déplacés dans des modules noyaux. NB: ces méthodes existent sur Linux, sur Solaris, sur Windows. Solaris, c'est ce qui a failli m'arriver sur le serveur élèves (clipper.ens.fr) le 24 septembre. Dans un tel cas de rootkit, on ne peut faire confiance à la machine vivante (*), il faut booter sur un CD et comparer avec le CD (ou avec une sauvegarde saine). (*) dans mon cas sur clipper, la commande df(1) montrait de la place disparue dans la partition /, partition qui bouge très peu. Un indice? From: Eric Cousin Subject: [info-liste] du bon usage du courriel.... To: info-liste@mlistes.enst-bretagne.fr Date: Fri, 17 Oct 2003 16:05:42 +0200 Le gouvernement américain dévoile la vie privée des employés d'Enron sur l'internet : http://www.transfert.net/a9447 Ne dites pas que vous n'aurez pas été avertis :-< Dessin et autre dans http://www.denialinfo.com/ http://www.crypto.com/masterkey.html http://catless.ncl.ac.uk/Risks \trans {Commande openssl} Demanderait à détailler les composants de TLS avant. Rajouter exemple de RSA Fusionner partie Unix avec FC Solaris. Présenter modèle de sécurité Unix, conepts, CBAC,... Regarder dans Usenix ? http://www.kewney.com/articles/021119-secure.html From: "Ossian Vitek" Subject: Re: IP SmartSpoofing : How to bypass all IP filters relying on source IP address To: bugtraq@securityfocus.com Date: Thu, 31 Oct 2002 20:44:36 +0100 The only new is that the attacker relays the packets from the trusted client. This is not needed for the spoof. The solution in the defcon 8 presentation is far more easier. You do not need to arpspoof and NAT. * Spoof trusted client on the same LAN: Just take the MAC and IP of the trusted host. * Spoof an upstream trusted client: Just take the MAC of the upstream router and the IP of the trusted client. Defcon 8: http://www.defcon.org/html/defcon-8/defcon-8-post.html Read "Full Connection Vanilla IP-Spoof" in the presentation at: http://www.wittys.com/files/defcon_vitek.ppt All responses containing: 1: "But on a switched environment ..." 2: "But if you take same MAC as the ..." will be redirected to /dev/null //Ian Vitek, iXsecurity mailto:ian.vitek@ixsecurity.com Hi, In an article available at http://www.althes.fr/ressources/avis/smartspoofing.htm, we describe a new technique for spoofing an IP address using ARP cache poisoning and network translation. The IP smart spoofing allows to run any application with a spoofed IP address and thus, bypass many access control based on source IP address. As a result, we will explain why IP based access control is not reliable on firewalls, routers or applications. Regards, Laurent Licour (llicour@althes.fr) & Vincent Royer (vroyer@althes.fr) http://www.althes.fr DNSSEC http://www.hsc.fr/ressources/presentations/bind9/index.html.en "Ettercap is a multipurpose sniffer/interceptor/logger for switched LAN. It supports active and passive dissection of many protocols (even ciphered ones) and includes many feature for network and host analysis." http://sourceforge.net/projects/ettercap/ From: Olivier AUBERT Subject: Microsoft et la crypto To: info@enst-bretagne.fr Date: Fri, 3 Dec 1999 11:06:04 +0100 (MET) C'est effectivement pathetique [tire du dernier bulletin Crypto-Gram de Bruce Schneier: http://lwn.net/1999/1202/a/cryptogram.html] Microsoft encrypts your Windows NT password when stored on a Windows CE device. But if you look carefully at their encryption algorithm, they simply XOR the password with "susageP", Pegasus spelled backwards. Pegasus is the code name of Windows CE. This is so pathetic it's staggering. Plus de details: http://www.cegadgets.com/artsusageP.htm La recherche sur la crypto a pourtant bien avance ces dernieres 30 annees... From: Laurent DAVERIO Subject: Vols de domaines chez VeriSign To: all@cri.ensmp.fr Cc: Rémi DAVERIO , Michel CAMBIER , Stefan JAFFRIN Date: Tue, 14 May 2002 15:20:54 +0200 Organization: ENSMP/CRI Web community puts price on head of super highwayman VeriSign http://www.theregister.co.uk/content/6/25270.html -- "Instead of a Password, Well-Placed Clicks" New York Times (05/02/02) P. E7; Eisenberg, Anne Rather than deal with the headache of remembering passwords made up of random strings of letters, numbers, and symbols, many users either write them down near their computers or settle for less complicated passwords, which raises the risk of hacking. To alleviate this problem, researchers at Microsoft and other companies are looking into image-based password systems. Microsoft has developed a tool in which users log in by clicking on certain parts of an image in a certain order; users can set a range of pixels around each location so that they do not have to be too precise in where they click. Microsoft researcher Dr. Darko Kirovski thinks that a picture must have a minimum of 500 clickable regions in order to be suitable as a password, and is devising a program to assess such suitability with two colleagues. Meanwhile, Real User is working on a system in which users create passwords by choosing photos of human faces, and then log in by identifying those particular faces in a grid that is also filled with decoys. Carnegie Mellon University's Dr. Michael Reiter believes that comprehensive user trials will need to be conducted to determine whether graphical password systems truly improve security. At the University of California, Berkeley, Adrian Perrig is developing a password system that solves the problem of shoulder surfing: In his concept, users familiarize themselves with a virtual world, and sign on by determining locations chosen at random. http://www.nytimes.com/2002/05/02/technology/circuits/02NEXT.html (Access to this site is free; however, first-time visitors must register.) http://www.giac.org/practical/donald_smith_gcia.doc http://www.chkrootkit.org/ http://www.cs.princeton.edu/~jns/security/iptables/ http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm Rajouter exemple ssh compliqué :ISIA, maison ENSMP,ENSTBr; machine //, Reactive,... Mettre exemple attaque clé publique Firewalls sous Linux http://www.linuxsecurity.com/resources/firewalls-3.html iptables Tutorial 1.1.6 http://www.linuxsecurity.com/resource_files/firewalls/IPTables-Tutorial/iptables-tutorial.html IPTables Linux firewall with packet string-matching support http://www.securityfocus.com/infocus/1531 A Comparison of iptables Automation Tools http://www.securityfocus.com/infocus/1410 Linux 2.4: Next Generation Kernel Security http://www.linuxsecurity.com/feature_stories/kernel-24-security-printer.html StegFS - A Steganographic File System for Linux http://www.mcdonald.org.uk/StegFS/ -- http://www.whitefang.com/sup/ Secure UNIX Programming FAQ From: Jacques Beigbeder Subject: [enssec] la semaine du 30/11 au 6/12 To: enssec@ens.fr Date: Sat, 8 Dec 2001 13:43:52 +0100 2. Le premier W32/Goner@MM a été intercepté le 4/12, 19h15. 15 minutes après la mise en place des signatures anti-virus permettant de le reconnaitre. On est donc en plein dans la question que je posais dans: http://www.cnrs.fr/Infosecu/num32-sansFond.pdf Le virus est fort probablement déjà arrivé dans des mailboxes, peut-on le rechercher? Non: car le courrier est inviolable. Cf les procès en cours. Oui: sinon les admin. vont être accusés de négligence, sachant que des PC/Windows vont être infectés! 713 10:54 x ssh-keygen -t rsa -N '' 717 10:56 x scp /.ssh/id_rsa.pub reactived1:.ssh/authorized_keys2 718 10:57 x ssh reactived1 http://www.techtv.com/callforhelp/projects/jump/0%2c23009%2c3015162%2c00.html http://www.networkuptime.com/tools/unix/mgmt/trend/ http://www.hsc.fr/ressources/breves/secretssh.html A. M. © Internet Actu 25/10/2001 _____________________________________________________ ENTREPRISES C'est reparti comme en 14 ! Cette semaine, Microsoft est parti en guerre contre les développeurs de virus. Dans une lettre ouverte, publiée sur le site de la firme de Redmond, Scott Culp, dirigeant de la cellule sécurité, préconise d'utiliser une arme nouvelle. Partant d'un constat d'échec de la sécurisation des logiciels, Scott Culp envisage simplement de s'attaquer à l'information concernant les trous de sécurité, plus rapidement qu'aux défauts de ses programmes. Selon lui, l'industrie logicielle toute entière doit interdire la divulgation des caractéristiques des vers et autres virus. Intitulée "Il est temps de mettre fin à l'anarchie de l'information", la profession de foi du dirigeant de Microsoft a de quoi effrayer. Tout d'abord, on est abasourdi par la mauvaise foi de Scott Culp qui met sur le même plan, sans vergogne, les cratères de sécurité de Windows et les chas d'aiguille exploitables sur Gnu/Linux. Comme pour excuser la faiblesse des programmes Microsoft, Scott Culp les situe "parmi les choses les plus compliquées que l'humanité ait jamais développées". Cette hypothèse posée, il termine de noircir le tableau en lançant : "Il y aura toujours des trous de sécurité." Il faut dire que cela fait longtemps que l'on avait cessé d'espérer le contraire. Les hackers et autres développeurs de virus ont de beaux jours devant eux. Quelle arme utiliser alors ? Scott Culp préconise une censure qui ne dit pas son nom, et qu'il préfère appeler "responsabilisation au nom de la sécurité des utilisateurs". Il promet que son entreprise s'emploiera à convaincre ses partenaires de ne plus détailler les trous de sécurité, même après publication et mise à disposition des "patches" qui, selon lui, ne sont pas suffisamment appliqués sur les produits vendus. Une manière comme une autre de rejeter la Culp... abilité sur les autres ! http://www.microsoft.com/technet/treeview/default.asp?url=/technet/colum ns/security/noarch.asp M. J. © Internet Actu 25/10/2001 Sur le plan des virus la vigilance doit etre permanente. Les utilisateurs doivent etre avertis des dangers de la messagerie electronique: "Virus Informatiques et autres malignites" http://www.cnrs.fr/Infosecu/Virus.html "Les virus" http://cache.univ-tlse1.fr/documentations/virus Pour info: "UNIX Security Checklist v2.0 - The Essentials" (ou comment mieux configurer et surveiller un systeme Unix pour limiter les risques) http://www.auscert.org.au/Information/Auscert_info/Papers/usc20_essentials.html Sécurité optimale = Maximum security ; traduit de l'américain par Christian Soubrier. - 2e éd. - CampusPress ; Paris, 1999. - XXI-786 p. . - ; 23 cm + CD-ROM. - (Références) . - ISBN 2-7440-0723-4 (br) . - Glossaire. Index Descripteurs : Administration réseau, Sécurité informatique, Protection information, Pare feu, Droit informatique, Internet Classification : 02.28 Cote : 2.28 SOUB Cours de cryptographie / Gilles Zémor. - Paris : Cassini, 2000. - 227 p. ; 23 cm. - (Enseignement des mathématiques ; 6) ISBN 2-84225-020-6 (br.) . - Bibliogr. Index Descripteurs :Cryptographie, Théorie nombre, Clé secrète, Complexité, Code correcteur erreur Classification : 07.24 Cote : 7.24 ZEMO http://www.kitetoa.com/index2.htm From: Jacques Beigbeder Subject: [enssec] Advisory: Statistical Weaknesses in TCP/IP Initial Sequence Numbers To: enssec@ens.fr Date: Fri, 4 May 2001 10:49:19 +0200 Si je résume ce long mail: . Linux protégé depuis 1996 . FreeBSD depuis la version 2.8 . Solaris Sun implemented RFC 1948 beginning with Solaris 2.6, but it isn't turned on by default. On Solaris 2.6, 7 and 8, edit /etc/default/inetinit to set TCP_STRONG_ISS to 2. On a running system, use: ndd -set /dev/tcp tcp_strong_iss 2 ===================================================================== CERT-Renater Note d'Information No. 2001/VULN134 _____________________________________________________________________ DATE : 03/05/2001 HARDWARE PLATFORM(S) : / OPERATING SYSTEM(S) : / ====================================================================== CERT Advisory CA-2001-09 Statistical Weaknesses in TCP/IP Initial Sequence Numbers Original release date: May 01, 2001 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected * Systems using TCP stacks which have not incorporated RFC1948 or equivalent improvements * Systems not using cryptographically-secure network protocols like IPSec Overview Attacks against TCP initial sequence number (ISN) generation have been discussed for some time now. The reality of such attacks led to the widespread use of pseudo-random number generators (PRNGs) to introduce some randomness when producing ISNs used in TCP connections. Previous implementation defects in PRNGs led to predictable ISNs despite some efforts to obscure them. The defects were fixed and thought sufficient to limit a remote attacker's ability to attempt ISN guessing. It has long been recognized that the ability to know or predict ISNs can lead to manipulation or spoofing of TCP connections. What was not previously illustrated was just how predictable one commonly used method of partially randomizing new connection ISNs is in some modern TCP/IP implementations. A new vulnerability has been identified (CERT VU#498440, CVE CAN-2001-0328) which is present when using random increments to constantly increase TCP ISN values over time. Because of the implications of the Central Limit Theorem, adding a series of numbers together provides insufficient variance in the range of likely ISN values allowing an attacker to disrupt or hijack existing TCP connections or spoof future connections against vulnerable TCP/IP stack implementations. Systems relying on random increments to make ISN numbers harder to guess are still vulnerable to statistical attack. I. Description Some History In 1985, Bob Morris first identified potential security concerns [ref_morris] with the TCP protocol. One of his observations was that if a TCP sequence number could be predicted, an attacker could "complete" a TCP handshake with a victim server without ever receiving any responses from the server. One result of the creation of such a "phantom" connection would be to spoof a trusted host on a local network. In 1989, Steve Bellovin [ref_bellovin] observed that the "Morris" attack could be adapted to attack client connections by simulating unavailable servers and proposed solutions for strengthening TCP ISN generators. In 1995, the CERT Coordination Center issued CA-1995-01, which first reported the widespread use of such attacks on the Internet at large. Later in 1995, as part of RFC1948, Bellovin noted: The initial sequence numbers are intended to be more or less random. More precisely, RFC 793 specifies that the 32-bit counter be incremented by 1 in the low-order position about every 4 microseconds. Instead, Berkeley-derived kernels increment it by a constant every second, and by another constant for each new connection. Thus, if you open a connection to a machine, you know to a very high degree of confidence what sequence number it will use for its next connection. And therein lies the attack. Also in 1995, work by Laurent Joncheray [ref_joncheray] further describes how an attacker could actively hijack a TCP connection. If the current sequence number is known exactly and an attacker's TCP packet sniffer and generator is located on the network path followed by the connection, victim TCP connections could be redirected. In his recently published paper on this issue, [ref_newsham] Tim Newsham of Guardent, Inc. summarizes the more generalized attack as follows: As a result, if a sequence number within the receive window is known, an attacker can inject data into the session stream or terminate the connection. If the ISN value is known and the number of bytes sent already sent is known, an attacker can send a simple packet to inject data or kill the session. If these values are not known exactly, but an attacker can guess a suitable range of values, he can send out a number of packets with different sequence numbers in the range until one is accepted. The attacker need not send a packet for every sequence number, but can send packets with sequence numbers a window-size apart. If the appropriate range of sequence numbers is covered, one of these packets will be accepted. The total number of packets that needs to be sent is then given by the range to be covered divided by the fraction of the window size that is used as an increment. Many TCP/IP implementers turned to incrementing the global tcp_iss [TCP Initial Send Sequence number, a.k.a., an ISN] variable using pseudo-random variables instead of constants. Unfortunately, the randomness of the pseudo-random-number generators (PRNGs) used to generate the "random" increments was sometimes lacking (see CVE-1999-0077, CVE-2000-0328, CAN-2000-0916, CAN-2001-0288, among others). As noted in RFC1750: It is important to keep in mind that the requirement is for data that an adversary has a very low probability of guessing or determining. This will fail if pseudo-random data is used which only meets traditional statistical tests for randomness or which is based on limited range sources, such as clocks. Frequently such random quantities are determinable by an adversary searching through an embarrassingly small space of possibilities. Eastlake, Crocker, and Schiller were focused on randomness in cryptographic systems, but their observation was equally applicable in any system which relies on random number generation for security. It has been noted in the past that using such poor PRNGs can lead to smaller search spaces and make TCP ISN generators susceptible to practical brute-force attacks. However, new research demonstrates that the algorithm implemented to generate ISN values in many TCP/IP stacks is statistically weak and susceptible to attack even when the PRNG is adequately randomizing its increments. The problem lies in the use of increments themselves, random or otherwise, to advance an ISN counter, making statistical guessing practical. Some Fresh Analysis: Guardent Tim Newsham of Guardent, Inc. has written a paper titled "The Problem with Random Increments" [ref_newsham] concerning an observed statistical weakness in initial sequence number generation for TCP connections. Newsham explains how incrementing the ISN by a series of pseudo-random amounts is insufficient to protect some TCP implementations from a practical ISN guessing attack in some real-world situations. Such attacks would not rely on data sniffed from a victim site but only on one or two ISN samples collected by previous connections made to a victim site. Newsham's statistical analyses provide a theoretical backdrop for practical attacks, drawing attention once again to the protocol analysis documented by Steve Bellovin (building on work pioneered by Robert Morris) in RFC1948. Newsham points out that the current popular use of random increments to obscure an ISN series still contains enough statistical information to be useful to an attacker, making ISN guessing practical enough to lead to TCP connection disruption or manipulation. This attack is possible because an attacker can still predict within "a suitable range of values" what the next (or a previous) ISN for a given TCP connection may be. This range can be derived when looking at the normal distribution that naturally arises when adding a large number of values together (random or otherwise) due to expected values governed by the Central Limit Theorem [ref_clt]: Roughly, the central limit theorem states that the distribution of the sum of a large number of independent, identically distributed variables will be approximately normal, regardless of the underlying distribution. In addition to statistical analysis of this weakness, Newsham's paper demonstrates the weakness inherent in one specific TCP/IP implementation. In other recently-published research, Michal Zalewski of BindView surveys over 20 different ISN generators included in many of the most widely available operating systems on the Internet today. Their work shows in graphic detail how observable this statistical weakness is. Some Fresh Empirical Evidence: BindView Analysts at BindView have produced interesting research that analyzes the patterns many of the most popular TCP/IP stacks produce when producing ISNs. In a paper titled "Strange Attractors and TCP/IP Sequence Number Analysis," [ref_zalewski] author Michal Zalewski uses phase analysis to show patterns of correlation within sets of 32-bit numbers generated by many popular operating systems' TCP ISN generators. As Zalewski explains: Our approach is built upon this widely accepted observation about attractors: If a sequence exhibits strong attractor behavior, then future values in the sequence will be close to the values used to construct previous points in the attractor. Our goal is to construct a spoofing set, and, later, to calculate its relative quality by empirically calculating the probability of making the correct ISN prediction against our test data. For the purpose of ISN generators comparison , we established a limit of guess set size at the level of 5,000 elements, which is considered a limit for trivial attacks that does not require excessive network bandwidth or processing power and can be conducted within few seconds. (A "spoofing set" is defined as "a set of guessed values for ISNs that are used to construct a packet flood that is intended to corrupt some established TCP connections." Please see [ref_zalewski] for more information about phase space analysis and attractor reconstruction). In effect, using this technique for data visualization, they are able to highlight emergent patterns of correlation. Such correlation, when present in TCP ISN generators, can dramatically shrink the set of numbers that need to be guessed in order to attack a TCP session. Since the sequence number for TCP sessions is stored in packet headers using 32-bits of data, it was generally assumed that an attacker would have a very small chance of correctly guessing a sequence number to attack established (or to-be established) connections. BindView's research shows attackers actually have much smaller bit-spaces to guess within due to dependencies on system clocks and other implementation defects. Zalewski further notes in his paper [ref_zalewski]: What comes to our attention is that most every implementation described above, except maybe current OpenBSD and Linux, has more or less serious flaws that make short-time TCP sequence number prediction attacks possible. Solaris 7 and 8 with tcp_strong_iss set to 2 results are a clear sign there are a lot of things to do for system vendors. We applied relatively loose measures, classifying attacks as "feasible" if they can be accomplished using relatively low bandwidth and a reasonable amount of time. But, as network speeds are constantly growing, it would be not a problem for an attacker having access to powerful enough uplink to search the entire 32-bit ISN space in several hours, assuming a local LAN connection to the victim host and assuming the network doesn't crash, although an attack could be throttled to compensate. The work done by Guardent and BindView illustrates that not all current TCP/IP ISN generators have implemented the suggestions made by Steve Bellovin in RFC1948 to address prediction-based ISN attacks, or provided a equivalent fixes. In particular, TCP/IP stacks based on operating system software which has not previously incorporated RFC1948 or equivalent fixes will be susceptible to classic TCP hijacking in the absence of other cryptographically secure hardening (i.e., when not using IPSec or an equivalent secure networking technology). Much work remains to be done to ensure the systems deployed using TCP today and tomorrow have strengthened their ISN generators using RFC1948 recommendations or equivalent fixes. II. Impact If the ISN of an existing or future TCP connection can be determined within some practical range, a malicious agent may be able to close or hijack the TCP connections. If the ISNs of future connections of a system are guessed exactly, an agent may be able to "complete" a TCP three-way handshake, establish a phantom connection, and spoof TCP packets delivered to a victim. The ability to spoof TCP packets may lead to other types of system compromise, depending on the use of IP-based authentication protocols. Examples of such attacks have been previously described in CA-1995-01 and CA-1996-21. III. Solution The design of TCP specified by Jon Postel in RFC793 specifically addressed the possibility of old packets from prior instantiations of a connection being accepted as valid during new instantiations of the same connection, i.e., with the same 4-tuple of : To avoid confusion we must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation. We want to assure this, even if a TCP crashes and loses all knowledge of the sequence numbers it has been using. When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32-bit ISN. The generator is bound to a (possibly fictitious) 32-bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN's will be unique. Several criteria need to be kept in mind when evaluating each of the following solutions to this problem: 1. Does the soulution address the security concerns identified in this advisory? 2. How well does the solution conform for TCP reliability and interoperability requirements? 3. How easily can the solution be implemented? 4. How much of a performance cost is associated with the solution? 5. How well will the solution stand the test of time? In the discussions following the initial report of this statistical weakness, several approaches to solving this issue were identified. All have various strengths and weaknesses themselves. Many have been implemented independently by various vendors in response to other reported weaknesses in specific ISN generators. Deploy and Use Cryptographically Secure Protocols TCP initial sequence numbers were not designed to provide proof against TCP connection attacks. The lack of cryptographically-strong security options for the TCP header itself is a deficiency that technologies like IPSec try to address. It must be noted that in the final analysis, if an attacker has the ability to see unencrypted TCP traffic generated from a site, that site is vulnerable to various TCP attacks - not just those mentioned here. The only definitive proof against all forms of TCP attack is end-to-end cryptographic solutions like those outlined in various IPSec documents. The key idea with an end-to-end cryptographic solution is that there is some secure verification that a given packet belongs in a particular stream. However, the communications layer at which this cryptography is implemented will determine its effectiveness in repelling ISN based attacks. Solutions that operate above the Transport Layer (OSI Layer 4), such as SSL/TLS and SSH1/SSH2, only prevent arbitrary packets from being inserted into a session. They are unable to prevent a connection reset (denial of service) since the connection handling will be done by a lower level protocol (i.e., TCP). On the other hand, Network Layer (OSI Layer 3) cryptographic solutions such as IPSec prevent both arbitrary packets entering a transport-layer stream and connection resets because connection management is directly integrated into the secure Network Layer security model. The solutions presented above have the desirable attribute of not requiring any changes to the TCP protocol or implementations to be made. Some sites may want to investigate hardening the TCP transport layer itself though. RFC2385 ("Protection of BGP Sessions via the TCP MD5 Signature Option") and other technologies provide options for adding cryptographic protection within the TCP header at the cost of some potential denial of service, interoperability, and performance issues. The use of cryptographically secure protocols has several advantages over other possible solutions to this problem. Protection against hijacking and disruption are provided by the cryptography, while the TCP layer is free to return to a simple increasing sequence number mechanism, providing the greatest level of reliability. The performance, durability, and practicality of implementation will vary according to the protocol selected, but IPSec in particular appears to have a number of positive attributes in this regard. Use RFC1948 Implementations In RFC1948, Bellovin observed that if the 32-bit ISN space could be segmented across all the ports available to a system, collecting sample ISNs from one connection could yield little or no information about the ISNs being generated in other connections. Breaking the reliance on a global ISN pool by using cryptographically hashed secrets and [IP, port] 4-tuples effectivly eliminates TCP ISN attacks by remote users (unless, of course, attackers able to sniff traffic on a local network segment). Newsham notes in his paper [ref_newsham]: RFC 1948 [ref1] proposes a method of TCP ISN generation that is not vulnerable to ISN guessing attacks. The solution proposed partitions the sequence space by connection identifiers. Each connection identifier, which is composed of the local address and port and the remote address and port of a connection, is assigned its own unique sequence space starting at an offset that is a function of the connection identifier. The function is chosen in such a way that it cannot be computed by an attacker. The ISN is then [...] generated by increments to this offset. ISN values generated in this way are not vulnerable to ISN range prediction methods outlined in this paper since an attacker cannot gain knowledge of the ISN space for any connection identifiers he cannot directly observe. Once the global ISN space becomes segmented among all the TCP ports available on a system, attacking TCP ISNs remotely becomes impractical. However, it should be noted that even when using RFC1948 implementations, some forms of ISN attack remain viable under very specific conditions, as discussed in further detail below. In addition, using a cryptographically strong hash function to perform this segmentation may lead to longer TCP connection establishment time. Some implementors (like those of the Linux kernel) have chosen to use a reduced-round MD4 hash function to provide a "good enough" solution from a security standpoint to keep performance degradation to a minimum. One cost of weakening the hash algorithm is the need to re-key the generator every few minutes. Each time a re-keying occurs, security is strengthened, but other reliability issues identified in RFC793 become a concern. It had been understood (but not widely noted) that ISNs generated by a "strictly-compliant" RFC1948 generator would still allow ISN guessing attacks to be made against previously-owned IP addresses. If an attacker could "own" an IP address used by a potential victim at some point afterward, given enough sample ISNs collected within the shared [IP, port] 4-tuple ISN space, an attacker could make reasonable guesses about the ISNs of subsequent connections. This is because strict RFC1948 suggests the following algorithm: ISN = M + F(sip, sport, dip, dport, ) where ISN = 32-bit initial sequence number M = monotonically increasing clock/counter F = crypto hash (typically MD4 or MD5) sip = source IP sport = source port dip = destination IP dport = destination port = an optional fifth input into the hash function to make remote IP attacks unfeasible. For the ISN itself to monotonically (constantly) increase, F() needs to remain fairly static. So the envisioned by Bellovin was a system-specific value (such as boot time, a passphrase, initial random value, etc) which would infrequently change. Each time it changes, the value of F() (a hash) changes and there is no guarantee that subsequent ISNs will be sufficiently distanced from the previous value assigned, raising the potential RFC793 reliability concern again. When viewed from the perspective of a particular [IP, port] 4-tuple, the ISN sequence is predictable and therefore subject to practical attacks. When looking at the Solaris tcp_strong_iss generator (RFC1948) from the perspective of a remote IP attacker, for example, the ISNs generated appear random. However, the Zalewski paper analyzes data which looks at both the remote and same-IP address attack vectors. Their data confirms the same-IP attack vector against Solaris tcp_strong_iss=2 (RFC1948) is a practical attack. The Linux TCP implementors avoided this issue by rekeying every five minutes. Unfortunately, this breaks the monotonicity of the algorithm, weakening the iron-clad reliability guarantee that Bellovin was hoping to preserve by segmenting the ISN space among ports in the first place. Some have proposed that the following algorithm may be a better answer to this issue: M = M + R(t) ISN = M + F(sip, sport, dip, dport, ) where R(t) = some random value changing over time This is essentially adding a random increment to the RFC1948 result. This makes most attacks impractical, but still theoretically possible. (It would still be "RFC1948-compliant" as well ... RFC1948 makes as few assumptions about the F() incrementing function as possible, requiring only that the connection [IP, port] 4-tuple be inputs to the function and that it be practically irreversible.) However, the "problem" of random increments was what brought this issue back into the spotlight to begin with. Use Some Other Non-RFC1948 Approaches A more direct solution chosen by some TCP implementors is to simply feed random numbers directly into the ISN generator itself. That is, given a 32-bit space to choose from, assign: ISN = R(t) Solutions which essentially randomize the ISN seem to mitigate against the practical guessing attack once and for all (assuming strong pseudo-random number generation). However, a purely-random approach allows for overlapping sequence numbers among subsequently-generated TCP connnections sharing [IP, port] 4-tuples. For example, a random generator can produce the same ISN value three times in a row. This runs contrary to multiple RFC assumptions about monotonically increasing ISNs (RFC 793, RFC 1185, RFC 1323, RFC1948, possibly others as well). It is unclear what practical effect this will have on the long-term reliability guarantees the TCP protocol makes or is assumed to make. Another novel approach introduced by Niels Provos of the OpenBSD group tries to strike a balance between the fully-random and segmented (RFC1948) approaches: ISN = ((PRNG(t)) << 16) + R(t) where PRNG(t) = a pseudo-randomly ordered list of sequentially-generated 16-bit numbers R(t) = a 16-bit random number generator with its msb always set to zero (This formula is an approximation of the results the OpenBSD implementation actually generates. Please see their actual code at: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/tcp_subr.c) What the Provos implementation effectively does is generate a psuedo-random sequence that will not generate duplicate ISN values within a given time period. Additionally, each ISN value generated is guaranteed to be at least 32K away from other ISN values. This avoids the purely-random ISN collision problem, as well as makes a stronger attempt to keep sequence number spaces of subsequent [IP, port] 4-tuple connections from overlapping. It also avoids the use of a cryptographic hash which could degrade performance. However, monotonicity is lost, potentially causing reliability problems, and the generator may leak information about the system's global ISN state. Further discussion and analysis on the importance of such attributes needs to occur in order to ascertain the characteristics present in each ISN generator implemented. Empirical evidence provided by BindView may indicate that from a predictability standpoint, the solutions are roughly equivalent when viewed from a remote attackers perspective. It is unclear at the time of this writing what the security, performance, and reliability tradeoffs truly are. Appendix A. - Vendor Information This appendix contains information provided by vendors for this advisory. When vendors report new information to the CERT/CC, we update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments. Cisco Systems Cisco systems now use a completely random ISN generator. Please see the following for more details: http://www.cisco.com/warp/public/707/ios-tcp-isn-random-pub.shtml Compaq Computer Corporation At the time this document was written, Compaq is investigating the potential impact to Compaq's Tru64 UNIX and OPENVMS operating systems. Compaq views the problem to be a concern of moderate severity. Compaq implementations of TCP/IP sequence randomization for Tru64 UNIX for Alpha and OpenVMS for Alpha follow current practices for implementation of TCP/IP initial sequence numbers. If and when further information becomes available Compaq will provide notice of the completion/availability of any necessary patches or tuning recommendations through AES services (DIA, DSNlink FLASH and posted to the Services WEB page) and be available from your normal Compaq Global Services Support channel. You may subscribe to several operating system patch mailing lists to receive notices of new patches at: http://www.support.compaq.com/patches/mailing-list.shtml FreeBSD, Inc. FreeBSD has adopted the code and algorithm used by OpenBSD 2.8-current in FreeBSD 4.3-RELEASE and later, and this release is therefore believed not to be vulnerable to the problems described in this advisory (for patches and information relating to older releases see FreeBSD Security Advisory 01:39). We intend to develop code in the near future implementing RFC 1948 to provide a more complete solution. Fujitsu Fujitsu is currently working on the patches for the UXP/V operating system to address the vulnerabilities reported in VU#498440. The patches will be made available with the following ID numbers: OS Version,PTF level patch ID -------------------- -------- UXP/V V20L10 X01021 UX28164 UXP/V V20L10 X00091 UX28163 UXP/V V10L20 X01041 UX15529 Hewlett-Packard Company HP has been tracking tcp randomization issues over the years, and has to date implemented the following: For 11.00 and 11.11 (11i): _______________________________ For 11.00, if you want HP's solution for randomized ISN numbers then apply TRANSPORT patch PHNE_22397. Once you apply PHNE_22397, there's nothing more to do --- default is randomized ISNs. (Note: PHNE_22397 has patch dependencies unrelated to ISN randomized ISN number modification listed in the dependency section, but they should still be also applied. One is a PHKL kernel patch dependency and the other STREAMS/UX minimum level patch dependency.) The LR release of 11.11 (11i) has the same random ISN implementation as the patched 11.00. For releases up to, but not including 10.30: _______________________________ HP has key parameters that were made tunable to be able to select two levels of levels of randomization with patch PHNE_5361, a TRANSPORT Megapatch, which applies to releases up to (but not including) 10.30. Check patch text for details. It is done with nettune, and requires a reboot: tcp_random_seq set to 0 (Standard TCP sequencing) tcp_random_seq set to 1 (Random TCP sequencing) tcp_random_seq set to 2 (Increased Random TCP sequencing) IBM Corporation We have studied the document written by Guardent regarding vulnerabilities caused by statistical analysis of random increments, that may allow a malicious user to predict the next sequence of chosen TCP connections. IBM's AIX operating system should not be vulnerable as we have implemented RFC 1948 in our source coding. According to Guardent, we do not expect an exploit described in the document to affect our AIX OS because we employ RFC 1948. Linux The Linux kernel has used a variant of RFC1948 by default since 1996. Please see: http://lxr.linux.no/source/drivers/char/ChangeLog#L258 http://lxr.linux.no/source/drivers/char/random.c#L1855 OpenBSD post-2.8 we no longer use random increments, but a much more sophisticated way. SGI SGI implemented RFC 1948 with MD5 on IRIX 6.5.3 and above using the tcpiss_md5 tunable kernel parameter, but the default is disabled. To enablee tcpiss_md5 kernel parameter, use the following command as root: # /usr/sbin/systune -b tcpiss_md5 1 To verify RFC 1948 has been enabled in IRIX, use the following command as root: # /usr/sbin/systune tcpiss_md5 This should return: tcpiss_md5 = 1 (0x1) The latest IRIX 6.5 Maintenance Releases can be obtained from the URL: http://support.sgi.com/colls/patches/tools/relstream/index.html An SGI security advisory will be issued for this issue via the normal SGI security information distribution methods including the wiretap mailing list and http://www.sgi.com/support/security/ . Sun Microsystems, Inc. Sun implemented RFC 1948 beginning with Solaris 2.6, but it isn't turned on by default. On Solaris 2.6, 7 and 8, edit /etc/default/inetinit to set TCP_STRONG_ISS to 2. On a running system, use: ndd -set /dev/tcp tcp_strong_iss 2 Appendix B. - References 1. Postel, J., "RFC 793: TRANSMISSION CONTROL PROTOCOL: DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION," September 1981. ftp://ftp.isi.edu/in-notes/rfc793.txt 2. Eastlake, D., Crocker, S., Schiller, J., "RFC 1750: Randomness Recommendations for Security," December 1994. ftp://ftp.isi.edu/in-notes/rfc1750.txt 3. Bellovin, S., "RFC 1948: Defending Against Sequence Number Attacks," May 1996. ftp://ftp.isi.edu/in-notes/rfc1948.txt 4. Heffernan, A., "RFC 2385: Protection of BGP Sessions via the TCP MD5 Signature Option," August 1998. ftp://ftp.isi.edu/in-notes/rfc2385.txt 5. Thayer, R., Doraswamy, N., Glenn, R., "RFC 2411: IP Security Document Roadmap," November 1998. ftp://ftp.isi.edu/in-notes/rfc2411.txt 6. CERT Advisory CA-1995-01: IP Spoofing Attacks and Hijacked Terminal Connections http://www.cert.org/advisories/CA-1995-01.html 7. CERT Advisory CA-1996-21: TCP SYN Flooding and IP Spoofing Attacks http://www.cert.org/advisories/CA-1996-21.html 8. A Weakness in the 4.2BSD UNIX TCP/IP Software, Morris, R., ComputingScience Technical Report No 117, ATT Bell Laboratories, Murray Hill,New Jersey, 1985. ftp://research.att.com/dist/internet_security/117.ps.Z 9. Security Problems in the TCP/IP Protocol Suite, Bellovin, S., Computer Communications Review, April 1989. http://www.research.att.com/~smb/papers/ipext.ps http://www.research.att.com/~smb/papers/ipext.pdf 10. Simple Active Attack Against TCP, Joncheray, L., Proceedings, 5th USENIX UNIX Security Symposium, June 1995. http://www.usenix.com/publications/library/proceedings/security95/ full_papers/joncheray.txt 11. Newsham, T., "Guardent White Paper: The Problem with Random Increments," February 2001. http://www.guardent.com/comp_news_tcp.html 12. Zalewski, M., "Razor Paper: Strange Attractors and TCP/IP Sequence Number Analysis," April 2001. http://razor.bindview.com/publish/papers/tcpseq.html 13. Virtual Laboratories in Probability and Statistics, Random Samples Section 5: The Central Limit Theorem 14. CVE-1999-0077 15. CVE-2000-0328 16. CAN-2000-0916 17. CAN-2001-0288 18. CAN-2001-0328 19. Havrilla, J., "CERT Vulnerability Note VU#498440: Multiple TCP/IP implementations may use statistically predictable initial sequence numbers", March 2001. https://www.kb.cert.org/vuls/id/498440 _________________________________________________________________ The CERT/CC thanks Guardent, Inc. and BindView for their invaluable contributions to this advisory. We also thank all the vendors who participated in the discussion about this vulnerability and proposed solutions. We also thank the following people for their individual contributions to this advisory: * Steve Bellovin, AT&T Labs * Kris Kennaway, FreeBSD * Mark Loveless, Bindview * Tim Newsham, Guardent, Inc. * Niels Provos, OpenBSD * Damir Rajnovic, Cisco * Theo de Raadt, OpenBSD * Theodore Tso, MIT _________________________________________________________________ Authors: Jeffrey S. Havrilla, Cory F. Cohen, Roman Danyliw, and Art Manion. ______________________________________________________________________ This document is available from: http://www.cert.org/advisories/CA-2001-09.html ______________________________________________________________________ CERT/CC Contact Information Email: cert@cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo@cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. ______________________________________________________________________ NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. _________________________________________________________________ Conditions for use, disclaimers, and sponsorship information Copyright 2001 Carnegie Mellon University. Revision History May 01, 2001: Initial release -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBOu8/ewYcfu8gsZJZAQHyywP+NnCTtLUfl/3wiSERXEA5TS7v6GQzBLEQ ykDwtR3IqeHO4U6a16Ta2+hHtz85C2g0LeZ69amAKGPaAP6CUIPx+UxgZLrQUaD2 2EyEsw+TupWd3XArkX3YIywDZeLRw6FWInT/9xyxRR2gSbVFzjfkC4u3v0SvBwO2 44CQY1lI6bk= =aPms -----END PGP SIGNATURE----- ====================================================================== ========================================================= Les serveurs de référence du CERT-Renater http://www.urec.fr/securite http://www.cru.fr/securite http://www.renater.fr ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 151 bd de l'Hopital | fax : 01-53-94-20-41 + + 75013 Paris | email: certsvp@renater.fr + ========================================================= ----- End forwarded message ----- Approved-By: Russ.Cooper@RC.ON.CA MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Date: Fri, 30 Mar 2001 15:27:47 -0800 From: Phil Cox Subject: Hardening Windows 2000 document v1.0 Comments: To: Focus on Microsoft Mailing List , WIN2KSECADVICE@LISTSERV.NTSECURITY.NET To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM All, I have finally condensed chapter 21 of my book in to a paper about hardening Win2K. I hope this proves helpful. There is a link to download the pdf on http://www.systemexperts.com/win2k.shtml It is different than Stephan Norberg's, in that it is not specific to a bastion host, but goes through the steps to harden a system to just about any level you want. Also since it is a more "general" document, I am sure that there will be many suggestions and disagreements. I will do my level best to make this a living document, and make regular version updates. Also, I have gotten a couple of Security Configuration Manager "inf" files, and as I get more (or make them) for specific host configurations, I will make a "zip" file of them. As with all things from the net, please do understand what you get. Take a look through the "inf" files before you use them, and always test them on a non-production system first. Phil ---------------------------------------------------------------------------- Delivery co-sponsored by BindView Corporation ============================================================================ Are your security practices adequate enough to protect you from hackers and crackers? How do you provide remote access to your users, enable e-mail messaging, Internet sites and e-commerce activity, and at the same time maintain security? Can you implement and administer the effective security measures you need without doing battle with the people who need access to your network? Download FREE the latest Hurwitz Group Report, Management Controls: Security Impact of IT Administration at Approved-By: Russ.Cooper@RC.ON.CA MIME-Version: 1.0 Date: Sun, 22 Apr 2001 20:20:45 -0500 From: Lance Spitzner Subject: "Know Your Enemy: Honeynets" and S-ot-M To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Know Your Enemy: Honeynets -------------------------- For several years the Honeynet Project has been developing the Know Your Enemy series, which is dedicated to the tools, tactics and motives of the blackhat community. We are excited to announce our newest release, Know Your Enemy: Honeynets Instead of focusing on blackhats, this paper focuses on Honeynets, our primary tool of information gathering. Specifically what a Honeynet is, its value, how to build one, and risks/issues involved. You can find this online at http://project.honeynet.org/papers/honeynet/ Scan of the Month ----------------- Results for April's Scan of the Month have been released. Learn some of the common tools and tactics used by blackhats once they attack and compromise an NT server. We had 23 submissions this month, with an average of 9 hours of analysis for each submission. http://project.honeynet.org/scans/scan14/ Thanks! -- Lance Spitzner http://project.honeynet.org From: Francis Dupont To: sec@ossir.org Subject: la crypto > 64 bits retiree de l'accord de Wassenaar Date: Thu, 15 Mar 2001 21:55:18 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-From: sec@ossir.org X-Mailing-List: archive/latest/4604 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org Content-Length: 901 X-Status: $$$$ Dans une discussion à propos d'AES dans la list IPsec de l'IETF (faut-il le rendre l'AES obigatoire - est qu'il y a un pb d'exportation - ...) quelqu'un affirme que la restriction aux clés de 64 bit a été supprimée ! Le contexte : - l'accord de Wassenaar réglemente l'exportation des armes et des technologies à double usage (civil et militaire). cf: http://www.wassenaar.org/ - cet accord a valeur de traité (donc peut rajouter des limites supplémentaires, d'ailleurs le projet de loi fait allusion à ça) - l'accord a été mis à jour à la suite d'une réunion cf: http://www.wassenaar.org/list/Summary.html - l'accord classifiait la crypto symétrique avec des clés de plus de 64 bits comme technologie à double usage, ceci a été supprimé cf http://www.wassenaar.org/list/Cat%205P2%20-%2099.pdf (le point d du 5.A.2) Quelqu'un en sait-il plus? Francis.Dupont@enst-bretagne.fr Date: Tue, 13 Mar 2001 19:46:31 +0100 To: sec@ossir.org, nt-securite@ossir.org From: Laurent LEVIER Subject: Performances de 16 firewalls comparées Mime-Version: 1.0 Resent-From: nt-securite@ossir.org X-Mailing-List: archive/latest/777 X-Loop: nt-securite@ossir.org Resent-Sender: nt-securite-request@ossir.org Content-Length: 827 X-Status: $$$$ Messieurs, J'avais vu dernierement des demandes en ce sens. Voici une URL interessante: http://www.idg.net/ic_473844_1794_9-10000.html Il s'agit d'une comparaison de firewall commerciaux: Cisco's PIX 525; Check Point's Firewall-1; Computer Associates' eTrust; CyberGuard's KnightStar; Enternet's Enternet Firewall; Lucent's Brick; NetScreen's NetScreen-100; Network-1's CyberwallPlus; Network Associates' WebShield; Novell's BorderManager; Nokia's IP650; Secure Computing's SideWinder; SonicWall's SonicWall Pro VX; Symantec's Raptor; TopLayer's AppSwitch 3500; WatchGuard's Firebox II. Laurent LEVIER IT Systems & Networks, Unix System Engineer Security Specialist Argosnet Security Server : http://www.Argosnet.com "Le Veilleur Technologique", "The Technology Watcher" Date: Wed, 21 Feb 2001 12:03:16 +0000 From: Stephane Lentz To: le hoangan charlie Cc: sec@ossir.org Subject: Re: Anti-Virus sur FreeBsd Message-ID: <20010221120316.A7822@nickfury.netfr.alcatel.fr> Reply-To: Stephane.Lentz@ansf.alcatel.fr Mail-Followup-To: Stephane Lentz , le hoangan charlie , sec@ossir.org Mime-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3A938CE0.5957BC5B@acetiming.com>; from le hoangan charlie on Wed, Feb 21, 2001 at 10:39:44AM +0100 Organization: Alcanet International Resent-From: sec@ossir.org X-Mailing-List: archive/latest/4471 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org Content-Length: 921 X-Status: $$$$ En voici : http://members.es.tripod.de/virusattack/antivirus/freebsd.htm http://www.decros.cz/~reho/check_virus/ http://www.freebsd-fr.org/archive-mail/msg00856.html http://www.sophos.com/products/antivirus/savunix.html http://www.amavis.org/ SL/ On Wed, Feb 21, 2001 at 10:39:44AM +0100, le hoangan charlie wrote: > Bonjour, > Je cherche à installer un Anti Virus sur FreeBsd, Pouvez vous me > donner des pointeurs ? > Merci. > > PS: Je m'étais desinscrit de la liste sur un coup de tête et je me suis > remis à lire les différentes questions et réponses, après avoir reçu > des messages me convaincant qu'il faut continuer (en français en plus). > > -- > Le Hoangan Charlie -- -- Stephane Lentz - Internet Services / Alcanet - Stephane.Lentz@alcatel.fr for B2B DHCP DNS HDLC and other acronyms check http://webopedia.internet.com/ ou allez sur http://www.olf.gouv.qc.ca/ressources/internet/index/index.htm From: Laurent DAVERIO Reply-To: Laurent DAVERIO Subject: ShareSniffer To: respinfo@cc.ensmp.fr Cc: vmazenod@libertysurf.fr Mime-Version: 1.0 Content-Md5: wFHWC9CTNNovUDdiBGicIA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from QUOTED-PRINTABLE to 8bit by paris.ensmp.fr id f1RDRdK08506 X-Loop: respinfo@paris.ensmp.fr X-Sequence: 481 Content-Length: 641 X-Status: $$$$ Si, si, c'est authentique. Garez vos PC ! Napster alternative: hack people's hard drives http://www.theregister.co.uk/content/8/17188.html -- Laurent DAVERIO Centre de Recherche en Informatique de l'École Nationale Supérieure des Mines de Paris (CRI-ENSMP) 35, Rue Saint-Honoré 77305 FONTAINEBLEAU CEDEX FRANCE Tel: (+33|0) 1.64.69.48.37 Fax: (+33|0) 1.64.69.48.47 E-mail: laurent@daverio.net http://daverio.net/ La Page Trad : http://trad.org/ X-Coding-System: nil Mail-from: From smtp-fr-owner@cru.fr Fri Mar 2 10:05 MET 2001 Date: Fri, 2 Mar 2001 10:05:16 +0100 From: Jacques Beigbeder To: sympa-fr@cru.fr, smtp-fr@cru.fr Subject: amavis, sympa et les virus Message-ID: <20010302100516.A13216@trefle.ens.fr> Mime-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i X-Loop: smtp-fr@cru.fr X-Sequence: 447 List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Content-Length: 454 X-Status: $$$$ Si d'aucuns sont intéressés par l'outil amavis, des statistiques, quelques réflexions basées sur mon expérience: http://www.spi.ens.fr/beig/amavis/ -- Jacques Beigbeder | Jacques.Beigbeder@ens.fr Service de Prestations Informatiques | http://www.spi.ens.fr Ecole normale supérieure | 45 rue d'Ulm |Tel : (+33 1)1 44 32 37 96 F75230 Paris cedex 05 |Fax : (+33 1)1 44 32 20 80 X-Coding-System: nil Mail-from: From irigoin@cri.ensmp.fr Fri Jan 26 09:12 MET 2001 Message-Id: <200101260810.JAA18022@champeaux.ensmp.fr> Date: Fri, 26 Jan 2001 09:10:40 +0100 (MET) From: Francois IRIGOIN Reply-To: Francois IRIGOIN Subject: 19264 IN SEARCH OF A BUG-FREE COMPUTER 01.26.01 To: all@cri.ensmp.fr Cc: huberman@cc.ensmp.fr, ml@cri.ensmp.fr MIME-Version: 1.0 Content-MD5: uUblyAJGpAiT1MSXuMUs0g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by antares.enst-bretagne.fr id JAA14835 Content-Length: 5938 X-Status: $$$$ ------------- Début message réacheminé ------------- IN SEARCH OF A BUG-FREE COMPUTER 01.26.01 FEATURES AND COMMENTARY HPCwire ============================================================================== San Jose, CA ­- It is common to all computers, regardless of make, operating system or age. It lurks everywhere from the humble home PC to spacecraft that navigate the Martian atmosphere. It's the bug, glitch or bomb ­ the system crash that brings down the whole works, frustrating users, raising costs, reinforcing doubts about the overall reliability of technology in the 21st century. After years of working alone on the problem, high-powered minds from academia, government and the private sector are putting aside competitive concerns and banding together to work on creating bulletproof computer systems. "We're willing to put a lot of information on the table and share it on the theory that high tide raises all ships," said Richard DeMillo, Hewlett-Packard Co.'s chief technology officer. "If we can bring up the level of dependability in the industry, then we all win." The High Dependability Computing Consortium, announced in December, held its first workshop this month to chart a course for stomping out bugs that affect everything from air traffic control to office networks. Initially funded with a $500,000 NASA grant and led by Carnegie Mellon University, the group includes industry heavyweights such as HP, IBM Corp. and Microsoft Corp. After 2½ days of discussions, participants agreed reliable computing must be a priority. "High dependability is something that cuts across a lot of what companies do," said David Garlan, a computer science professor at Carnegie Mellon. "It's not their main line of business, but they need it. In some sense, sharing that is less threatening than sharing some proprietary feature." In the past, most discussion of fail-safe systems focused on national defense and nuclear power plants. But with the explosion of e-commerce and networked business databases, the entire high-tech industry is taking notice, said Garlan.The economic costs of computer crashes and downtime are staggering,though companies aren't eager to reveal the scope of the problem. "Most view reliability issues as dirty laundry," said Dale Way, who led Y2K research for the Institute of Electrical and Electronics Engineers. "A lot of organizations have methods of reacting when things fail and keeping it in-house ... It's serious and expensive, but it's buried inside the cost structureof organizations." In June 1999, a 22-hour outage on the Internet auction site eBay cost the company $3.9 million in lost fees. Sometimes, more than dollars are at stake. In December, officials at San Francisco International Airport halted installation of a new ground radar system after tests showed it was tracking airplanes that weren't there. And national pride took a hit in 1999 when human and software glitches doomed both of NASA's Mars spacecraft ­ just as they were about to begin their missions at the Red Planet. One cost $125 million; the other $165 million. "Both people in government and industry know we could do much better," said Microsoft researcher Jim Gray, who leads the company's San Francisco lab. "We're doing the best we can with the technology we have, but there must be a better way." Computers and software as aware as HAL in the movie "2001: A Space Odyssey" or as reliable as the post office won't be available anytime soon, but some obvious steps can be taken in the near future to improve technology. The biggest problem is that high quality is not always designed into software from the start. Garlan believes software developers should think and work more like engineers ­ who incorporate the lessons of failed bridges and buildings into future designs. "All the things that you would find in a mechanical system would apply to software systems," DeMillo said. "The appeal here is to build that set of engineering principles and build that culture of learning from failure and making sure it doesn't happen again." Beyond learning from spilled milk, computer system developers should try to understand the ecosystems in which their programs operate ­ and how humans can thwart the software, DeMillo said. In 1996, America Online went offline for more than 19 hours when new hardware was being added to the system while new software was being downloaded. When the upgrade was finished, nothing worked. "This was probably the first time in the Internet world anyway that we had seen this particular combination of events," DeMillo said. "You now know that you don't change four or five things at the same time." Consortium partners also will develop ways to simulate how software works before it is deployed, much like how airplanes are tested by computers before they take flight. New techniques also are being explored that will give computers the ability to heal themselves. "Self-evolving systems could adapt on the fly and have the mechanism so that you can be sure the changes you make aren't going to bring the whole thing down," Garlan noted. Sometimes, it's more cost effective to bite the bullet and rewrite code that has been recycled over the years, Garlan said. Both Apple's and Microsoft's next generation operating systems, scheduled to be released this year, are abandoning old code in favor of programming that originated in the business world and has been proven to work well. That's a good start, said Gary Chapman, director of the 21st Century Project at the University of Texas at Austin. "It's surprising that there hasn't been more of a sense of outrage and calls for reform on the part of consumers," he said. "There's a kind of rumbling out there that people are pretty annoyed with computers these days." ------------- Fin message réacheminé ------------- Date: Fri, 22 Dec 2000 13:15:21 -0500 Reply-To: "Richard M. Smith" From: "Richard M. Smith" Subject: CERT's ActiveX security report To: BUGTRAQ@SECURITYFOCUS.COM Content-Length: 607 X-Status: $$$$ Hello, This past summer, CERT sponsored a two-day workshop on security issues with ActiveX controls. The final report was just released today and is available as a PDF file at the CERT Web site: http://www.cert.org/reports/activeX_report.pdf There is a lot of good information in the report about how individuals and organizations can reduce security risks in Internet Explorer when using ActiveX controls. In addition, there is a section aimed at software developers on how to create safer controls. A good bit of the technical information in the report has not been made public before. Richard Le site du projet : http://project.honeynet.org/ X-Coding-System: nil Mail-from: From owner-bugtraq@SECURITYFOCUS.COM Thu Dec 21 20:56 MET 2000 Approved-By: beng@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Delivered-To: BUGTRAQ@SECURITYFOCUS.COM MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <200012211520.QAA19665@hw1464.wdf.sap-ag.de> Date: Thu, 21 Dec 2000 16:20:03 +0100 Reply-To: mrex@sap-ag.de From: Martin Rex Subject: Re: "The End of SSL and SSH?" X-To: perry@PIERMONT.COM To: BUGTRAQ@SECURITYFOCUS.COM In-Reply-To: <877l4w5lzq.fsf@snark.piermont.com> from "Perry E. Metzger" at Dec 19, 0 01:01:13 pm Content-Length: 5779 X-Status: $$$$ Perry, Perry E. Metzger wrote: > > Kurt Seifried in an article on SecurityPortal shrilly entitled "The > End of SSL and SSH?" claims that SSH needs a PKI to be secure. I don't like the general bashing of SSH and SSL either, however there are grains of truth in those articles. The problem is not with the protocols SSH or SSL itself, but with the environments these protocols are used in *today* or bad combinations of these protocols with others. (1) the significance of a secure key storage. SSL: All Web-Browsers that I know keep Root-CA certificates in software and it is quite possible for software to modify Root-CA certs or to add new Root-CA certs, which subverts the whole PKI trust model. Modifying this storage is not that difficult, given the doors and bugs in Javascript, Java, ActiveX and Browser plugins. And the more application vendors move over to using Web-Browsers as frontends, the more (signed) general-purpose lauch pads will be installed and used. SSH: With SSH the known_hosts file is kept in the home directory of the user and it only protected by means of the underlying OS. On multi-user machines or with homes in network file systems (like NFS), this OS-protection might be extremly weak, especially on computers under central administration in large companies. (2) the significance of secure key distribution SSL: Web-Browsers area shipped with >100 preconfigured CA certs these days. Most Browsers can be downloaded via the Internet, but many of the distributions are still not signed -- how do you know they haven't been backdoored with additional Root-Certs? SSH: building up a known_hosts file by connecting new hosts and having the added after acknowledging SSH's warning is very common. Quite a lot of people go to IETF meetings without their own Laptop (me 2, I don't have a Laptop). How many of them use SSH on a public PC in the terminal room to dial into one of their own machines? How many of them do bring their own known_hosts with them? (3) the significance of correct protocol usage SSL: Many online shops on the Web only perform payment via HTTPS (SSL), catalogue browsing and filling the shopping cart is often done via plain HTTP. The HTTPS link for the payment is not typed in by the user, but it is a simple HREF, GET or POST of an HTTPS URL, served in an unprotected document -- which can be subverted. It's much easier to MITM the HTTP channel that serves the document with the HTTPS url that to MITM the actual HTTPS channel. SSH: If SSH is used to replace telnet among hosts, but the home directories are still shared via NFSv3, then it might be quite simple to succeed an SSH authentication... Still, the use of SSH will reduce the amount of plaintext passwords travelling the networks through telnet sessions. The general problem is normally, that security is only as good as the weakest link in the chain. In many places one will find SSL and/or SSH in long chains of legacy systems. Even though SSL and SSH are among the strongest links in that chain, they will not make up for the weak links. One of the features of SSH and SSL is that they can be used for Single Sign-On. In fact, they are used in such a fashion and are becoming more and more popular for this feature (as are other SSO-systems such as Kerberos or Microsoft's NTLM). In the presence of weak legacy systems/protocols, the Single Sign-On turns into a "Single Break-In", i.e. one hole in a large network of SSO-enabled machines may give me access to all of them, in spite of the quality of the SSO authentication protocol against brute-force guessing. This affects SSL in Web-Browsers, Kerberos if you happen to find a valid credential cache, SSH if you happen to find the socket to a working ssh-agent or X11-forwarding. What I don't like about X.509-based PKIs is that they are growing in the direction of insecurity, i.e. when you expand your trust you add new risks = you lower your security. If a single trusted CA gets subverted, you loose. With PGP/GPG-style "certificates" it would be possible to increase the security. You could require a certificate to carry several signatures from different authorities in order to be valid. Subverting a single signing authority (CA) wouldn't immediately subvert all your systems. One final problem with HTTPS (a particular use of SSL) is, that the servers are never acutally authenticated, they're only identified. There is a simple plausibility check of a FQDN against the CN= part of the subject distinguished name. (1) The signing CA is irrelevant as long as it is among the set of >100 CAs preconfigured in the Browser. Will you feel comfortable when your bank's server identifies with a certificate from a foreign CA you've never heard of before? (A CA that sneaked in with a previous browser update, or even with a previous OS service pack!). Your Browser will give you the same warm fuzzy illusion of security! (2) domain abiguity: There is no obvious difference between www.openssl.org and www.openssl.de for all casual humans. However the domains are owned by different organizations! How do people come up with URLs for Online shops? Quite often by guessing the second level domain and then cycling through the known TLDs. This is not exactly secure. And then there are those numerous domain name disputes. There have been quite many domains transferred. I don't know whether any of the CAs closely tracks domain name ownership once they've issued a server cert, but as far as I know, my web browser doesn't check CRLs to see whether server certs have been revoked by the issuing CA. -Martin X-Coding-System: nil Mail-from: From owner-bugtraq@SECURITYFOCUS.COM Fri Dec 22 02:32 MET 2000 Approved-By: beng@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Delivered-To: BUGTRAQ@SECURITYFOCUS.COM X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <200012212159.IAA24192@caligula.anu.edu.au> Date: Fri, 22 Dec 2000 08:59:05 +1100 Reply-To: Darren Reed From: Darren Reed Subject: Re: "The End of SSL and SSH?" X-To: mrex@sap-ag.de To: BUGTRAQ@SECURITYFOCUS.COM In-Reply-To: <200012211520.QAA19665@hw1464.wdf.sap-ag.de> from Martin Rex at "Dec 21, 0 04:20:03 pm" Content-Length: 1277 X-Status: $$$$ In some mail from Martin Rex, sie said: [...] > (1) the significance of a secure key storage. > > SSL: All Web-Browsers that I know keep Root-CA certificates in software > and it is quite possible for software to modify Root-CA certs > or to add new Root-CA certs, which subverts the whole > PKI trust model. No, it just subverts the implementation whereby the browser doesn't bother you if it can find a path back to a root-CA for a X.509 cert associated with whatever cert it has been given. For Netscape there is a builtin MIME type that cannot be disabled which invokes the root CA installation code. 10:1 most people would click "ok" to install a root CA if so prompted from a random web site. Now that's without even doing anything nasty. [...] > SSL: Web-Browsers area shipped with >100 preconfigured CA certs > these days. Most Browsers can be downloaded via the Internet, > but many of the distributions are still not signed -- > how do you know they haven't been backdoored with additional > Root-Certs? How do you know there is any integrity at all in those preconfigured ? What's to say that 10 of them aren't controlled by some mafia ? I'll let the conspiracy theorists goto town on that note. Darren From: GUYANNE FRANCIS Reply-To: "fguyanne@rcs.fr" To: "'sec@ossir.org'" Subject: Honey Pots & IDS Date: Thu, 23 Nov 2000 13:18:43 +0100 Organization: RCS X-Mailer: Messagerie Internet de Microsoft/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www.ossir.org id NAA25827 Resent-From: sec@ossir.org X-Mailing-List: archive/latest/4082 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org Content-Length: 1195 X-Status: $$$$ Bonjour, Vous pouvez trouver des infos à l'URL ci-jointe: http://www.sans.org/infosecFAQ/honeypots.htm Honey Pots and Intrusion Detection David Klug September 13, 2000 CyberCop Sting by Network Associates This product is designed to run on Windows NT and is able to emulate several different systems including Linux, Solaris, Cisco IOS, and NT. It is made to appeal to hackers for looking as if it has several well-known vulnerabilities. BackOfficer Friendly by NFR This product is designed to emulate a Back Orifice server. Francis Guyanne Consultant RCS, groupe TR Services -----Original Message----- From: FoUDeCHiCk@aol.com [SMTP:FoUDeCHiCk@aol.com] Sent: Thursday, November 23, 2000 5:11 AM To: sec@ossir.org Subject: Scan ou IDS ? Bonjour, j'observe votre discution "passionnée" depuis un moment et je reste indécis devant les arguments des 2 camps. Alors je vous pose la question : dans quels cas un IDS se revèle plus efficace pour la sécurité d'un réseau qu'un scanner de vulénabilité et vice-versa ? Je souhaiterais également savoir où trouver de la documentation sur les honeypot. Merci X-Coding-System: nil Mail-from: From nt-securite-request@ossir.org Thu Nov 23 19:41 MET 2000 Resent-Date: Thu, 23 Nov 2000 19:36:03 +0100 (MET) X-Authentication-Warning: www.ossir.org: list set sender to nt-securite-request@ossir.org using -f Message-ID: <028401c0557c$75087c90$aa0e33c1@mumm> From: "Patrick Chambet" To: Subject: Support présentation Sécurité Windows 2000 Date: Thu, 23 Nov 2000 19:37:38 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Resent-From: nt-securite@ossir.org X-Mailing-List: archive/latest/707 X-Loop: nt-securite@ossir.org Resent-Sender: nt-securite-request@ossir.org Content-Length: 417 X-Status: $$$$ Bonjour à tous, Le support de la présentation sur la sécurisation d'un serveur sous Windows 2000 qui a eu lieu lors de la dernière réunion du groupe Sécurité Windows NT de l'OSSIR le 9 octobre 2000 est accessible en ligne: http://www.edelweb.fr/ossir.html Cordialement, ____________________________________________ Patrick CHAMBET Edelweb SA - Groupe ON-X Consulting http://www.edelweb.fr - http://www.on-x.com X-Coding-System: nil Mail-from: From sec-request@ossir.org Tue Nov 21 10:20 MET 2000 Resent-Date: Tue, 21 Nov 2000 10:19:05 +0100 (MET) X-Authentication-Warning: www.ossir.org: list set sender to sec-request@ossir.org using -f Message-ID: <3A1A3DD4.9BE727DE@univ-tlse1.fr> Date: Tue, 21 Nov 2000 10:18:12 +0100 From: Fabrice Prigent Organization: Université Sciences Sociales X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Denis Ducamp CC: sec@ossir.org Subject: Re: Detection d'intrusion Content-Transfer-Encoding: 8bit Resent-From: sec@ossir.org X-Mailing-List: archive/latest/4059 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org Content-Length: 2361 X-Status: $$$$ Denis Ducamp a écrit : > > Il s'agit du meilleur logiciel de détection d'intrusion à mon avis. Ses > points faibles sont : ... > Ses points forts sont : > ... Nous utilisons Snort avec satisfaction depuis 2 mois. Je lui ferais cependant quelques reproches : 1) il travaille avec une variable de réseau interne et externe. Pour peu que le réseau soit, comme le notre, composé de 10 classes C non "regroupables", on est obligé de faire quasiment 1 base de signatures par réseau protégé : la taille du processus et la CPU utilisée deviennent alors conséquentes : 35 Mo de RAM (au lieu de 3,5 Mo) 50% de la CPU d'un pentium 166 sur une liaison 4 Mb/s - Celà devrait se corriger avec la future version qui devrait autoriser de mettre plusieurs définitions de réseau pour 1 meme variable - de plus on peut considérer que les alertes ne doivent pas faire attention à la notion d'interne et d'externe, mais on se trouve alors face à un nombre de fausses alertes très conséquentes. 2) Nous connaissons au moins 2 bases de signatures d'attaques : a) celle de http://www.snort.org/snort-files.htm#Rules (900 règles) b) celle de http://whitehats.com/ids/ (450 règles) Mais si elles s'inspirent l'une de l'autre, elles n'ont pas les memes definitions. le SCAN SYN-FIN est référencée par whitehats avec un numéro IDS permettant d'avoir une page d'explication, mais dans celle de snort, le SCAN SYN-FIN n'en n'a pas. Moralité on obtient des doublons inutiles. 3) les signatures bougent assez lentement (1 fois tout les 15 jours au plus rapide) ce qui n'est peut-etre pas assez réactif. A nous peut-etre d'améliorer la chose en aidant les développeurs ? Malgré ces petits défauts, c'est un excellent outil d'IDS (il nous a permis de repérer 2 intrusions réussies et de faire corriger 5 serveurs) et permet aussi de voir les trafics que ne peuvent voir les outils de mesures standard (Gnutella, Napster et autres protocoles à ports variables....). Il est assez simple d'installation et d'utilisation (sous un linux du moins) et des outils tels que snortsnarf viennent le compléter. -- Fabrice Prigent Administrateur reseau Tel : +33 5 61 63 36 93 Fax : +33 5 61 63 37 98 Bureau : 46 bis http://cache.univ-tlse1.fr/les.personnes/fabrice.prigent Universite des Sciences Sociales Place Anatole France 31042 Toulouse FRANCE X-Coding-System: nil Mail-from: From sec-request@ossir.org Mon Nov 6 12:44 MET 2000 Resent-Date: Mon, 6 Nov 2000 12:39:33 +0100 (MET) X-Authentication-Warning: vangogh.prism.uvsq.fr: thb set sender to thb@vangogh.prism.uvsq.fr using -f To: sec@ossir.org Subject: [comp.sys.sun.announce] SN Vol 12 #2 2737 Crypto Accelerator I -- PCI-Bus-Based SSL Accelerator Board From: Thierry Besancon Organization: PRiSM Date: 06 Nov 2000 12:37:32 +0100 Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.4 MIME-Version: 1.0 Resent-From: sec@ossir.org X-Mailing-List: archive/latest/4031 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org Content-Length: 4034 X-Status: $$$$ [1 ] Distribution: world Newsgroups: comp.sys.sun.announce Followup-To: poster From: flash@FlashBack.com (John J. McLaughlin) Reply-To: flash@FlashBack.com Organization: FlashBack, Inc. Approved: flash@sun.com Subject: SN Vol 12 #2 2737 Crypto Accelerator I -- PCI-Bus-Based SSL Accelerator Board Message-ID: Date: Mon, 06 Nov 2000 04:32:07 GMT X-Trace: news2.mia 973485127 208.63.239.9 (Sun, 05 Nov 2000 23:32:07 EST) NNTP-Posting-Date: Sun, 05 Nov 2000 23:32:07 EST MIME-Version: 1.0 http://sun.systemnews.com/system-news/jobdir/submitted/2000.12.all.w2.html#2737 The Sun Crypto Accelerator I is a PCI-bus-based SSL accelerator board supporting Sun server platforms using Solaris 2.6, 7, & 8. As a co-processor solution which off-loads the SSL function, used in many web applications, it supports iPlanet Webserver 3.6, 4.0 & 4.1, iPlanet Portal Server 3.0 SP1, and Apache. This accelerator board provides as much as five times the performance improvement to a system not using any acceleration, with a speed of 200 Ops/Sec per board. It is able to scale up to 1400 operations per second. It is suitable for e-commerce applications using SSL encryption via PCKS11 interface. This accelerator board is especially of interest to the following types of companies: - Banking/Financial Services: Much of the banking industry has been using SSL as a method of encryption for a number of years. The benefit of the Sun Crypto Accelerator board is the improvement in the number of simultaneous transactions and scalability, as many customers have larger server web implementations. - ISP/MSP (managed server providers): This market has a tendency to install large distributed server farms with lots of machines. The benefit is the reduced need for additional capacity planning for the web session load. The Accelerator board completely off-loads and speeds up the process of authentication as well as doing 5x the number of simultaneous connections. - Internet/intranet web implementation by brick-and-mortar or e-business company: Most of these companies are in need of intranet or Internet web access for employees as well as customers. With the need for remote work and web based transactions, the need for SSL is in high demand. Therefore, the benefit of increasing speed at an incrementally small cost is great. The Sun Crypto Accelerator I allows for a more cost-effective implementation to handle the transaction load increases of e-commerce. It can handle more simultaneous transactions, faster transactions, and fewer time-outs -- resulting in less dropped connections and optimized performance for system SSL authentication load. These benefits result in more cost-effective planning for server capacity planning. ---------------------------------------------------------------------------- To subscribe to the weekly "System News for Sun Users", fill in the request form at http://sun.systemnews.com or send email to John J. McLaughlin, Editor Specify text, PDF or web links. (c) 2000 System News, Inc. [2 ] -- -- THierry Besançon La NSA justifie Echelon : http://www.internetactu.com/flash/flash130-18octobre.html#t2 Le FBI cherche à protéger son Carnivore : http://www.internetactu.com/archives/iactu54.html#ten1 AIDE (http://www.cs.tut.fi/~rammer/aide.html) est très simple et rapide à mettre en oeuvre. X-Coding-System: nil Date: Thu, 12 Oct 2000 14:32:15 -0600 Reply-To: Kurt Seifried From: Kurt Seifried Subject: Re: File "shredding" To: BUGTRAQ@SECURITYFOCUS.COM Content-Length: 928 X-Status: $$$$ The only way to be somewhat sure (high degree of confidence, oh yeah) is to keep the file encrypted on the disk at all times and only decrypt it in memory (which unfortunately also means swap partitions nowadays). OpenBSD has such a beastie, and it is possible in other OS's. If you want to be really paranoid you could have a program wipe swap as part of shutdown, one option is http://wipe.sourceforge.net/. For example in Linux use swapoff, then wipe the device(s) that had the swap partition. From: http://www.securityportal.com/research/cryptodocs/basic-book/