Hiya.

Interestingly, running nmap with o/s detection against a ST Pro running
3.281 yields a similar result - rediculously easy to guess sequence
numbers... Not a good look really, and I doubt that a fix will be
available..... just the usual pesimism.

Cheers -

Russell Fulton wrote:

>Probably not a big deal for home users but still worth noting.
>
>Russell
>
>-----Forwarded Message-----
>From: auscert@auscert.org.au
>To: auscert-subscriber@auscert.org.au
>Subject: [Irt] (AUSCERT ESB-2004.0504) iDEFENSE Security Advisory 08.05.04 - Thompson SpeedTouch Home ADSL Modem Predictable TCP ISN Generation
>Date: Tue, 10 Aug 2004 18:04:54 +1000
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>===========================================================================
> AUSCERT External Security Bulletin Redistribution
>
> ESB-2004.0504 -- iDEFENSE Security Advisory 08.05.04
> Thompson SpeedTouch Home ADSL Modem Predictable TCP ISN Generation
> 10 August 2004
>
>===========================================================================
>
> AusCERT Security Bulletin Summary
> ---------------------------------
>
>Product: Thompson (formerly Alcatel) SpeedTouch ADSL router
>Publisher: iDEFENSE
>Impact: Reduced Security
>Access: Remote/Unauthenticated
>CVE Names: CAN-2004-0641
>
>- --------------------------BEGIN INCLUDED TEXT--------------------
>
>Thompson SpeedTouch Home ADSL Modem Predictable TCP ISN Generation
>
>iDEFENSE Security Advisory 08.05.04:
>
>I. BACKGROUND
>
>The Thompson (formerly Alcatel) SpeedTouch is an ADSL router for home
>and business providing a continuously available, "always on,"
>connection. More information about the product can be found at
>http://www.speedtouchdsl.com/.
>
>II. DESCRIPTION
>
>Remote exploitation of a design error vulnerability in Thompson's
>SpeedTouch Home ADSL modem allows attackers to spoof TCP traffic on
>behalf of the device.
>
>The problem specifically exists due to the predictable nature of the TCP
>Initial Sequence Number (ISN) generator on the device. The following
>sanitized tcpdump output demonstrates the existence of the vulnerability
>when 10 consecutive TCP connection requests are generated for the telnet
>server (port 23) on the Thompson device:
>
>48.3 host_a.1096 > host_b.telnet: S
>48.3 host_b.telnet > host_a.1096: S 4081040897:4081040897(0) ack
>48.3 host_a.1096 > host_b.telnet: R
>48.4 host_a.1096 > host_b.telnet: S
>48.4 host_b.telnet > host_a.1096: S 4081104897:4081104897(0) ack
>48.4 host_a.1096 > host_b.telnet: R
>48.6 host_a.1096 > host_b.telnet: S
>48.6 host_b.telnet > host_a.1096: S 4081232897:4081232897(0) ack
>48.6 host_a.1096 > host_b.telnet: R
>48.7 host_a.1096 > host_b.telnet: S
>48.7 host_b.telnet > host_a.1096: S 4081296897:4081296897(0) ack
>48.7 host_a.1096 > host_b.telnet: R
>48.9 host_a.1096 > host_b.telnet: S
>48.9 host_b.telnet > host_a.1096: S 4081360897:4081360897(0) ack
>48.9 host_a.1096 > host_b.telnet: R
>49.0 host_a.1096 > host_b.telnet: S
>49.0 host_b.telnet > host_a.1096: S 4081488897:4081488897(0) ack
>49.0 host_a.1096 > host_b.telnet: R
>49.2 host_a.1096 > host_b.telnet: S
>49.2 host_b.telnet > host_a.1096: S 4081552897:4081552897(0) ack
>49.2 host_a.1096 > host_b.telnet: R
>49.3 host_a.1096 > host_b.telnet: S
>49.3 host_b.telnet > host_a.1096: S 4081616897:4081616897(0) ack
>49.3 host_a.1096 > host_b.telnet: R
>49.5 host_a.1096 > host_b.telnet: S
>49.5 host_b.telnet > host_a.1096: S 4081744897:4081744897(0) ack
>49.5 host_a.1096 > host_b.telnet: R
>49.6 host_a.1096 > host_b.telnet: S
>49.6 host_b.telnet > host_a.1096: S 4081808897:4081808897(0) ack
>49.6 host_a.1096 > host_b.telnet: R
>
>In the above example, host_a is the querying host and host_b is the
>Thompson device. A clear pattern in ISN generation can be seen as the
>value increases by approximately 64,000 each millisecond.
>
>III. ANALYSIS
>
>Successful exploitation of weak ISNs for the purpose of connection
>spoofing is not a trivial task. Successful exploitation allows an
>attacker to generate traffic on behalf of the affected device. Such an
>ability is most dangerous when trust paths exist between the affected
>device and another remote system.
>
>IV. DETECTION
>
>iDEFENSE has verified the existence of this vulnerability in Thompson's
>SpeedTouch firmware version GV8BAA3.270 (1003825). It is suspected that
>earlier versions are susceptible to exploitation as well.
>
>V. WORKAROUNDS
>
>Untrusted traffic should be filtered at the network perimeter.
>
>VI. CVE INFORMATION
>
>The Common Vulnerabilities and Exposures (CVE) project has assigned the
>name CAN-2004-0641 to this issue. This is a candidate for inclusion in
>the CVE list (http://cve.mitre.org), which standardizes names for
>security problems.
>
>VII. DISCLOSURE TIMELINE
>
>06/08/04 Initial vendor contact - no response
>06/08/04 iDEFENSE clients notified
>06/18/04 Secondary vendor contact - no response
>08/05/04 Public disclosure
>
>VIII. CREDIT
>
>The discoverer wishes to remain anonymous.
>
>Get paid for vulnerability research
>http://www.idefense.com/poi/teams/vcp.jsp
>
>IX. LEGAL NOTICES
>
>Copyright © 2004 iDEFENSE, Inc.
>
>Permission is granted for the redistribution of this alert
>electronically. It may not be edited in any way without the express
>written consent of iDEFENSE. If you wish to reprint the whole or any
>part of this alert in any other medium other than electronically, please
>email customerservice@idefense.com for permission.
>
>Disclaimer: The information in the advisory is believed to be accurate
>at the time of publishing based on currently available information. Use
>of the information constitutes acceptance for use in an AS IS condition.
>There are no warranties with regard to this information. Neither the
>author nor the publisher accepts any liability for any direct, indirect,
>or consequential loss or damage arising from use of, or reliance on,
>this information.
>
>- --------------------------END INCLUDED TEXT--------------------
>
>You have received this e-mail bulletin as a result of your organisation's
>registration with AusCERT. The mailing list you are subscribed to is
>maintained within your organisation, so if you do not wish to continue
>receiving these bulletins you should contact your local IT manager. If
>you do not know who that is, please send an email to auscert@auscert.org.au
>and we will forward your request to the appropriate person.
>
>NOTE: Third Party Rights
>This security bulletin is provided as a service to AusCERT's members. As
>AusCERT did not write the document quoted above, AusCERT has had no control
>over its content. The decision to follow or act on information or advice
>contained in this security bulletin is the responsibility of each user or
>organisation, and should be considered in accordance with your organisation's
>site policies and procedures. AusCERT takes no responsibility for consequences
>which may arise from following or acting on information or advice contained in
>this security bulletin.
>
>NOTE: This is only the original release of the security bulletin. It may
>not be updated when updates to the original are made. If downloading at
>a later date, it is recommended that the bulletin is retrieved directly
>from the author's website to ensure that the information is still current.
>
>Contact information for the authors of the original document is included
>in the Security Bulletin above. If you have any questions or need further
>information, please contact them directly.
>
>Previous advisories and external security bulletins can be retrieved from:
>
> http://www.auscert.org.au/render.html?cid=1980
>
>If you believe that your computer system has been compromised or attacked in
>any way, we encourage you to let us know by completing the secure National IT
>Incident Reporting Form at:
>
> http://www.auscert.org.au/render.html?it=3192
>
>===========================================================================
>Australian Computer Emergency Response Team
>The University of Queensland
>Brisbane
>Qld 4072
>
>Internet Email: auscert@auscert.org.au
>Facsimile: (07) 3365 7031
>Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
> AusCERT personnel answer during Queensland business hours
> which are GMT+10:00 (AEST).
> On call after hours for member emergencies only.
>===========================================================================
>
>-----BEGIN PGP SIGNATURE-----
>Comment: http://www.auscert.org.au/render.html?it=1967
>
>iQCVAwUBQRiBbSh9+71yA2DNAQKvMwP9EKWXSQSZj5GaQusdCkWehHEOr/WqXtt0
>j9NHGJkkI760FnWc4+ja1S995Oly8TUyhsQq7CL+CcfzUW2snBpXzl2OMBMEkLGw
>GXdDzlim68XGysvkrmEtJ+jgS1lqSiBFKhWzmwmB5Wxby22HCt8+9/gv3MUSOEPR
>Hkz2yZMlGLI=
>=o2NO
>-----END PGP SIGNATURE-----
>_______________________________________________
>
>

-- 
This message is part of the NZ ADSL mailing list. 
see http://unixathome.org/adsl/ for archives, FAQ, 
and various documents. 
To unsubscribe: send mail to majordomo@lists.unixathome.org 
with "unsubscribe adsl" in the body of the message