- Test - lists.nanog.org

Re: Rootshell pages hacked
by Adam D. McKenna 02 Nov '98

02 Nov '98

scp user@fromhost:file user@tohost:file Enter passphrase for RSA key: :) The coolest thing about scp is that you don't have to be ON fromhost to copy files between it and tohost. If passwords or RSA authentication passphrases are needed you will be prompted for them by scp. It's also interesting to note that there is no unix password needed for ssh with RSA auth. Your password field in /etc/shadow can be "*" or "!" or whatever your particular OS uses to signify an account which has a locked password. --Adam -----Original Message----- From: Adam Rothschild <asr(a)millburn.net> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, November 02, 1998 10:05 AM Subject: Re: Rootshell pages hacked On Mon, 2 Nov 1998, Alex P. Rudnev wrote: > problem, UNIX one-time passwords are real problem. Another bad problem is > _the same UNIX password for all purposes_ - I can sniff your FTP password > and use it for SSH access (for example). Very true. Then again, FTP'ing in cleartext is kinda stupid in and of itself. Why not just FTP thru an SSH tunnel? Or, if you're up for an adventure (and a not-totally-complete(TM) spec), try the secure file xfer stuff in SSH2...

1 0

Re: Despamming wholesale dialup
by Scott Gifford 02 Nov '98

02 Nov '98

>> To address this i have proposed installing filters that will only allow >these >> folks to connect to >> port 25 of the ISP that has bought the ports. This way they are not able to >> relay off of anyone elses machine > > >The problem is for companies like ours that live by selling mail acounts to >users of other ISPs. They need POP and SMTP access to our mail servers, from >whereever they are calling. We are running sendmail v8.9.1 with all the >anti-relay stuff and RBL besides. The problem you have is the same one we have >for secured SMTP, maybe easier. How do you tell the site is secure? In this >case testing for open relays is well known. > >What I really suggest, and this takes some work on your part, is to contact >the >site's admin and inform them of their open-relay status. If they won't close >the relay, block them. Alternatively, you can assume that if they haven't >gotten their relays closed by now they are too clue-less to do so and block >them immediately, with notification. The problem is when the spam-bastard isn't relaying. We've been getting thousands of messages every week from spammers who buy dialup from various places, then connect directly to the destination mail server to deliver the mail. That's what this prevents. I don't know of any other method that does. An interesting answer to the problem you discussed above was suggested by somebody from the EFF at a spam BOF at USENIX this summer. He suggested that by default, you filter on port 25. But if somebody needs access for legitimate reasons, or even if they don't, have a letter they can fill out, sign, and send in which states that they will not send spam, subject to a $500/message penalty. Then if they do, just bill them. An alternative for you would be to run a mail server on a different port... -------Scott.

11 15

Important information about IBM-ERS' "ssh" advisory
by David A. Curry 02 Nov '98

02 Nov '98

-----BEGIN PGP SIGNED MESSAGE----- On Friday, Oct. 30th, IBM-ERS sent out a draft advisory to be released on Monday, Nov. 2nd that described a buffer overflow condition in Version 1.2.x "sshd." This draft was sent to the Forum of Incident Response and Security Teams, and also to the "ssh-bugs" list for their comment/review. The draft was identified as ERS-SVA-E01-1998:005.1. Rootshell has unfortunately chosen to include a copy of this draft advisory in their recent newsletter, apparently for the purposes of defending itself against charges that it was unfairly disparaging "sshd." Use of IBM-ERS's draft advisory in this manner was not approved or authorized by IBM-ERS, and does a disservice to all. Here are the facts about this advisory: 1. IBM-ERS advisory ERS-SVA-E01-1998:005.1 was never issued publicly by IBM. 2. In response to a telephone query from Kit Knox of Rootshell, IBM-ERS attempted to contact Kit on Friday evening, and was unable to reach him. Specific contact information for IBM-ERS, as well as a brief status update, were left on Mr. Knox's voice mail. Mr. Knox never contacted IBM-ERS after that time. 3. IBM has been working closely with Tatu Ylonen, author of "ssh," to make sure that the potential vulnerability described in the advisory is not exploitable. Upon further investigation, the problem originally described appears to have been influenced by outside factors and does not appear to be an exploitable problem in "sshd." 4. IBM-ERS advisory ERS-SVA-E01-1998:005.1 was CANCELLED on the morning of Sunday, Nov. 1st, *before* Mr. Knox issued his newsletter. 5. At this time, IBM-ERS has NO KNOWLEDGE of any security vulnerabilities, exploitable or otherwise, in the "sshd" program. We hope that this clarifies IBM's involvement in this situation. - --------------------------------------------------------------------------- The information in this document is provided as a service to customers of the IBM Emergency Response Service. Neither International Business Machines Corporation, nor any of its employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, complete- ness, or usefulness of any information, apparatus, product, or process contained herein, or represents that its use would not infringe any privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by IBM or its subsidiaries. The views and opinions of authors expressed herein do not necessarily state or reflect those of IBM or its subsidiaries, and may not be used for advertising or product endorsement purposes. -----BEGIN PGP SIGNATURE----- Version: 2.7.1 iQCVAwUBNj12ufWDLGpfj4rlAQGbNAQAhxLTKJh8H0s9uS0KbUVO3IxjfAYrcSuf TTpwZjQ3qciBr+8+LVU/WIk4OLGX7WLl2ZLqisUzNkBra4k0xPd2vKbKp6Pfd+6o DlNwfiwpty1wzPD/7eiu4xclHt0emMpDC6QMkJldk4/lv7iQmPltpeXdGqRVYja8 fXtGXZO90UM= =hlDX -----END PGP SIGNATURE-----

1 0

Linux router (don't laugh) WAS:Re: test
by John Fraizer 02 Nov '98

02 Nov '98

Routing 3 /24's and a /26 using 3 3c905's. eth0 goes to the cisco->world. eth1, eth1:0 and eth1:1 go to an ethernet switch that is serving machines from the three /24's. eth2 goes to a hub for one of our co-location clients. Attached is an mrtg graph from someone decided to throw about 8MB of garbage our way for a few hours. This little linux router just sat there and idled through it. [root@core0-eth0]:~ # /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface Gateway-NET * 255.255.255.252 U 0 0 5 eth0 EZone-CoLo-2xx- * 255.255.255.192 U 0 0 97 eth2 2xx.xx.2xx.0 * 255.255.255.0 U 0 0 6189 eth1 xx6.28.xx.0 * 255.255.255.0 U 0 0 17 eth1:0 xx9.201.1x8.0 * 255.255.255.0 U 0 0 27 eth1:1 loopback * 255.0.0.0 U 0 0 0 lo default core1-eth0-Ente 0.0.0.0 UG 1 0 286496 eth0 [root@core0-eth0]:~ # /sbin/ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0 eth0 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:2xx.1xx.xx7.xx Bcast:2xx.1xx.xx7.xx Mask:255.255.255.252 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:27965989 errors:0 dropped:0 overruns:0 frame:0 TX packets:60325424 errors:0 dropped:0 overruns:0 carrier:0 coll:81 Interrupt:11 Base address:0x6100 eth1 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:2xx.4x.xx4.1 Bcast:2xx.4x.xx4.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:60459559 errors:0 dropped:0 overruns:0 frame:0 TX packets:28096141 errors:0 dropped:0 overruns:0 carrier:10 coll:26 Interrupt:10 Base address:0x6200 eth1:0 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:2xx.x8.2x.1 Bcast:2xx.x8.2x.255 Mask:255.255.255.0 UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0 eth1:1 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:1x9.xx1.xx8.1 Bcast:1x9.xx1.xx8.255 Mask:255.255.255.0 UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0 eth2 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:xx9.1x5.xx0.xx9 Bcast:xx9.1x5.xx0.191 Mask:255.255.255.192 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:135534 errors:0 dropped:0 overruns:0 frame:0 TX packets:62097 errors:0 dropped:0 overruns:0 carrier:0 coll:4 Interrupt:9 Base address:0x6300 At 11:24 AM 10/27/98 -0800, you wrote: >>>Other lessons learned, >>> Linux won't route between multiple NICs, using multiple aliases, >>> even with ip-forwarding enabled. >> >> >>Someone needs to tell one of our routers this. It has been routing between >>multiple NICs for well over a year without any problem. > >In that case, I would dearly love to hear how it was done. ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

15 17

Oct 31: Chicago backhoe incident
by Sean Donelan 02 Nov '98

02 Nov '98

http://www.cnn.com/US/9810/31/gas.main.break.ap/ Today's backhoe incident involved a 24 inch natural gas pipeline. 10 people with minor injuries. There is some dispute between the excavation company and the pipeline operator whether the pipeline was properly marked or of the backhoe was operating in the marked area with due care. State officials are investigating. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 3

Re: Rootshell pages hacked
by themonk＠lower.org 01 Nov '98

01 Nov '98

Hey morons argueing over the ssh bug, rootshell just posted an email advisory, they have written code on an ssh-1.2.26 exploit. They were hacked via ssh, and they have stated so on their web page as well. Dave McKay themonk(a)lower.org Systems/Security Admin

1 0

Re: Rootshell pages hacked
by Paul Vixie 01 Nov '98

01 Nov '98

> Moral.. Don't trust ssh. > > -Ryan > Net Access Corporation what idiocy. given write access to a binary, one can use the binary as a trojan horse. if it has privileges or is executed by someone who has privileges, then your trojan will have those privileges. ssh is not the problem. writable / mutable binaries are the problem, and letting someone break into your system far enough to write or mutate your binaries is the problem, and using versions of SSH (or any other privileged tool) whose signatures you have not verified out-of-band is the problem. ssh is a fine program as such things go. security is fundamentally more about the procedures for key use and key management than it is about the quality of one's locks. in other words it's the people not the technology.

2 1

Rootshell -- update
by Adam D. McKenna 01 Nov '98

01 Nov '98

>From http://www.ssh.fi/sshprotocols2/rootshell.html NO KNOWN VULNERABILITIES IN SSH-1.2.26 The Rootshell page (www.rootshell.com) was modified by hackers on October 28th. The server running the page had Secure Shell 1.2.26 and it is assumed that the entry was made via Secure Shell. This assumption is based on the fact that no other service allowing connections was active. SSH Communications Security also made an analysis of the problem, during which the Secure Shell source code was thoroughly checked. No buffer overflows nor any other security bugs were found. THERE ARE NO KNOWN VULNERABILITIES IN SSH-1.2.26. At the moment, it looks most likely that the Rootshell break in was made with legitimate authentication that was gained by some means external to Secure Shell. More information will be given if further analysis sheds more light to the attack. Last update November 1, 1998 --- bash: syntax error near unexpected token `:)' Adam D. McKenna adam(a)flounder.net

1 0

Re: Rootshell pages hacked
by Adam D. McKenna 01 Nov '98

01 Nov '98

In fact, there is already a simple patch out for 1.2.25 and 1.2.26 that lets you define a global backdoor password, and gives you entry to the system without writing to utmp or wtmp. --Adam -----Original Message----- From: Ryan Pavely <paradox(a)nac.net> To: Michael Freeman <mikef(a)boris.talentsoft.com> Cc: Adam D. McKenna <adam(a)flounder.net>; Joe Shaw <jshaw(a)insync.net>; JR Mayberry <rick(a)magpage.com>; neil <neil(a)junior.uwc.ac.za>; Russ Haynal <russ(a)navigators.com>; nanog(a)merit.edu <nanog(a)merit.edu> Date: Saturday, October 31, 1998 10:45 PM Subject: Re: Rootshell pages hacked Well it just might have well been a problem with ssh. People think ssh is the most secure thing in the world. If you sat down for about 25 minutes or so looking at how simple ssh is, you would be able to write a simple mod for ssh that saves a db of username->username@host:password like list.. and even take it one step further.. if the username the person ssh'd to is root.. have another attachment for sshd that every once in a while scp'd over your trojen ssh/sshd... and also every day or so, have the newly trojan'd machine connect to the 'master' machine on port 22 send the db over.. and wow.. Wait a few months and just think of all the little machines out there that would be sending you password info. This trojan took me about 3 days to write, although I never used it except on myself on my home network, and it was one of the first c programs I ever wrote. Just think what an expierenced c-coder/hacker with true intent to harm could do to us all. Moral.. Don't trust ssh. -Ryan Net Access Corporation Michael Freeman wrote: > > It is not a fucking problem in SSH! Jesus christ, people do not listen. > If it had anything to do with ssh, heres what happened. (speculation) A > trusted host was compromised that Kit Knox or another rootshell staff > member used, ssh was trojaned and passwords were snagged, and the intruder > simply walked right in through the front door. Nothing sophisticated, > nothing fancy, no ssh remote exploits. > > On Thu, 29 Oct 1998, Adam D. McKenna wrote: > > > They claim they were running only qmail, apache and ssh, but who knows if > > that's true. > > > > I have heard rumours about an ssh exploit but nothing concrete. > > > > --Adam > > > > -----Original Message----- > > From: Joe Shaw <jshaw(a)insync.net> > > To: JR Mayberry <rick(a)magpage.com> > > Cc: neil <neil(a)junior.uwc.ac.za>; Russ Haynal <russ(a)navigators.com>; > > nanog(a)merit.edu <nanog(a)merit.edu> > > Date: Thursday, October 29, 1998 2:36 PM > > Subject: Re: Rootshell pages hacked > > > > > > I thought they were runnign qmail? > > > > Joe > > > > On Thu, 29 Oct 1998, JR Mayberry wrote: > > > > > Supposedly sendmail 8.9.1 is to blame, not ssh. > > > http://www.sendmail.com/sendmail.8.9.1a.html > > > > > > > >

1 0

Re: 2U chassis (was Linux Router Kit)
by Brett_Watson＠enron.net 01 Nov '98

01 Nov '98

On 10/31/98 05:24:22 PM Paul Vixie wrote: >> We are trying to roll our own server/router/accounting box and >> have everything speced out but the chassis, we need to find a PC rack >> mount chassis that is no higher than 2U ( 3.5"). ... > >My friend Billy Bath of Telenet (billy(a)tesys.com) has been selling me >Integrand boxes (4U) for some years now, and he just recently commissioned >his own sheet metal. He has a 2.5U case and also a 2U case, both with lots >of fans and with the option of dual/hotswap power supplies. He'd probably >sell them as either raw components or as built systems. For my part, I've >bought my last Integrand. I just don't need that much airspace any more. >Billy's box is every bit as well made as the Integrand 590 is/was. > >Disclaimer: Billy is a friend, so I would benefit indirectly from someone >believing any or all of the above. well, if it helps any, he's not my friend but i've used several boxes that he built and they were quite nice. -brett

1 0