April 2004 - NLNOG - mailman3.nlnog.net

[gjmoed@xenosite.net: [Techniek-l] Ernstig Cisco SNMP exploit]
by sabri＠cluecentral.net 21 Apr '04

21 Apr '04

----- Forwarded message from "G.J. Moed" <gjmoed at xenosite.net> ----- Date: 21 Apr 2004 13:25:49 +0200 From: "G.J. Moed" <gjmoed(a)xenosite.net> To: techniek-l at nlip.nl Subject: [Techniek-l] Ernstig Cisco SNMP exploit X-Mailer: QuickMail Pro 3.0 (Windows32) http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml -- G.J. Moed GM1535-RIPE AS15426 XenoSite _______________________________________________ Techniek-l mailing list techniek-l at nlip.nl http://list2.xs4all.nl/mailman/listinfo/techniek-l-nlip-nl ----- End forwarded message ----- -- Sabri Berisha - SAB666-RIPE BIT BV - http://www.bit.nl/ AS12859 and AS31064 - lg: http://noc.bit.nl/traceroute

1 0

Fwd: US-CERT Technical Cyber Security Alert TA04-111A -- Vulnerabilities in TCP
by tycho＠e-dude.org 21 Apr '04

21 Apr '04

en wat is er nou precies aan de hand? easy-reader :-) ----- Forwarded message from CERT Advisory <cert-advisory at cert.org> ----- Return-Path: <bugtraq-return-14079-tycho=e-dude.org at securityfocus.com> From: CERT Advisory <cert-advisory(a)cert.org> To: cert-advisory at cert.org Date: Tue, 20 Apr 2004 15:33:19 -0400 Subject: US-CERT Technical Cyber Security Alert TA04-111A -- Vulnerabilities in TCP Delivered-To: tycho at e-dude.org Mailing-List: contact bugtraq-help at securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq at securityfocus.com> List-Help: <mailto:bugtraq-help at securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe at securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe at securityfocus.com> Delivered-To: mailing list bugtraq at securityfocus.com Delivered-To: moderator for bugtraq at securityfocus.com Organization: CERT(R) Coordination Center - +1 412-268-7090 List-Owner: <mailto:cert-advisory-owner at cert.org> Technical Cyber Security Alert TA04-111A archive Vulnerabilities in TCP Original release date: April 20, 2004 Last revised: -- Source: US-CERT Systems Affected * Systems that rely on persistent TCP connections, for example routers supporting BGP Overview Most implementations of the Border Gateway Protocol (BGP) rely on the Transmission Control Protocol (TCP) to maintain persistent unauthenticated network sessions. There is a vulnerability in TCP which allows remote attackers to terminate network sessions. Sustained exploitation of this vulnerability could lead to a denial of service condition; in the case of BGP systems, portions of the Internet community may be affected. Routing operations would recover quickly after such attacks ended. I. Description In 2001, the CERT Coordination Center released CA-2001-09, describing statistical weaknesses in various TCP/IP Initial Sequence generators. In that document (<http://www.cert.org/advisories/CA-2001-09.html>), it was noted by Tim Newsham: [I]f 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. Paul Watson has performed the statistical analysis of this attack when the ISN is not known and has pointed out that such an attack could be viable when specifically taking into account the TCP Window size. He has also created a proof-of-concept tool demonstrating the practicality of the attack. The National Infrastructure Security Co-Ordination Centre (NISCC) has published an advisory summarizing Paul Watson's analysis in "NISCC Vulnerability Advisory 236929," available at <http://www.uniras.gov.uk/vuls/2004/236929/index.htm>. Since TCP is an insecure protocol, it is possible to inject transport-layer packets into sessions between hosts given the right preconditions. The TCP/IP Initial Sequence Number vulnerability (http://www.kb.cert.org/vuls/id/498440) referenced in CA-2001-09 is one example of how an attacker could inject TCP packets into a session. If an attacker were to send a Reset (RST) packet for example, they would cause the TCP session between two endpoints to terminate without any further communication. The Border Gateway Protocol (BGP) is used to exchange routing information for the Internet and is primarily used by Internet Service Providers (ISPs). For detailed information about BGP and some tips for securing it, please see Cisco System's documentation (<http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm> or Team Cymru (<http://www.cymru.com/>). A vulnerable situation arises due to the fact that BGP relies on long-lived persistent TCP sessions with larger window sizes to function. When a BGP session is disrupted, the BGP application restarts and attempts to re-establish a connection to its peers. This may result in a brief loss of service until the fresh routing tables are created. In a TCP session, the endpoints can negotiate a TCP Window size. When this is taken into account, instead of attempting to send a spoofed packet with all potential sequence numbers, the attacker would only need to calculate an valid sequence number that falls within the next expected ISN plus or minus half the window size. Therefore, the larger the TCP Window size, the the larger the range of sequence numbers that will be accepted in the TCP stream. According to Paul Watson's report, with a typical xDSL data connection (80 Kbps, upstream) capable of sending of 250 packets per second (pps) to a session with a TCP Window size of 65,535 bytes, it would be possible to inject a TCP packet approximately every 5 minutes. It would take approximately 15 seconds with a T-1 (1.544 Mbps) connection. These numbers are significant when large numbers of compromised machines (often called "botnets" or "zombies") can be used to generate large amounts of packets that can be directed at a particular host. To protect against such injections, RFC 2385 provides a method of using MD5 signatures on the TCP Headers. If this form of verification is supported and enabled between two peers, then an attacker would have to obtain the key used to transmit the packet in order to successfully inject a packet into the TCP session. Another alternative would be to tunnel BGP over IPSec. Again, this would provide a form of authentication between the BGP peers and the data that they transmit. The lack of authentication when using TCP for BGP makes this type of attack more viable. US-CERT is tracking this issue as VU#415294. This reference number corresponds to CVE candidate CAN-2004-0230. NISCC is tracking this issue as Advisory 236929. II. Impact Sustained exploitation of the TCP injection vulnerability with regard to the BGP vulnerability could lead to a denial-of-service condition that could affect a large segment of the Internet community. Normal operations would most likely resume shortly after the attack stopped. Since the TCP/IP Initial Sequence Number vulnerability (VU#498440) has been proven more viable of an attack, any services or sites that rely on persistent TCP sessions could also be affected by this vulnerability. Impacts could range from data corruption or session hijacking to a denial-of-service condition. III. Solution Apply a patch from your vendor Please see you vendor's statement regarding the availability of patches, updates and mitigation strategies. Workaround 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 that 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. A stronger measure that would aid in protecting against such TCP attacks 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. 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. Ingress filtering Ingress filtering manages the flow of traffic as it enters a network under your administrative control. You can configure your BGP routers to only accept packets on a specific network connection. Servers are typically the only machines that need to accept inbound connections from the public Internet. In the network usage policy of many sites, there are few reasons for external hosts to initiate inbound connections to machines that provide no public services. Thus, ingress filtering should be performed at the border to prohibit externally initiated inbound connections to non-authorized services. In this fashion, the effectiveness of many intruder scanning techniques can be dramatically reduced. Network Isolation Complex networks can benefit by separating data channels and control channels, such as BGP, into different logical or physical networks. Technologies such as VLANs, VPNs, leased links, NAT may all be able to contribute to separating the tranmission of control information from the transmission of the data stream. Egress filtering Egress filtering manages the flow of traffic as it leaves a network under your administrative control. There is typically limited need for machines providing public services to initiate outbound connections to the Internet. In the case of BGP, only your BGP routers should be establishing connections to your peers. Other BGP traffic generated on your network could be a sign of an attempted attack. Appendix A. Vendor Information For vendor information, please see NISCC Vulnerability Advisory 236929 "Vulnerability Issues in TCP" (http://www.uniras.gov.uk/vuls/2004/236929/index.htm) or Vulnerability Note VU#415294 (http://www.kb.cert.org/vuls/id/415294#systems. As vendors report new information to US-CERT, we will update the vulnerability note. If a particular vendor is not listed in either the NISCC advisory, or the vulnerability, we recommend that you contact them for their comments. _________________________________________________________________ US-CERT thanks Paul Watson, Cisco Systems and NISCC for notifying us about this problem and for helping us to construct this advisory. _________________________________________________________________ Feedback can be directed to the US-CERT Technical Staff. _________________________________________________________________ Copyright 2004 Carnegie Mellon University. Terms of use Revision History April 20, 2004: Initial release Last updated April 20, 2004 ----- End forwarded message ----- -- Tycho Eggen (Unix|Network|Social) Engineer tycho at e-dude.org +31 6 41 824 855 "Never argue with an idiot. They bring you down to their level, then beat you with experience."

1 0

[Fwd: [IDS-Europe] On the TCP RST & BGP issue]
by henk＠wevers.org 20 Apr '04

20 Apr '04

More details Henk -------- Original Message -------- Subject: [IDS-Europe] On the TCP RST & BGP issue Date: Tue, 20 Apr 2004 19:53:22 +0200 From: Arrigo Triulzi <arrigo(a)northsea.sevenseas.org> To: ids-europe at alchemistowl.org Dear all, for those who haven't seen it yet: http://www.uniras.gov.uk/vuls/2004/236929/index.htm The CanSecWest presentation is tomorrow and hopefully I'll be able to report a few details via my contacts there. The big debate is whether or not it is reproducible "in the wild" as opposed to "under lab conditions". Hope this helps, Arrigo _______________________________________________ ids-europe mailing list ids-europe at alchemistowl.org https://ids-europe.alchemistowl.org/mailman/listinfo/ids-europe

1 0

[Fwd: [Fwd: [IDS-Europe] Unauthenticated BGP vulnerability - vendor independent]]
by marcel＠sc-network.nl 18 Apr '04

18 Apr '04

fyi -------- Original Message -------- Subject: [IDS-Europe] Unauthenticated BGP vulnerability - vendor independent Date: Wed, 14 Apr 2004 21:12:31 +0200 From: Arrigo Triulzi <arrigo(a)northsea.sevenseas.org> To: ids-europe at alchemistowl.org Dear all, I don't normally post vulnerability information but this one warrants an exception. There is a DoS, vendor independent, against unauthenticated BGP circulating on the net. Apparently both Cisco TAC and Juniper know about this if asked (I no longer have Cisco TAC access to verify this). The current "best fix" is to enable MD5. Hope this helps, Arrigo _______________________________________________ ids-europe mailing list ids-europe at alchemistowl.org https://ids-europe.alchemistowl.org/mailman/listinfo/ids-europe -- Met vriendelijke groet/With kind regards, Marcel ten Berg Network Engineer Scarlet Telecom B.V.

2 2

nummer trueserver
by marcel＠sc-network.nl 18 Apr '04

18 Apr '04

Hi, does anyone of you have a number of trueserver which is answered now. -- Met vriendelijke groet/With kind regards, Marcel ten Berg Network Engineer Scarlet Telecom B.V.

1 0

Re: MD5 authentication on peering sessions
by otter＠surfnet.nl 15 Apr '04

15 Apr '04

On Thursday, 15 April 2004, Neil J. McRae wrote: > Sorry wrong link, but that one is as valid an issue, can't find the right > link at the moment. > > The issue not a new one. its the same old stuff that other TCP sessions > have had for years and why we run ssh instead of telnet. > > I'd guess that someone has made some progress on those aspects of the > issue and I'd urge everyone to look at MD5. I think this is the one: http://www.nanog.org/mtg-0306/pdf/franz.pdf -- Niels

1 0

Gezocht : Wifi / UMTS PCMCIA kaartje
by erik＠is.nl 14 Apr '04

14 Apr '04

Heeft iemand al een WIFI / UMTS PCMCIA kaartje gezien ? Wifi liefst met 802.11G ondersteuning. Ik heb al wel kaartjes gezien Wifi/GPRS, maar aangezien UMTS er nu ook is.. zou dat leuker zijn.. Met vriendelijke groeten, Erik Bais -------- I S - I N T E R N E D - S E R V I C E S - B V -------- domeinregistratie - webhosting - colocating - dedicated servers www.is.nl - info at is.nl - T: 0299-476185 Gorslaan 18 - 1441 RG - Purmerend ---------------------------------------------------------------

3 2

MEDIA, COURT: Martijn Bevelander fined US$25,000
by raymond＠prolocation.net 08 Apr '04

08 Apr '04

Hi! Beefje toch de lul. ---------- Forwarded message ---------- Date: Wed, 7 Apr 2004 19:22:12 -0400 From: Alan Brown <alanb(a)DIGISTAR.COM> To: SPAM-L at peach.ease.lsoft.com Subject: MEDIA, COURT: Martijn Bevelander fined US$25,000 As reported in nanae (OP is alan [at] wylie.me.uk (Alan J. Wylie) As seen in the EDRI-gram bi-weekly newsletter, Number 2.7, 7 April 2004 EDRI-gram is a bi-weekly newsletter about digital rights in Europe. http://www.edri.org/ <cite> The Dutch spammer Martijn Bevelander has to pay 25,000 US Dollar to the US Federal Trade Commission, for unfair and deceptive acts of commerce. Bevelander and his company Maps Holding BV were accused by the FTC for misrepresenting the subject line, 'spoofing' (faking) the sender) and creating untrue opt-out possibilities in large amounts of unsolicited commercial mail. Both Bevelander and his US business partner Brian Westby have agreed to settle out of court. Westby pays 87,500 US dollar to the FTC. According to the complaint, Westby sent large amounts of adult e-mails with misleading subject lines, like 'Did you hear the news?' en 'New movie info'. For a period of three years, they both have to notify the Commission of any change in their private address and telephone number, any change in their employment status, and make all their current and future personnel sign a statement that they have read the FTC-order. The FTC can bring enforcement actions against any deceptive acts of commerce, including false or misleading headers and subject headings. The US claims jurisdiction over foreigners in these cases because the spam was addressed to US citizens. The US Can-Spam Act, entered into force on 1 January 2004, does not ban spam. It only creates the right to opt-out from future mailings. <snip> Stipulated final judgement and order for permanent injunction (04.03.2004) http://www.bof.nl/docs/westbyfinalorder.pdf FTC Complaint (16.09.2003) http://www.ftc.gov/os/2003/09/marriedcomp.pdf </cite>

1 0