- NZNOG - lists.nznog.org

Procedure for making an ISP take responsibility ?
by Tikiri Wicks 06 Nov '03

06 Nov '03

Hi Is there a procedure for forcing an ISP to take responsibility for hackers on their network ? I've got this one windows PC hidden behind a unix box. Ports above 1024 are forwarded from the Linux box to the windows box because of netmeeting and a few other things. This PC keeps getting hacked from a subscriber on an Israeli ISP. I've cleaned it 3 times now. Essentially the machine gets compromised with a hacktool and then opens a channel to the IP in Israel after which there is a continous stream at 40 kbps. Dialup modem speed perhaps ? I've emailed the ISP ( barak.net.il ) a couple times and get absolutely no response. Forum messages also indicate that this ISP does not respond to such messages. Norton Antivirus picks up a hack tool only when the pc is scanned but even then cannot identify it beyond stating that it is a hacktool. The filename is disguised as scan.exe in one of the winnt\installer folders If anyone is interested please email me off the list and I'll email you the packet logs. The following is the state of the afected PC when the firewall is not blocking traffic to 82-166-172-38.barak.net.il Example 1 winmgnt.exe:1200 TCP zoo:1337 82-166-172-38.barak.net.il:4241 ESTABLISHED winmgnt.exe:1200 TCP zoo:1336 82-166-172-38.barak.net.il:4273 TIME_WAIT winmgnt.exe:1200 TCP zoo:1336 82-166-172-38.barak.net.il:4276 ESTABLISHED winmgnt.exe:1200 TCP zoo:1337 zoo:0 LISTENING winmgnt.exe:1200 TCP zoo:43958 zoo:0 LISTENING Example 2 winmgnt.exe:1200 TCP zoo:1336 82-166-172-38.barak.net.il:2388 TIME_WAIT winmgnt.exe:1200 TCP zoo:1337 82-166-172-38.barak.net.il:2542 ESTABLISHED winmgnt.exe:1200 TCP zoo:1336 82-166-172-38.barak.net.il:2579 TIME_WAIT winmgnt.exe:1200 TCP zoo:1336 82-166-172-38.barak.net.il:2586 ESTABLISHED winmgnt.exe:1200 TCP zoo:1337 zoo:0 LISTENING winmgnt.exe:1200 TCP zoo:43958 zoo:0 LISTENING Once traffic to 82.166.172.38/24 is blocked then the trojan kept attempting a connection once every few seconds as follows System:8 TCP zoo:1337 82-166-172-38.barak.net.il:4530 SYN_RCVD 3 seconds later System:8 TCP zoo:1337 82-166-172-38.barak.net.il:4569 SYN_RCVD 3 seconds later System:8 TCP zoo:1337 82-166-172-38.barak.net.il:4607 SYN_RCVD 3 seconds later System:8 TCP zoo:1337 82-166-172-38.barak.net.il:4640 SYN_RCVD and so on.

3 2

RE: [nznog] Procedure for making an ISP take responsibility ?
by jfp 06 Nov '03

06 Nov '03

My 2 cents worth. Obviously that ISP is not going to do anything, So: - Permanently block said ISP to your linux box. - I assume you are using ipchains on your linux box, I would recommend upgrading to iptables which would mean not having to open incoming ports above 1024 as the session tracking should take care of that. jfp. ------------------------------------------------------------------------ Jean-Francois Pirus <jfp(a)clearfield.com> Clearfield Software Ltd Phone (+64-9) 358 2081 4th Floor 8-10 Whitaker Place Fax (+64-9) 358 2083 P O Box 2348 Auckland, New Zealand ------------------------------------------------------------------------

1 0

VPN with paq 5500 & pocket pc 2003
by Barry Murphy 05 Nov '03

05 Nov '03

Hi, This may be a bit off-topic but I thought someone on the list may have some idea on this. I've recently purchased an HP ipaq 5500 which comes with Pocket PC 2003 which has a VPN client built in. I'm trying to connect it to the VPN server but can't find the method of authentication it uses. All other windows clients can connect to the poptop VPN with no problem. HP Doesn't know & MS doesn't know where to direct my call to, I'm waiting for someone to call me back still. Server: enable MSCHAPv2 pap set mppe 128 stateless IPaq Client: Slip (Off by default) Software compression (tried with on & off) IP Header compression (tried with on & off) I guess my question is, what authentication method does the pocket pc 2003 use, does it support GRE? It connects but doesn't send any data. <snip from logs> Nov 6 11:08:35 ns pptpd[46749]: CTRL: PTY read or GRE write failed (pty,gre)=(6,5) Nov 6 11:08:35 ns pptpd[46749]: CTRL: Client 210.86.20.17 control connection finished Nov 6 11:08:35 ns ppp[46750]: Phase: deflink: Connect time: 16 secs: 0 octets in, 305 octets out Nov 6 11:08:35 ns ppp[46750]: Phase: deflink: 0 packets in, 5 packets out Nov 6 11:08:35 ns ppp[46750]: Phase: total 19 bytes/sec, peak 24 bytes/sec on Thu Nov 6 11:08:23 2003 </snip> <snip from logs for windows 2003> Nov 6 11:10:13 ns ppp[47125]: Phase: bundle: Authenticate Nov 6 11:10:13 ns ppp[47125]: Phase: deflink: his = none, mine = CHAP 0x81 Nov 6 11:10:13 ns ppp[47125]: Phase: Chap Output: CHALLENGE Nov 6 11:10:13 ns pptpd[47124]: CTRL: Ignored a SET LINK INFO packet with real ACCMs! Nov 6 11:10:13 ns ppp[47125]: Phase: Chap Input: RESPONSE (49 bytes from barry) Nov 6 11:10:13 ns ppp[47125]: Phase: Chap Output: SUCCESS </snip> Thanks Kindest Regards Barry Murphy

2 2

Joker nukes SPEWS
by Juha Saarinen 04 Nov '03

04 Nov '03

Domain ID:D74783489-LROR Domain Name:SPEWS.ORG Created On:07-Jul-2001 19:50:12 UTC Last Updated On:03-Nov-2003 15:44:43 UTC Expiration Date:07-Jul-2008 19:50:12 UTC Sponsoring Registrar:R25-LROR Status:INACTIVE Registrant ID:CORG-1195 Registrant Name:chip level domains Registrant Organization:Visit Lake Biakal! Registrant Street1:po box 61, Baikalsk-2 Registrant City:Irkutsk region, -- 665914 Registrant Postal Code:665914 Registrant Country:RU Registrant Phone:+7.3952348335 Registrant FAX:+7.3952348335 Registrant Email:chip(a)sendmail.ru Admin ID:CORG-58588 Admin Name:Sergei ''Chip'' Didorenko Admin Organization:Visit Lake Baikal! ~ http://baikal.irkutsk.org Admin Street1:po box 61, Baikalsk-2 Admin City:Irkutsk region Admin Postal Code:665914 Admin Country:RU Admin Phone:+7.3952348335 Admin Email:chip(a)sendmail.ru Billing ID:CORG-58588 Billing Name:Sergei ''Chip'' Didorenko Billing Organization:Visit Lake Baikal! ~ http://baikal.irkutsk.org Billing Street1:po box 61, Baikalsk-2 Billing City:Irkutsk region Billing Postal Code:665914 Billing Country:RU Billing Phone:+7.3952348335 Billing Email:chip(a)sendmail.ru Tech ID:CORG-58588 Tech Name:Sergei ''Chip'' Didorenko Tech Organization:Visit Lake Baikal! ~ http://baikal.irkutsk.org Tech Street1:po box 61, Baikalsk-2 Tech City:Irkutsk region Tech Postal Code:665914 Tech Country:RU Tech Phone:+7.3952348335 Tech Email:chip(a)sendmail.ru Name Server:INVALID-ADDRESS.JOKER.COM -- Juha

2 1

another phish
by David Miller 03 Nov '03

03 Nov '03

Hi Craig, If it's of interest to you, here's another example (forwarded separately.) This one's a Citibank phish - and where the westpac one was clearly sent direct, this one has a received line which would suggest that it was routed through a relay. I don't believe it. The relay, if that's what it was, appeared to be a student dorm at a french speaking university also in canada. The first received: line alleges to be from "pormexico.com", but the IP address belongs to Hewlett Packard according to whois. I think those URLs are kind of interesting. The citibank one references an IP address belonging in Korea (according to whois). The westpac one refers to at least a URL redirection service in russia (www.da.ru) and to something calling itself jablow.kir.jp, which on the face of it appears to be a legitimate site of some kind. I wonder if this is some kind of worm-like infestation, which would account for the broad number of connection attempts, IP addresses and the apparent lack of relays. A student dorm, a dial up/DSL address and an HP address seem like an unlikely real source for these things. Dave.

3 3

nsp-security
by Joe Abley 02 Nov '03

02 Nov '03

There is an invitation-only list run by Jared Mauch called nsp-security which has an extremely useful membership of enable-wielding ops people who never sleep. It's very useful for things like "I am under attack from address X.X.X.X which is in AS Y", infinitely more so than trying to get action from remote NOCs through the front door. https://puck.nether.net/mailman/listinfo/nsp-security It's a closed list, and you need to be recommended by people who are already on the list before your subscription will be approved. I'd be very happy to recommend anybody here who is interested (that I know). Note that nsp-sec isn't a conversational list; it's a terse, to-the-point, get-work-done list (unlike this one). Joe

1 0

Phishing expedition - Westpac heads-up!
by Andy Gardner 02 Nov '03

02 Nov '03

Had a friend who connect via ihug forward me an email - someone phishing for Westpac user ID's. They're blanket spamming it because he isn't even a Westpac customer. Might be an idea for all your ISP's to send out a warning message to your clients - good PR exercise. >> Reply-To: Westpac <verifyXX(a)westpac.com.nz> >> Sender: Westpac <verifyXX(a)westpac.com.nz> >> MIME-Version: 1.0 >> Content-Type: text/plain >> Content-Transfer-Encoding: 8bit >> >> Dear Westpac Bank Member, >> >> This email was sent by the Westpac server to verify your e-mail >> address. You must complete this process by clicking on the link >> below and entering in the small window your Westpac Banking >> Customer ID and Password. >> This is done for your protection --- because some of >> our members no longer have access to their email addresses and >> we must verify it. >> >> To verify your e-mail address and access your bank account, >> click on the link below. If nothing happens when you click on >> the link, copy and paste the link into the address bar of your >> web browser. >> >> >> http://www.westpac.com.nz:ac-XXXXXXXXXXXXXXXXXX(a)XXXXXXXXX.Da.rU/ >> ?XXXXXXXXXXX >> >> >> -------------------------------------------------- >> Thank you for using Westpac Bank! >> --------------------------------------------------

6 6

Re: [nznog] Phishing expedition - Westpac heads-up!
by Craig Whitmore 02 Nov '03

02 Nov '03

Yes I am seeing those emails as well: Nov 2 17:40:10 dbmail-mx3 sm-mta[26879]: hA24di60026879: ruleset=check_mail, arg1=<martin.williams(a)citibank.net>, relay=c-65-97-16-13.va.client2.attbi.com [65.97.16.13], reject=451 4.1.8 Domain of sender address martin.williams(a)citibank.net does not resolve Nov 3 13:41:28 dbmail-mx3 sm-mta[27391]: hA30ebfg027391: ruleset=check_mail, arg1=<martin.williams(a)citibank.net>, relay=adsl-66-120-247-125.dsl.lsan03.pacbell.net [66.120.247.125], reject=451 4.1.8 Domain of sender address martin.williams(a)citibank.net does not resolve (but not as many of them at all) Thanks Craig ----- Original Message ----- From: "Mark Piper" <Mark.Piper(a)nec.co.nz> To: "Craig Whitmore" <lennon(a)orcon.net.nz> Cc: <nznog(a)list.waikato.ac.nz> Sent: Monday, November 03, 2003 1:35 PM Subject: Re: [nznog] Phishing expedition - Westpac heads-up! > http://lists.insecure.org/lists/fulldisclosure/2003/Oct/1429.html > > Two more banks according to the above URL are having almost identical mailouts (citybank and natwest). >

1 0

The New Zealand Network Operators' Group
by Donald Neal 02 Nov '03

02 Nov '03

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. At present it consists of the subscribers to this mailing list, which anyone is free to join. A face-to-face gathering is to take place in Hamilton on January 29 and 30 2004, hosted by the WAND group. See http://www.nznog.org/ for more details, including the Call for Presenters. Also see http://thursdaynightcurry.com/about.html if you live in or near Wellington or Auckland. Operators' Contact List See http://www.usenet.net.nz/noc/ for operational contact details for most New Zealand ISP's. These are intended for use by other network operators rather than by most customers. Internet Exchanges See http://www.ape.net.nz/ for details of the Auckland Peering Exchange and those connected there, http://www.wix.net.nz/ for the Wellington Internet Exchange. About This Mailing List This list has around 550 addresses subscribed. You may only post to the list from a subscribed address. A number of people subscribe addresses which do not receive email purely to allow posting from them. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by an employee of Alcatel NZ Ltd. Neither of these organisations, nor the administrator, is responsible for its content. NZNOG Mailing List Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 4. Postings to multiple mailing lists are discouraged. 5. Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 6. Blatant product or service marketing is unacceptable. 7. Postings of a political, philosophical or legal nature are discouraged. 8. Postings to the list should be in ASCII or MIME encoded as text/plain. Attachments should not be sent to the list. To present a document, a suitable URL may be referred to. For documents of general interest, the use of proprietary file formats is discouraged. 9. Breaches of list etiquette should be dealt with privately with the offending list user, and should not result in complaints being sent to the list. 10. A person repeatedly breaching list etiquette shall receive warnings from the list administrator. A further breach after the second such warning within thirty days shall result in the offender being unsubscribed from the list. Other action may also be taken to block postings to the list by the offender. Any such unsubscription is to be immediately announced to the list. Mailing List Archives A full archive is available at http://list.waikato.ac.nz/archives/nznog/ Any message sent to the list will be archived and made available on the web automatically. Changes are not made to the archive on request, though the administrator remains happy to assist the Office of the Privacy Commissioner should any complaint be laid with that office. One way to search the archive is to use google and prefix your search with site:list.waikato.ac.nz . Subscribing to the List See http://list.waikato.ac.nz/mailman/listinfo/nznog to subscribe. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

1 0

Strange BGP 'problem'
by Nathan Ward 01 Nov '03

01 Nov '03

At the risk of posting something on topic.. I have 2 routers (lets call them A and B), talking to different upstream providers, advertising 202.6.75.0/24 via BGP. 202.6.75.0/24 is subnetted, each subnet is on a different VLAN. These routers talk to each other with iBGP, giving each other everything (including 202.6.75.0/24 le 32). I run HSRP between the 2 routers. Router B prepends my ASN several times before advertising 202.6.75.0. Relevant stuff (on both boxes): router bgp 23729 network 202.6.75.0 no synchronization ! ip route 202.6.75.0 255.255.255.0 Null0 With this config, reachability for 202.6.75.0/24 hosts alternates on and off roughly every minute. 47% total loss over 10 minutes (ie 5 'bursts' of loss). These packets are all hitting my AS at router A. I've turned HSRP off and on again to see if that was causing problems (it wasn't). Several solutions I've found: - Turning the iBGP session to router B off. (uhh..) - Turning syncronization on. My understanding of BGP synchronization, is that BGP will only re-advertise with eBGP prefixes learned via iBGP after learning them via another IGP if one is running. <snip> ec-br-1(config-router)#do sh run | inc router router bgp 23729 bgp router-id 202.6.75.1 </snip> I'm not running any IGPs, so synchronization shouldn't be part of the equation. In any case, I'm not a transit provider. And, there seems to be no relation to readvertising routes here, the packets AFAICT are getting to router A and being dropped. I've got no problem running running with synchronization on at the moment, but thats not the point. :-) Any ideas/thoughts? -- Nathan Ward

3 3