Slashdot Mirror

I love Fred. If I didn't have so much faith in human stupidity, I've suspect that his articles were actually some sort of satire on FUD.

Since ABCNews, it in interested of giving people the direct facts, have neglected to provide a link to the actual BugTraq statistics. Here's one. Check it out, lots of fascinating disclaimers and real numbers. Fred cheerfully brushes off such fun disclaimers as "The statistics should not be taken to imply that some particular operating system or application is more or less secure than another one." He ignores " We consider a vulnerability to affect an application or operating system if the vulnerability affects a component that is part of the application or operating system when brought or downloaded." So, if sendmail has a vulnerability, it's likely to count against Linux, since most Linux distributions ship a sendmail. If a mail transport agent for NT has a vulnerability, well, it didn't ship with NT, so it's okay.

Windows NT totaled 99 new vulnerabilities on the BugTraq list. (So far in 2000, the count stands at 37.) This looks like an alarmingly high number in comparison with Solaris' 34 or NetBSD's 10, but it is significantly less than the 122 racked up by Red Hat and the other Linuxes (their 2000 count stands at 47).

Let's check Fred's numbers. A quick check for 1999 for Windows NT reveals 99 incidents, sure enough. A check for "Linux (aggr.)" reveals... 84? Something smells fishy.

Well, the disclaimers at the top note " Were we display aggregate number of vulnerabilities (Linux and BSD) the number is the size of the set that results from the union of all vulnerabilities for the components without duplication. Vulnerabilities are not counted twice." Perhaps this means that the "aggr" entry doesn't include the Red Hat, SuSE, Debian, or Slackware entries. Not how I would have interpreted it (I would have read it as "If a single bug was found in Red Hat, SuSE, and Debian, we only counted it in the aggregation once, not three times.) But adding them together gets me... 182. Erm, so where did Fred pull 122 from?

Fred, after blowing off BugTraq's very long disclaimer, summarises with:

All that aside, though, one conclusion is inescapable: If you look this list over, and measure each system's number of vulnerabilities against the number of its customers, Linux is arguably the worst operating-system product in history, and Microsoft's the best.

This is just stupid. If you remove his little "against the number of its customers", his analysis has no meaning. I can find a strong case for many of the system with a little justification like Fred's. Security vulnerabilities are more important for servers on the internet where random people can attack them. Given the number of Linux boxes to Windows boxes serving web pages on the internet, it's looks that Linux and Windows NT are closely matched. Taking into account severity of the vulnerability (Are there real exploits, or is it a suspected vulnerability? Can it be exploited externally, or only if you already have local user permissions? Does it effect all computers, or only ones in particular configuration?) I suspect you'd find different answers, but the information isn't there (and BugTraq admits as much).

The amazingly low quality of this article makes me suspect that Fred is either so strongly biased against Linux that he is conciously or subconciously viewing the world through blue (screen) colored glasses. Of course, ABC doesn't have any reason to stop him, since clearly he's drawing huge hits.

Oh well.

As Linux zealots are beginning to find out, it's a lot easier to masquerade as a better product than it is to go out and be one.

Ultimately, we should just ignore the silly little man and go on enjoying our better product.

For those who want to see the statistics Moody is using, look here. It's interesting to note that Slackware has zero bugs listed for 2000. Guess that makes them the best OS.

...than NT 4 :-) the BugTraq list is on:
http://www.securityfocu s.com/vdb/stats.html?&_ref=969560743
says it all, ok all the Linux distr. together are as high as NT4 but when you do it that way the same bug might be couted alot of times (Linux are not one distr. you know ;) Linux is still the most bugfree compared to M$

PhoX
--------
most cats is green?

Fred Moody's data comes from Security Focus, but he obviously spend much time at their site. Look at the BUGTRAQ Vulnerability Database Statistics, and you'll see that

"Where we display aggregate number of vulnerabilities (Linux and BSD) the number is the size of the set that results from the union of all vulnerabilities for the components without duplication. Vulnerabilities are not counted twice."

In the charts towards the bottom of the page, Windows NT 4.0 was listed as the most vulnerable distribution in 2000 and 1999. The most vulnerable Linux distributions were all from RedHat, but even then, there were 13 vulnerabilities in RedHat Linux 6.2 i386, compared to the 21 vulnerabilities in Microsoft Windows NT 2000, and the 34 vulnerabilities in Microsoft Windows NT 4.0.

Fred Moody's data comes from Security Focus, but he obviously spend much time at their site. Look at the BUGTRAQ Vulnerability Database Statistics, and you'll see that

"Where we display aggregate number of vulnerabilities (Linux and BSD) the number is the size of the set that results from the union of all vulnerabilities for the components without duplication. Vulnerabilities are not counted twice."

In the charts towards the bottom of the page, Windows NT 4.0 was listed as the most vulnerable distribution in 2000 and 1999. The most vulnerable Linux distributions were all from RedHat, but even then, there were 13 vulnerabilities in RedHat Linux 6.2 i386, compared to the 21 vulnerabilities in Microsoft Windows NT 2000, and the 34 vulnerabilities in Microsoft Windows NT 4.0.

Look, we dont need for you to trot out the tired, untrue cliches. All we need is for people to actually look at the chart and to draw their own conclusions.

It doesnt matter that Linux isnt COMMERCIAL. FreeBSD isnt commercial either and it's count is even lower than every COMMERCIAL unix on that chart.

MS has the highest bug count on that chart bar none.

End of fucking story. Argue FUD with facts, not mythology.

says it all. i don't know where he got his misguided statistics... according to this, windows NT has the most bugs out of any operating system in both 1999 and 2000. Did he add all distro's on there AND the Aggregate Linux statistics to get his numbers? guess he didn't understand what "Linux(aggr.)" meant...

It indicates plenty. Unfortunately, if you actually take a look at the chart, it doesnt look anything like the chart the well known alcoholic and cocaine binger Moody was looking at.

I'll see your FUD and raise you 2 FUDs. Read 'em and weep, Moody, you ignorant shill.

It indicates plenty. Unfortunately, if you actually take a look at the chart, it doesnt look anything like the chart the well known alcoholic and cocaine binger Moody was looking at.

I'll see your FUD and raise you 2 FUDs. Read 'em and weep, Moody, you ignorant shill.

Were we display aggregate number of vulnerabilities (Linux and BSD) the number is
the size of the set that results from the union of all vulnerabilities for the components
without duplication. Vulnerabilities are not counted twice.

(quoted from the introduction at the top of the stats page he used http://www.securityfocus.com/vdb/stats. html)

Okay, lets for a moment assume that we want to go distro for distro... and most people believe that RedHat is one of the more insecure of them...

Vendor, Bugs in 1997, 1998, 1999, 2000 (so far)
LINUX (all), 10, 23, 84, 30
RedHat, 5, 10, 38, 17
WinNT, 4, 6, 99, 37

Geee... despite a minor problem at the beginning the numbers look a little different... don't they? In fact evem the agregate Linux numbers come up better then NT (while not a benchmark I would like to use, its the one he seems to be using). To compare the Unix agregate number properly to Windows, we would have to include the Win9x statistics also... right? Somehow I doubt he'd want to do that.

No there are not more bugs. There are LESS bugs.

Look at the chart for your self. I have no idea where Moody is drawing his figures from but it certainly is not the chart which shows Windows to be head and shoulders above everyone else's bug count. I would have expected it to do a lot better given the inavailability of their source code.

Here are the actual stats

They pretty much speak for themselves as to how lame his argument is. Going by his argment, windows 95/98 are more secure than NT as they had few vulnerability reports!

But all you really have to look at the two charts: "Top vulnerable applications of 2000" and "Top vulnerable applications of 1999" to get a clue.

Also, I suspect that his 124 figure (which does not appear on the graph) includes some double counting, because it is what you get when you add the "Linux (aggr)" and "Redhat" figures. (Apparently, he doesn't realize that Slackware, Debian and Suse are Linux.)

Run NMAP on your default install of a RH 6.1 box. BTW, there is a nice remote exploit for the lpd setup (I can't remember if it is a buffer overflow or just a misconfiguration). Checkout SecurityFocus.com for a look at the problems w/6.1.

1998-04-07: AppleShare IP Mail Server Buffer Overflow Vulnerability

--ian

1998-04-07: AppleShare IP Mail Server Buffer Overflow Vulnerability

--ian

Might be just me but if you take a look at securityfocus.com and look at slackware there are 0 (this year)! and then you look at debian and theres a few esp last year but most are due to packages but they were fixed very fast. I dont see why debian and slack were not done.

This came up on one of the SecurityFocus mailing lists recently (BugTraq, I think). Performance was one of the key reasons cited for not implementing such a system; economics was the other. Apparently, there are routers out there that lack the powerful (and reasonably fast) ACL routines but are significantly cheaper than their more powerful brethern; some of them are simply older and lack the features of a new router. Either way, it costs significant money to implement a system with ACL checking, and that's money that ISPs would rather spend on something most customers would notice more directly (e.g. more modem racks or more bandwidth)

So, a judge with a bent for privacy could order the FBI to NOT use Carnivore to tap an email system, even while approving the wiretap.

Fat chance of that.

I know... Innocent people will never fall prey to government surveillance, the story goes, because the bureau can't place a tap without a permission from fair and impartial judge. A lovely thought -- but I'll leave you with one more figure from the wiretap report.

Number of wiretap applications denied by judges nationwide last year: Zero.

From a recent Kevin Poulsen article on SecurityFocus.

More than that, I've heard anecdotes of federal judges who just hand out signed, blank orders for wiretaps and search-and-seizures and just let the LEO fill them out at will.

So, a judge with a bent for privacy could order the FBI to NOT use Carnivore to tap an email system, even while approving the wiretap.

Fat chance of that.

I know... Innocent people will never fall prey to government surveillance, the story goes, because the bureau can't place a tap without a permission from fair and impartial judge. A lovely thought -- but I'll leave you with one more figure from the wiretap report.

Number of wiretap applications denied by judges nationwide last year: Zero.

From a recent Kevin Poulsen article on SecurityFocus.

More than that, I've heard anecdotes of federal judges who just hand out signed, blank orders for wiretaps and search-and-seizures and just let the LEO fill them out at will.

Posted never by no-one
from the not-all-that-surprising dept.
Yes, remote root on recent versions of (probably) all Linux-based systems that include NFS. Fortunately, most of them seem to have issued updates already. See the Security Focus Record for a summary (and, yes, an exploit). The irony is of course that we pretend to be concerned with security, but we really care only for ridiculing Microsoft, so when something this serious hits Linux, we don't even report it.

-f

-f

Link on securityfocus is here

Also, bugtraq archived here

Now, to avoid everyone calling me a karma whore, here's my insight on the whole thing:

USSR labs decided that they would hold back details until MS produced a fix. Understandable, I mean, they wouldn't want everyone to be developing exploits for the vulnerability while MS sits on it (Yes, I understand that security through obscurity doesn't work, but I'm sure that USSR would've released details if MS had refused to comply in a timely fashion). Anyway, I think that the problem is people actually getting/using the patch.

Sure, sysadmins will probably do corporate work to clear this up, but people do worse jobs maintaining software than they do their cars. At least with cars, they know that the oil needs to be changed every 5000 or so KM, and that when the tread on the tires is bare, those need to be replaced. People are still using IE 3.0! Users generally too lazy to upgrade software, even if there's a known security issue.

That said, I'm as guilty as most of them.

Link on securityfocus is here

Also, bugtraq archived here

Now, to avoid everyone calling me a karma whore, here's my insight on the whole thing:

USSR labs decided that they would hold back details until MS produced a fix. Understandable, I mean, they wouldn't want everyone to be developing exploits for the vulnerability while MS sits on it (Yes, I understand that security through obscurity doesn't work, but I'm sure that USSR would've released details if MS had refused to comply in a timely fashion). Anyway, I think that the problem is people actually getting/using the patch.

Sure, sysadmins will probably do corporate work to clear this up, but people do worse jobs maintaining software than they do their cars. At least with cars, they know that the oil needs to be changed every 5000 or so KM, and that when the tread on the tires is bare, those need to be replaced. People are still using IE 3.0! Users generally too lazy to upgrade software, even if there's a known security issue.

That said, I'm as guilty as most of them.

Link on securityfocus is here

Also, bugtraq archived here

Now, to avoid everyone calling me a karma whore, here's my insight on the whole thing:

USSR labs decided that they would hold back details until MS produced a fix. Understandable, I mean, they wouldn't want everyone to be developing exploits for the vulnerability while MS sits on it (Yes, I understand that security through obscurity doesn't work, but I'm sure that USSR would've released details if MS had refused to comply in a timely fashion). Anyway, I think that the problem is people actually getting/using the patch.

Sure, sysadmins will probably do corporate work to clear this up, but people do worse jobs maintaining software than they do their cars. At least with cars, they know that the oil needs to be changed every 5000 or so KM, and that when the tread on the tires is bare, those need to be replaced. People are still using IE 3.0! Users generally too lazy to upgrade software, even if there's a known security issue.

That said, I'm as guilty as most of them.

I personally thought the article was lacking in details, so here is the Security Focus bug report that goes into many more details (exploit included).

--

But just think of the boon this could represent to script kiddies everwhere....

M$ AI: It looks like you are trying to crack a system, can I offer you some help from my knowledge base? There an excellent source of exploits covering most M$ products located here.

You used CERT to find out where the holes are. CERT is years behind bugtraq

"I don't think I really love you", or writting internet worms for fun and profit

Anyone doing serious work in these fields could write this. It's just a matter of time before one is released into the wild. Genies, bottles, and all that.

On a related note, the potential impact of this class of worm is probably responsible for funding approval to the new "Infrastructure Protection" the USGOV is deploying to protect us from ourselves. Amusing, considering that this is one class of worm that will likely evolve to a point where it can't be eradicated from the net, at least as long as a few insecure systems are still online.

Thanks to the miracle of Captive-X, it is already possible to make a web-based worm that executes upon viewing. Just look at all these delicious exploits. And since more and more windows apps (e-mail, newsreaders,etc) are using IE as the in-app browser then those are affected too. What is rediculous is that the 'good times' virus is now a very real possibility.

I don't have to worry about it as I use Linux (not that we don't have exploits) but if you're a windows user please turn ActiveX off. The uberworm will happen eventually, and next time maybe it'll delete *.DOC,*.XLS,*.MDB instead of just *.JPG and *.MP3. That's going to seriously break some corporations off.

http:// www.securityfocus.com/vdb/keyword.html?index=vuldb &query=openbsd

Not that I mean to belittle OpenBSD, it's a great system and while it is true that OpenBSD's dedication to security and stability is unmatched by most other OSes, just saying "There are no exploits in OpenBSD" doesn't make it true. In fact, it's a logical fallacy -- you can't prove a negative. And you can't patch a bug you don't know about.

So the approach is right, but OpenBSD needs to drop this whole holier-than-though attitude. (Or should that be holeless-er?)

Check out the stuff at Secur ity Focus for the IP that they are doing the scanning from.


-------

SecurityFocus is a handy site, but they drove me insane when I was trying to understand more about what people were doing to me with cookies.

Adrian

This is a growing hobby of mine as well. I've found that the best way to learn is read...I read both sides of the fence with equal eagerness, because as people have said, most notably Mudge(l0pht), learning to attack is the key to learning to defend. When constructing defences you must think about who and what you're defending against, and get inside their head. I frequent Security Focus, White Hats which is home to arachNID and anything else I can find linked, etc. Tools like Nmap, Nessus, Snort, tripwire, and the assorted "3l337" toolkits are incredibly useful. O'Reilly's Building Internet Firewalls is a good reference for when you get into a production environment, but it's tough to implement with only a few computers.

They rent rackspace from Exodus (who according to messages (index of week's messages) on INCIDENTS). Exodus is doing nothing it seems and condones their activities. They don't seem to be doing anything more than getting some REALLY paranoid sysadmins underwear in a knit, but I really don't like being batch scanned for no real reason. So here's my info I've scoped on them.
whois -h whois.networksolutions.com quova.net ...

Registrant:
David Naffziger (QUOVA2-DOM)
333 W Evelyn
Mountain View, CA 94043
US

Domain Name: QUOVA.NET

Administrative Contact, Technical Contact, Zone Contact:
hostmaster (HO8675-ORG) hostmaster@QUOVA.COM
Quova, Inc.
333 W. Evelyn Ave.
Mountain View , CA 94043
US
(650) 962-2933
Fax- (650) 962-2025
Billing Contact:
billing (BI4691-ORG) billing@QUOVA.COM
Quova, Inc.
333 W. Evelyn Ave.
Mountain View , CA 94043
US
(650) 962-2933
Fax- (650) 962-2025

Record last updated on 23-May-2000.
Record expires on 16-Nov-2001.
Record created on 16-Nov-1999.
Database last updated on 6-Jul-2000 18:55:18 EDT.
Domain servers in listed order:

NS1.QUOVA.COM 208.37.145.35
AUTH50.NS.UU.NET 198.6.1.161


www.quova.net is running Apache/1.3.12 (Unix) PHP/4.0.0 FrontPage/4.0.4.3 on Solaris netcraft
AND SINCE THEY shouldn't mind!!!

cherrycoke:~$ sudo nmap -sX -vv -O www.quova.net
Starting nmap V. 2.54BETA1 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Host (205.177.226.233) appears to be up ... good.
Initiating FIN,NULL, UDP, or Xmas stealth scan against (205.177.226.233)
The UDP or stealth FIN/NULL/XMAS scan took 69 seconds to scan 1525 ports.
For OSScan assuming that port 23 is open and port 1 is closed and neither are firewalled
Interesting ports on (205.177.226.233):
(The 1520 ports scanned but not shown below are in state: closed)
Port State Service
23/tcp open telnet
80/tcp open http
111/tcp open sunrpc
514/tcp open shell
2049/tcp open nfs

TCP Sequence Prediction: Class=random positive increments
Difficulty=132682 (Good luck!)

Sequence numbers: 6A1BA7D9 6A255F59 6A2A5515 6A2F4624 6A37B2F6 6A3CE0D6
Remote OS guesses: Solaris 2.6 - 2.7, Solaris 7
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=2064A)
T1(Resp=Y%DF=Y%W=2297%ACK=S++%Flags=AS%Ops=NNTNWME )
T2(Resp=N)
T3(Resp=N)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=N)


Nmap run completed -- 1 IP address (1 host up) scanned in 83 seconds


Some "security company," with all those notoriously insecure services running on their webserver (NFS, telnet, shell, RPC). Oh well. It looks like their webserver is colocated with some company.
cherrycoke:~$ traceroute www.quova.net
traceroute to www.quova.net (205.177.226.233), 30 hops max, 40 byte packets
1 orangecrush (192.168.0.1) 2.638 ms 2.239 ms 2.238 ms
2 quincy-asx-2.ziplink.net (206.15.185.18) 509.732 ms 203.12 ms 219.374 ms
3 206.15.185.17 (206.15.185.17) 209.86 ms 215.767 ms 199.762 ms
4 * zl-qnz-cisco2bcn.ziplink.net (206.15.158.150) 205.427 ms 214.611 ms
5 zl-pru-h20-1z172h209.ziplink.net (206.15.172.209) 219.845 ms 214.564 ms 219.459 ms
6 206.15.185.217 (206.15.185.217) 219.572 ms 216.462 ms 199.567 ms
7 bay4-322.quincy.ziplink.net (208.196.109.82) 279.498 ms 274.794 ms 259.6 ms
8 zl-sf-e20-2sf7k.ziplink.net (206.15.172.6) 279.477 ms 265.691 ms 279.473 ms
9 pacbell-1.globalcenter.net (198.32.128.32) 279.597 ms 272.632 ms 279.56 ms
10 pos4-2-155M.cr1.SNV.gblx.net (206.132.150.25) 269.622 ms 272.892 ms 299.483 ms
11 pos2-0-622M.cr1.IAD3.gblx.net (206.132.113.102) 337.01 ms 333.853 ms 339.512 ms
12 pos0-0-0-155M.br2.IAD3.gblx.net (206.132.253.26) 339.529 ms 343.903 ms 349.513 ms
13 digiweb.s2-1-1.br2.IAD.gblx.net (204.152.166.190) 349.878 ms 273.863 ms 299.393 ms
14 209.143.145.194 (209.143.145.194) 309.769 ms 277.821 ms 299.558 ms
15 ucla.digiweb.com (206.161.225.11) 299.497 ms 292.234 ms *

They rent rackspace from Exodus (who according to messages (index of week's messages) on INCIDENTS). Exodus is doing nothing it seems and condones their activities. They don't seem to be doing anything more than getting some REALLY paranoid sysadmins underwear in a knit, but I really don't like being batch scanned for no real reason. So here's my info I've scoped on them.
whois -h whois.networksolutions.com quova.net ...

Registrant:
David Naffziger (QUOVA2-DOM)
333 W Evelyn
Mountain View, CA 94043
US

Domain Name: QUOVA.NET

Administrative Contact, Technical Contact, Zone Contact:
hostmaster (HO8675-ORG) hostmaster@QUOVA.COM
Quova, Inc.
333 W. Evelyn Ave.
Mountain View , CA 94043
US
(650) 962-2933
Fax- (650) 962-2025
Billing Contact:
billing (BI4691-ORG) billing@QUOVA.COM
Quova, Inc.
333 W. Evelyn Ave.
Mountain View , CA 94043
US
(650) 962-2933
Fax- (650) 962-2025

Record last updated on 23-May-2000.
Record expires on 16-Nov-2001.
Record created on 16-Nov-1999.
Database last updated on 6-Jul-2000 18:55:18 EDT.
Domain servers in listed order:

NS1.QUOVA.COM 208.37.145.35
AUTH50.NS.UU.NET 198.6.1.161


www.quova.net is running Apache/1.3.12 (Unix) PHP/4.0.0 FrontPage/4.0.4.3 on Solaris netcraft
AND SINCE THEY shouldn't mind!!!

cherrycoke:~$ sudo nmap -sX -vv -O www.quova.net
Starting nmap V. 2.54BETA1 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Host (205.177.226.233) appears to be up ... good.
Initiating FIN,NULL, UDP, or Xmas stealth scan against (205.177.226.233)
The UDP or stealth FIN/NULL/XMAS scan took 69 seconds to scan 1525 ports.
For OSScan assuming that port 23 is open and port 1 is closed and neither are firewalled
Interesting ports on (205.177.226.233):
(The 1520 ports scanned but not shown below are in state: closed)
Port State Service
23/tcp open telnet
80/tcp open http
111/tcp open sunrpc
514/tcp open shell
2049/tcp open nfs

TCP Sequence Prediction: Class=random positive increments
Difficulty=132682 (Good luck!)

Sequence numbers: 6A1BA7D9 6A255F59 6A2A5515 6A2F4624 6A37B2F6 6A3CE0D6
Remote OS guesses: Solaris 2.6 - 2.7, Solaris 7
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=2064A)
T1(Resp=Y%DF=Y%W=2297%ACK=S++%Flags=AS%Ops=NNTNWME )
T2(Resp=N)
T3(Resp=N)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=N)


Nmap run completed -- 1 IP address (1 host up) scanned in 83 seconds


Some "security company," with all those notoriously insecure services running on their webserver (NFS, telnet, shell, RPC). Oh well. It looks like their webserver is colocated with some company.
cherrycoke:~$ traceroute www.quova.net
traceroute to www.quova.net (205.177.226.233), 30 hops max, 40 byte packets
1 orangecrush (192.168.0.1) 2.638 ms 2.239 ms 2.238 ms
2 quincy-asx-2.ziplink.net (206.15.185.18) 509.732 ms 203.12 ms 219.374 ms
3 206.15.185.17 (206.15.185.17) 209.86 ms 215.767 ms 199.762 ms
4 * zl-qnz-cisco2bcn.ziplink.net (206.15.158.150) 205.427 ms 214.611 ms
5 zl-pru-h20-1z172h209.ziplink.net (206.15.172.209) 219.845 ms 214.564 ms 219.459 ms
6 206.15.185.217 (206.15.185.217) 219.572 ms 216.462 ms 199.567 ms
7 bay4-322.quincy.ziplink.net (208.196.109.82) 279.498 ms 274.794 ms 259.6 ms
8 zl-sf-e20-2sf7k.ziplink.net (206.15.172.6) 279.477 ms 265.691 ms 279.473 ms
9 pacbell-1.globalcenter.net (198.32.128.32) 279.597 ms 272.632 ms 279.56 ms
10 pos4-2-155M.cr1.SNV.gblx.net (206.132.150.25) 269.622 ms 272.892 ms 299.483 ms
11 pos2-0-622M.cr1.IAD3.gblx.net (206.132.113.102) 337.01 ms 333.853 ms 339.512 ms
12 pos0-0-0-155M.br2.IAD3.gblx.net (206.132.253.26) 339.529 ms 343.903 ms 349.513 ms
13 digiweb.s2-1-1.br2.IAD.gblx.net (204.152.166.190) 349.878 ms 273.863 ms 299.393 ms
14 209.143.145.194 (209.143.145.194) 309.769 ms 277.821 ms 299.558 ms
15 ucla.digiweb.com (206.161.225.11) 299.497 ms 292.234 ms *

As a matter of fact, it was from this site. The Internet Auditing Project, posted here on August 14, 1999. It's a really good article, certainly worth a read.

Your friendly karma whore,
--
-jacob

I was fortunate enough to attend the "Hacking Exposed:Live!" tutorial at Usenix2000 in San Diego, Ca. 3 weeks ago and can recommend "Hacking Exposed:"(McClure,Cambray & Kurtz,Osborne/Mcgraw-Hill, $39.99 ). My prior network security experience consisted of copying IPCHAINS scripts to rc.firewall, yet I had no problem understanding the material or applying the suggested counter measures. I have since purchased the book and found it even more informative and thorough.

You may also find SecurityFocus.com useful.

Keep up the good work BUGTRAQ.

The transcripts of these sessions are a priceless document of the way semi-skilled crackers feel their way clumsily towards their goals. Honeynet re-named the two main crackers "D1ck" and "J4n3", and their crew "K1dd13", to express their contempt for the group's skills.

Note: We have removed intervening comments in the dialogues for clarity.

:D1ck: i am making a elite archieve of sploits just for k1dd13 members
:D1ck: can u make pass protection on sites?
:J4n3: yeah i can make it password protected
:D1ck: make sure it's leet i dont want any other person other then u me m4ry
mi||er and glitchX to have access :D1ck: hehe
:D1ck: all leet stuff
:J4n3: y0 hooo
:J4n3: ha ha
:J4n3: d0n worry boss
:D1ck: hehehe


Later, crew-member "b0b" expresses considerable interest in learning to code in C. This, he reckons, will make the crew even leeter than it already is.
:b0b :what's vor-ticks-3?
:D1ck :A TROJAN
:D1ck :on receiving a string
:D1ck :on port 80
:D1ck :it opens a bind shell
:D1ck :like on a string 'asad'
:D1ck :it opens port 234323,
:D1ck :or some thing
:D1ck :hehehe
:D1ck :LOL
:b0b :btw, i'm going to be learning C soon too inshallah
:b0b :the[n] we'll have C fights
:b0b :yipeeee
:b0b :i'll insult you in code
:b0b :and once we develop m4d C skillz.. we'll develop D

NT and security are two things that don't match. http://www.securityfocus.com/vdb/stats. html

The BugTraq discussion thread about this issue can be found here.

"Why didn't NSI think of this years ago?"

Umm....They did.

The email they send you has a tracking number, which you must include in the Subject field of any response you send.

Here's the catch - the tracking number is made up of the date and a .blank.-digit number, for example .blank. The numbers used, other than the date, are sequential. Which means - guess what? - the numbers can be predicted with only a very little bit of work. Just include the predicted tracking number in the spoofed email, and there you go!

For a better description, check here.

Hey!

If you want a good source of random numbers, try downloading DIEHARD for Linux.

There are also some RNG links at SecurityFocus.

My copy of diehard includes 'makewhat.exe', a FAST RNG. It makes 11MB chunks of data in... like... less than a second with the faster generators. Check it you if you want.

Michael Tandy

OpenBSD did not have procfs installed by default where as *BSD did. And from what I understand from my security junkie programming buddies, FBSD is still probably vulrable to a procfs exploit (although it hasn't been written yet). OpenBSD worked really hard on this one and fixed the problem right.

Code junkies wanna check out the code? OBSD procfs patch
FBSD procfs patch

There was a recent post on regarding security courses. The poster was kind enough to reply back to the list with a list of responses to his question. I've included some of that list below.. my hands hurt from typing all day, so I don't feel like typing out the rest. Maybe I will tomorrow..

http://www.isc2.org/
http://www.brainbench.com/
http://www.robertgraham.com/
http://www.r00tabega.com/
http://www.sans.org/
http://www.csc.com/
http://www.ey.com
http://www.securityfocus.com/
http://astalavista.box.sk/
http://neworder.box.sk/
http://blacksun.box.sk/tutorials.html
http://www.prosofttraining.com/

Don Head
Linux Mentor

Try securing your systems BEFORE they get cracked. A good few places to start:

Insecure.org, especially this top 50 security tools page.
SecurityFocus the disseminators of the BUGTRAQ list among others.
Attrition.org, especially their security page.
And of course 2600, the l0pht, and Phrack for the latest tasty street info....

#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak

• Types of vulnerabilities.
• Types of firewalls, what they can and can't do for you.
• Router configuration for secure networking, and being a good net citizen.
• Network penetration methods and how to counter them.
• Network traffic monitoring.
• Secure server setup for different types of servers. Some are naturally more secure than others.
• Secure and insecure protocols.
• Procedures and policies.
• (plus many, many more)...

I would take a look over at Security Focus for further ideas on what to include. I also maintain a listing of security sites I feel are worth while.