Having just written a piece about CERT and ego trips I feel obliged to counter-balance it with a pointer to an interview worthy of applause.
The humble and intelligent interviewee is Daniel Mehan, CIO of the FAA whom I will describe with two quotes regarding security.
The first describes how to improve "cyber security": To improve cybersecurity, Mehan said the FAA and all business must harden individual network and system elements, isolate elements to avoid viral attacks, and backup elements to support event recovery. "You're going to catch a cold," Mehan said. "The trick is containing the cold.".
The second shows that a good security practitioner doesn't necessarily come with an ego the size of the planet: Even so, Mehan said he couldn't guarantee that FAA systems will counter all unseen attacks. Hackers are continually arming themselves for new attacks, he said. Thus, the FAA and other organizations must remain on their toes and continue to improve their cybersecurity efforts. "This is an area where you always have to be prepared," he said.
As I said: intelligence and humility.
It looks like CERT continues to lose friends. There have always been disputes about CERT and its role which have ranged in depth and breadth to the point of becoming this century's dispute on the sex of angels (This is not the so-called palamite controversy regarding, amongst other things, the divine essence of angels).
One of the many issues has been that of CERT witholding information and waiting for all the vendors to come up with an answer before publishing anything. The argument in favour goes something along the lines of: "we are giving the vendors the best possible chance of issuing fixes for the vulnerability". The counter-argument is: "the baddies already have the code, by witholding the information you are giving them time to scourge the helpless Internet" (my dramatisation of the issue, of course).
The argument this time revolves around CERT funding (An oldish rant comes from attrition.org) with the latest spat being in relation to "free riding" on other people's research. The point being made is that when CERT obtains vulnerabilities it sends information off to paying customers first and then follows the prescribed "wait for vendors" dance before releasing their bulletin to the wide world.
So, the reasoning goes, if I do all the research for free and send it off to CERT only for them to make money out of it then I might as well just not send it, publish on Bugtraq and be famous.
Might it not be the case for trying to build better cooperation, perhaps creating something which renders CERT obsolete rather than fighting? Just who exactly benefits from these quarrels? Somehow I doubt it is the "helpless Internet".
Consider taking the constructive side of the argument.
Lifted straight off a posting by Ben Laurie on the open-source mailing list: the opinions and presentations at a Software Security Workshop.
A ten minute read which should cause (in those with a predisposition to such activity) about two week's worth of thinking.
Having mentioned the interesting correlation between attacks and people visiting my web site to check if they made it into the daily IDS summary I thought I'd write it up properly including all the gory details.
As it is in preformatted mode I'm afraid it is not as pretty as properly done HTML pages but the data is all there (except for the raw packets but these you can get from the web site).
The format is in temporal order, oldest first. I give you the IP address, whois record, Snort output, Apache log (in Combined log format). From the Apache Agent field it is pretty clear that either the same script or a similar one has been used in each case. Note also the "evolution" in the attack attempts.
It is also interesting that the first "client" attempted a recon vist of the daily Snort logs, the others went straight.
218.62.92.153
inetnum: 218.62.0.0 - 218.62.127.255
netname: CHINANET-JL
descr: CHINANET jilin province network
descr: China Telecom
descr: A12,Xin-Jie-Kou-Wai Street
descr: Beijing 100088
country: CN
Mar 18 03:57:54 tempest snort: IDS296/web-misc_http-whisker-splicing-attack-space: {TCP} 218.62.92.153:4767 -> 195.82.120.100:80
Mar 18 03:57:54 tempest snort: IDS243/web-cgi_http-cgi-pipe: {TCP} 218.62.92.153:4767 -> 195.82.120.100:80
Mar 18 03:57:55 tempest snort: IDS243/web-cgi_http-cgi-pipe: {TCP} 218.62.92.153:4767 -> 195.82.120.100:80
218.62.92.153 - - [16/Mar/2002:16:12:43 +0000] "GET /data/snort_daily.html HTTP/1.0" 200 63461 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
218.62.92.153 - - [18/Mar/2002:17:02:20 +0000] "GET /data/snort_daily.html HTTP/1.0" 200 73461 "-" "libwww-perl/5.21"
203.149.250.59,61
inetnum: 203.149.250.0 - 203.149.250.63
netname: MARYNET
descr: We are a internet access company
country: TW
admin-c: MC137-AP
tech-c: JYB1-AP
mnt-by: IS-NCD
May 29 15:48:04 tempest snort: spp_portscan: PORTSCAN DETECTED from 203.149.250.59 (THRESHOLD 5 connections exceeded in 0 seconds)
May 29 15:48:04 tempest snort: MS/SQL connection attempt: {TCP} 203.149.250.59:2741 -> 195.82.120.99:1433
May 29 15:48:04 tempest snort: MS/SQL connection attempt: {TCP} 203.149.250.59:2740 -> 195.82.120.98:1433
May 29 15:48:04 tempest snort: MS/SQL connection attempt: {TCP} 203.149.250.59:2742 -> 195.82.120.100:1433
May 29 15:48:04 tempest snort: MS/SQL connection attempt: {TCP} 203.149.250.59:2744 -> 195.82.120.102:1433
May 29 15:48:04 tempest snort: MS/SQL connection attempt: {TCP} 203.149.250.59:2745 -> 195.82.120.103:1433
May 29 15:48:05 tempest snort: MS/SQL connection attempt: {TCP} 203.149.250.59:2747 -> 195.82.120.105:1433
May 29 15:48:05 tempest snort: MS/SQL connection attempt: {TCP} 203.149.250.59:2748 -> 195.82.120.106:1433
May 29 15:48:05 tempest snort: MS/SQL connection attempt: {TCP} 203.149.250.59:2751 -> 195.82.120.109:1433
May 29 15:48:05 tempest snort: MS/SQL connection attempt: {TCP} 203.149.250.59:2752 -> 195.82.120.110:1433
May 29 15:48:49 tempest snort: spp_portscan: portscan status from 203.149.250.59: 9 connections across 9 hosts: TCP(9), UDP(0)
May 29 15:49:18 tempest snort: spp_portscan: End of portscan from 203.149.250.59: TOTAL time(3s) hosts(9) TCP(9) UDP(0)
203.149.250.61 - - [30/May/2002:18:03:01 +0100] "GET /data/snort_daily.html HTTP/1.0" 200 54371 "-" "libwww-perl/5.21"
203.149.33.127
inetnum: 203.149.32.0 - 203.149.63.255
netname: SAMART-TH
descr: Samart Corporation Co., Ltd.
descr: 99/6 Software Park Tower,30th Fl. Chaengwattana Rd.
descr: Klong Gluar, Pak-Kred, Nonthaburi 11120 Thailand
country: TH
Oct 14 08:01:36 tempest snort: IDS177/netbios_netbios-name-query: {UDP} 203.149.33.127:1024 -> 195.82.120.98:137
Oct 14 08:01:36 tempest snort: IDS177/netbios_netbios-name-query: {UDP} 203.149.33.127:1024 -> 195.82.120.99:137
Oct 14 08:01:36 tempest snort: IDS177/netbios_netbios-name-query: {UDP} 203.149.33.127:1024 -> 195.82.120.100:137
Oct 14 08:01:36 tempest snort: IDS177/netbios_netbios-name-query: {UDP} 203.149.33.127:1024 -> 195.82.120.102:137
Oct 14 08:01:37 tempest snort: IDS177/netbios_netbios-name-query: {UDP} 203.149.33.127:1024 -> 195.82.120.103:137
Oct 14 08:01:37 tempest snort: IDS177/netbios_netbios-name-query: {UDP} 203.149.33.127:1024 -> 195.82.120.105:137
Oct 14 08:01:37 tempest snort: IDS177/netbios_netbios-name-query: {UDP} 203.149.33.127:1024 -> 195.82.120.106:137
Oct 14 08:01:37 tempest snort: IDS177/netbios_netbios-name-query: {UDP} 203.149.33.127:1024 -> 195.82.120.109:137
Oct 14 08:01:38 tempest snort: IDS177/netbios_netbios-name-query: {UDP} 203.149.33.127:1024 -> 195.82.120.110:137
203.149.33.127 - - [14/Oct/2002:16:12:38 +0100] "GET /data/snort_daily.html HTTP/1.0" 200 65378 "-" "libwww-perl/5.21"
210.52.79.148
inetnum: 210.52.79.144 - 210.52.79.151
netname: LUTENG-GARDEN
descr: xiamen city
country: CN
Jan 16 02:58:15 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3408 -> 195.82.120.98:1433
Jan 16 02:58:15 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3412 -> 195.82.120.102:1433
Jan 16 02:58:15 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3413 -> 195.82.120.103:1433
Jan 16 02:58:15 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3409 -> 195.82.120.99:1433
Jan 16 02:58:15 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3410 -> 195.82.120.100:1433
Jan 16 02:58:15 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3415 -> 195.82.120.105:1433
Jan 16 02:58:15 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3416 -> 195.82.120.106:1433
Jan 16 02:58:15 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3420 -> 195.82.120.110:1433
Jan 16 02:58:15 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3419 -> 195.82.120.109:1433
Jan 16 02:58:16 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3408 -> 195.82.120.98:1433
Jan 16 02:58:16 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3412 -> 195.82.120.102:1433
Jan 16 02:58:16 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3413 -> 195.82.120.103:1433
Jan 16 02:58:16 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3409 -> 195.82.120.99:1433
Jan 16 02:58:16 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3410 -> 195.82.120.100:1433
Jan 16 02:58:16 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3415 -> 195.82.120.105:1433
Jan 16 02:58:17 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3416 -> 195.82.120.106:1433
Jan 16 02:58:17 tempest snort: MS/SQL connection attempt: {TCP} 210.52.79.148:3420 -> 195.82.120.110:1433
Jan 16 02:58:17 tempest snort: MS/SQL connection attempt: {TCP}
210.52.79.148:3419 -> 195.82.120.109:1433
210.52.79.148 - - [16/Jan/2003:15:34:24 +0000] "GET /data/snort_daily.html HTTP/1.0" 200 41567 "-" "libwww-perl/5.21"
That's all folks!
A while back I believe I mentioned how, back in 1999, I used to joke that the Bad Guys really needed a database to keep track of vulnerabilities and hosts which they had already scanned. I don't think they heeded my call at the time, nor do I suspect that they are particularly prone to doing so now but an interesting pattern is emerging which I feel worthy of an honourable mention.
For quite some time (since June 2001), I've been placing my IDS logs on the web for IDS researchers and SANS students to use. In particular as an extra bonus I process my daily logs with a small Perl script which produces HTML for me to post. The data which is produced by the script is a good representation, relatively easy to browse and search. I am personally fond of the section with the distribution of attack methods which I always read first as it gives me a good handle on the overall picture.
One of the ideas which has always been drilled into me, in particular by Stephen Northcutt, has been that of "log fusion". There is a lot of value in looking at logs in context and attempting to combine information from, say, Apache, Squid, Sendmail and your IDS (not to mention syslog, of course). In particular this technique is perfect for rooting out false positives concerning web traffic, the best example being the good ol' 3DNS "attacks" which compared against Squid logs become load-balancing attempts after a web request.
Now, who says that you cannot apply "log fusion" in the opposite direction? I've recently been comparing the web accesses to the daily Snort data with attacks and suddently my heart jumped: in the list of attacks I had sites with source addresses which matched exactly the source address of hosts checking the daily log the following day!
What happened? Well, very simple really: if you had developed a new attack and wanted to test it against a set of Snort rules to see if it was detected you would probably run it on a small private segment. But what about modified Snort rulesets? So you search the web with Google and you fall upon my site which not only publishes daily Snort logs but also the rules being used. What follows is that you try your attack against my web site on the assumption that the Snort sensor is there. Then you check the following day to see how much of it was detected. Not bad at all: free remote verification!
There is only one small catch in the whole argument: who says that the producer of the public data is the only IDS running on the network?
I'm sorry, I really shouldn't be doing this but this is just getting better by the day. Every single time I cannot help but think about other uses for £50.
We have determined that there isn't much happening in the security community at the moment if we ignore the slight issue with the RIAA. Just so it doesn't look like we are not covering the newsworthy material let us spend a line or two on the matter: it concerns the fact that the RIAA has apparently employed a well-known chap to write a worm to run after peer-to-peer networks. Furthermore the chap in question also created a DDoS network of all the systems infected by the worm. Oh, hot off the press, it was all a hoax , what a pity. Allow me to quote from the article: According to Aitel, who said he has no other involvement with the group, Gobbles helps to keep the security industry's "huge egos" in check. Couldn't agree more.
Fine, now that we've covered the real stuff let us get back to the serious plight of electron wastage. Our candidates for the 2003 Preferred Security Consultancy award have released something "new". Quick summary for those quite rightly asleep in the past week: Microsoft will release their code to governments in some form. Guess what the security slant it is? That, as we know (do we?) that open source is safer, this will improve security for governments under attack (according to their database). I am still attempting to read information into the sequence of bytes making up the press release.
Very well, the electrons haven't even dried on the last entry and we have a new winner available in full for the meager sum of £50.
Ladies and gentlemen, in the fine tradition of the Sibilla Cumana who used to cunningly move the comma in ibis redibis non morieris in bello, we have now been told that, as predicted by fine research, hackers take Christmas off and party on New Year's Eve. Next will be the news that SMS messages on New Year's Eve hit the all-time high (for the US folks, this is more GSM-only cool stuff).
For those who don't know the story or, alternatively, don't read much Latin it goes something like this: before you went off for a war you'd pop in to see the oracle and ask what would be of you. So she would say the fabled words which, depending on the position of the comma, would translate to "you shall go, you shall not return and die in war" or, alternatively, "you shall go, you shall return and not die in war". Why does it work in Latin? Simple: "ibis, redibis non, morieris in bello" gives you the bad news whereas "ibis, redibis, non morieris in bello" means you get to keep your hide. Also known as a self-fulfilling prophecy although you could suggest that the press releases are simply tautologies.
This year I have a winning candidate for the best "silly season" remark. The term comes from the british newspaper industry and normally describes the summer months when Parliament is in recess. During that period any rubbish any politician even thinks about hinting at is blown into a story out of all proportion by newspapers starved of all the good parliamentary news and gossip.
In the security industry we have a similar season, the slight problem is that it seems to last twelve months per annum and has just had its peak.
Just before the Christmas break a security consulting group published the Earth-rattling factoid that attacks increase during school and university breaks. Written with suitably strong sentences and catchy phrases it made it sound like years of research were necessary for this amazing conclusion to be reached. What is worse is that the mainstream media picked it up and reported on it.
Yet another chapter in the failures of the security industry to act responsibly.