Tuesday, May 13, 2008

.mil botnet?

along the lines of my inet doom n gloom blurb, now via security focus there is an AF col who is suggesting we build our own .mil botnet to counter the emerging inet threats from china and others...

my post focused mostly on defensive measures, such as filtering, but this guy turns it around and thinks about how we can be offensive so as to have a "deterrent we lack"...

the theme of the piece is that we already know that defense is not an acceptable posture. every example of warfare in the past has shown that holing up in a castle or fort won't keep you safe from an attacker... so we should have offensive strike capability in our arsenal to augment our existing fortifications...

in a nutshell, he says the US should have a botnet to counter-attack attackers. he talks about how they could integrate the code into .mil IDS/IPS, and then goes on to say that they shouldn't throw away obsolete PCs, but rather put botnet code on them and stuff "them in any available space every Air Force base can find". past that, he wants to begin installing the code on .mil machines, and then later on .gov machines.

this weapon would be a DDOS machine. and since we need volume to DDOS, he points out that the entire network must be able to be activated by a single commander, and not sliced up into sections controlled by different military factions. the paper degenerates into endless blathering here, making case after case that the weapon should be controlled by a specific segment of the AF... .mil politics and internal power struggles make me barf in my own mouth... then the last 1/3 of the paper is devoted to countering predicted counter-arguments to such a system.

imo, the guy is missing some key points here. for one, a DDOS botnet isn't an effective counter-attack tool to end an ongoing attack. if successful, it is at best similar to a mute button. once you stop counter-DDOSing your attacker, they will be free to continue their attack on you. you haven't removed the machine from the hostile botnet, or acheived permanent disruption of the attackers C&C, or anything. so what did you achieve?

he says that in some cases, the attacker won't be readily identifiable, but we could make reasonable conclusions on who the host entity is, and just attack them. yea, that'd go over really well. but there is a bigger problem wrapped up in this point. see, an unethical attacker will be controlling a botnet which is global in scope. we won't know where they are coming from, but an entity who found itself under "counter-attack" from our DDOS botnet would know where _we_ are coming from. They can blackhole route .mil and .gov subnets at their border routers, and then we'll need the bandwidth to flood every pipe going into and out of china? right... oh, well we could just spoof the source IP's, except that he points out that spoofing could make an attacker "guilty of the war crime of perfidy" or in violation of UN rules (which the US would *never* violate).

another big issue is that he is talking about running code which can generate (raw?) packets on every non-secret network the US govt has, with remote control capability. let's think about unintended consequences here for a second. we define risk by combining the liklihood of an event with the damage such an event would have if it were to occur. so yea, maybe it's unlikely that an attacker could compromise our official .mil botnet, but if an attacker did, it could be a pretty serious problem. he says the system will have:

protection with various mechanisms, including disabling the botnet code if an automated check indicated the code has been altered. The af.mil botnet could protect against fratricide by having filters to prevent attacks against .mil, .gov or registered allied addresses, unless specifically overridden.

but if you can override them, then maybe an attacker could too... at one very interesting point which ties in w/ the end of my last post, he says:

if the U.S. is defending itself against an attack that originates from a computer which was co-opted by an attacker, then there are real questions about whether the owner of that computer is truly innocent. At the least, the owner may be culpably negligent, and that does not, in fairness or law, prevent America from defending itself if the harm is sufficiently grave

emphasis added there... wow... so anyway, this guy has a few other choice quotes i wanted to include:

We want potential adversaries to know this capability works and will be used when needed. In fact, we should do live-fire demonstrations on the Internet against range targets so foreign signals intelligence organizations can observe. Of course, we should fire inert rounds so as to not give away secrets.

wot? are we talking DDOS here? whatever... and then there's this jewel:

Brute force has an elegance all its own.

anyway, this has become a monster post. despite my belief that a .mil DDOS botnet isn't the right next step, i think the author has hit upon an important point. today the internet is the wild west, and there are little bastions of civility and law, but if a big group of bandits comes riding along, you might have a problem. we aren't going to secure the internet at large by installing firewalls and IDS's at client sites. that does nothing about the badness right outside your fort which is hanging out trying to figure out how to get in.

when this thing reaches a boiling point, and change is at our door, i expect we'll see proactive security methods introduced into the internet at large. there's lots of possibilities, and lots of potential consequences... but, as i'll continue to state, i don't believe the status quo of infosec can be maintained...

Monday, May 12, 2008

botnet foo

so there's an interesting thread on the incidents mailing list talking about bruteforce ssh attacks...

yea yea, old news...

but what's interesting isn't the brute ssh stuff, but the level of sophistication and coordination in the botnet itself. i'd only recently heard of denyhosts, which is a blacklist of known-hostile IP addresses that attack ssh servers. if a new IP fails logins to an ssh server, it gets added to the list...

it seems that this botnet is actively trying to get around this defense mechanism by coordinating attacks so that different login attempts come from different IP addresses. so you'll see an attempt pattern like this:

x.x.x.x: user=alice
y.y.y.y: user=bob
z.z.z.z: user=charlie

the really nifty bit is that state is apparently maintained as the botnet iterates through the dictionary of users... one admin reported that if you blacklist ssh from all but a few /8's, the attacks will cease for a while, but eventually one will come from the whitelisted IP address block and will be the next alphabetical username...

i really need to get a gig as an engineer at an ISP so i can spend some time writing code to identify and disrupt botnets... more needs to be done in that area... but yet again, there is this whole debate about the ethics of dismantling botnets... i haven't thought about it enough yet, but there are clearly important points on both sides of the issue. but lets cut through all of that high-brow legalese and ethical stuff (i'd rather go listen to Jennifer Granick talk about this stuff at bh/dc this year instead of flaming over it anyway;) and cut right to something more grounded...

comcast is talking about bandwidth caps and charges for overusage... so, tell me, what is going to happen when your grandmas bot infested box is spewing spam and she gets a big old bill from comcast...?

statcounter follow-up

so how do you feel about cleartext passwords over inet? anyway, this is a followup from my other post about statcounter passing creds in the clear after you hit their page via SSL... the rub of it is that SSL is up and functional for processing creds, they just don't use it.

so i mailed em, and here's what they said:

As far as the general member log in is concerned, a secure connection is not generally used - our view is that the information in your StatCounter account is not "critically sensitive" in the same way as your online bank account would be. In addition, we have never had a case of anyone's log-in details being stolen.

Basically, since we provide a free service, we have to analyse everything on a risk return basis from the perspective of our members. The extra cost of providing secure log in facilities in terms of increased hosting costs etc would reduce the level of service we can provide to our members and tha vast majority of our members are happy with the system as it stands. This is the thinking behind our position.

The service we provide, however, is 100% driven by our members. So if a large portion of our members voiced their concerns to us in this regard, then this is something we would have to implement.

i think that bit at the end is very cool. kudos for being willing to listen to your user base. so i wrote em back w/ this blurb, and haven't heard anything in a few days:

I completely understand that there is a cost benefit analysis that must be done in regards to any security measure. You do provide a nifty free service, and I'm grateful for it...

My main disagreement w/ the crux of your response comes from the fact that you already have SSL infrastructure in place. You clearly have the capacity to handle the current amt of people who hit https://statcounter, although I'm sure most users probably hit http:// instead.

I have never hosted a site, so I can only speculate, but it seems that the increased cost of doing an HTTPS POST for users who explicitly travel to the HTTPS main page would only moderately increase the amount of bandwidth hitting your SSL devices (considering that most users probably hit HTTP by default).

...

[if you] do your login POSTs as cleartext HTTP, then you should just disable the HTTPS site entirely, because it is wasting money and bandwidth by encrypting the public site and not protecting user credentials...


what do you think? do you use the same username and password for accounts like this? or do you have a different password for every site you visit? do you bother to check if you're on SSL when you're logging into a site? are we worried about sniffing anymore?

not sure how i feel about this...

but i must confess...

so a long time ago, i built this machine as a gentoo/windows dual boot box. at the time i had gentoo and beryl running on my work d620, and i was very very happy... i'm not anti-windows, mainly because i game. so i made gentoo the primary boot, and off i went.... and i ended up using windows almost every time i booted.

since then i've changed jobs, and installed gentoo on a POS toshiba (redundant redundant) laptop. during a recent emerge -uD world, the truecrypt module started bombing when i try to open my tc files. also, i've been listing to the endless issues my buddy is having w/ his gentoo install/upgrade experiences. the two of us have been using gentoo for a few years now...

so today as i sat down to boot my windows box to browse the web and write some emails, i was like WTF... i've never been happy w/ where this gentoo box is, and i shouldn't be using windows for shit i know is good on linux. so fuckit.

i already had the latest version b/c i'd installed it on a machine at a client site. jdm and i have been debating it for a few days, and i took the plunge and installed ubuntu as my primary desktop OS. i have a weird ass setup atm, so when i tried to do manual partitioning (w/o reading any directions) it (or i) dorked up. so i grabbed a spare big ass hdd and just used the wizard. and you know what? i'm up and running in less time (than gentoo or windows) and having a much easier go at it.

my other buddy sk00t will give me no end of shit for it, i'm now to the point where the easiness of ubuntu and the fact that it just works has outweighed my macho feelings that anyone who doesn't compile their entire computer from scratch has something to prove to the world at large. hell, even some of my non-tech friends will probably chuckle at me, as i'd been advocating gentoo to them as being better than ubuntu.

but the fact is that while there is still a place in my heart for gentoo (much as there is for fbsd), apt-get isn't all that different than portage (or the ports tree). and i installed this thing in a very short amt of time (like an hour) and everything just works.

ubuntu is not superior to gentoo, but seems to be more actively supported. and when it's sunday afternoon and i want to not be using windows, having things work right w/o much pain seems more important than hacking through some issue for a few hours just to make my box act the way i want.

most importantly, i know i'll be using this as my default environment... now i just have to fix my windows partition so i can recover my documents and continue playing games that use punkbuster ;)

Friday, May 9, 2008

certs and paranoia

so did the gmail ssl cert change today for anyone else, or did someone just MitM me?

i've been in the habbit of checking the hash on the site for a while now. i think kaminsky talked about doing things to help remember hashes a few years back at blackhat/dc (i think he proposed using phases derived from the hash value, which are easier to remember, but i'm not sure). i know others have talked about hash visualization... i dug around for a hash visualization plugin for firefox, and turned up nothing, and am kicking around building one (w/ all my free time ;)...

anyway, it's tough to remember those long hash strings, so i was using the weaker method of just remembering a few values and their placement in the hash string. much to my surprise this morning, the values i was expecting were no longer there...

sooooo, now what? i hit cancel... then i went back and examined the cert, and the cert chain. but wtf am i lookin for? if they can gen a fake gmail cert, they can gen a fake cert chain too, right? so anyway, i went ahead and logged in after a few min of indecision. i need to rotate my passwords anyway ;)

but now i'm left wondering what is the right thing to do when a cert changes... how do you verify that it is legit, and not a MitM? guess i've got some reading to do...

Thursday, May 1, 2008

dur, wtf statcounter?

so my buddy and i recently noticed this lameness with statcounter and other sites...

so i do dislike non-ssl stuff in some situations, like when google-ish stuff passes you to cleartext after the login... but at least when you hit the initial google-ish page w/ https, it will generally retain your ssl session past login...

what irks me is that statcounter does the opposite... i hit https://statcounter.com and go to login, and firefox warns that i'm passin creds in cleartext:



so i embarked on testing the stuff in this post, just cause i was curious... i figured others had probably been all over bitching about this type of stupidity, but maybe not...

anywho, so i check the source of the page to see what the form is doing:


and then i tcpdump and sure enough:

(syn)
05:02:34.157286 IP (tos 0x0, ttl 128, id 37627, offset 0, flags [DF], proto TCP (6), length 48) 192.168.13.113.4820 > 67.15.80.69.80: S, cksum 0xb352 (correct), 1179194610:1179194610(0) win 65535
0x0000: 4500 0030 92fb 4000 8006 065f c0a8 0d71 E..0..@...._...q
0x0010: 430f 5045 12d4 0050 4649 14f2 0000 0000 C.PE...PFI......
0x0020: 7002 ffff b352 0000 0204 05b4 0101 0402 p....R..........

(syn-ack)
05:02:34.216816 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], proto TCP (6), length 44) 67.15.80.69.80 > 192.168.13.113.4820: S, cksum 0x8e44 (correct), 974121408:974121408(0) ack 1179194611 win 5840
0x0000: 4500 002c 0000 4000 2d06 ec5e 430f 5045 E..,..@.-..^C.PE
0x0010: c0a8 0d71 0050 12d4 3a0f e9c0 4649 14f3 ...q.P..:...FI..
0x0020: 6012 16d0 8e44 0000 0204 0518 0000 `....D........

(ack)
05:02:34.216945 IP (tos 0x0, ttl 128, id 37630, offset 0, flags [DF], proto TCP (6), length 40) 192.168.13.113.4820 > 67.15.80.69.80: ., cksum 0xbc35 (correct), 1:1(0) ack 1 win 65535
0x0000: 4500 0028 92fe 4000 8006 0664 c0a8 0d71 E..(..@....d...q
0x0010: 430f 5045 12d4 0050 4649 14f3 3a0f e9c1 C.PE...PFI..:...
0x0020: 5010 ffff bc35 0000 0000 0000 0000 P....5........

(cleartext-password)
05:02:34.218309 IP (tos 0x0, ttl 128, id 37631, offset 0, flags [DF], proto TCP (6), length 906) 192.168.13.113.4820 > 67.15.80.69.80: P, cksum 0x8c8d (correct), 1:867(866) ack 1 win 65535
0x0000: 4500 038a 92ff 4000 8006 0301 c0a8 0d71 E.....@........q
0x0010: 430f 5045 12d4 0050 4649 14f3 3a0f e9c1 C.PE...PFI..:...
0x0020: 5018 ffff 8c8d 0000 504f 5354 202f 7072 P.......POST./pr
0x0030: 6f6a 6563 742f 2048 5454 502f 312e 310d oject/.HTTP/1.1.
0x0040: 0a48 6f73 743a 206d 7933 2e73 7461 7463 .Host:.my3.statc
0x0050: 6f75 6e74 6572 2e63 6f6d 0d0a 5573 6572 ounter.com..User
0x0060: 2d41 6765 6e74 3a20 4d6f 7a69 6c6c 612f -Agent:.Mozilla/
...
0x02e0: 2530 305a 2539 3925 3043 2543 343b 2073 Z%99%0C%C4;.s
0x02f0: 6573 7369 6f6e 5f32 3034 3630 393d 3132 ession_204609=12
0x0300: 3039 3631 3531 3330 2532 3630 0d0a 436f 09615130%260..Co
0x0310: 6e74 656e 742d 5479 7065 3a20 6170 706c ntent-Type:.appl
0x0320: 6963 6174 696f 6e2f 782d 7777 772d 666f ication/x-www-fo
0x0330: 726d 2d75 726c 656e 636f 6465 640d 0a43 rm-urlencoded..C
0x0340: 6f6e 7465 6e74 2d4c 656e 6774 683a 2035 ontent-Length:.5
0x0350: 330d 0a0d 0a66 6f72 6d5f 7573 6572 3d72 3....form_user=r
0x0360: 776e 696e 2666 6f72 6d5f 7061 7373 3d** wnin&form_pass=*
0x0370: **** **** **** **26 4c4f 4749 4e5f 4255 *******&LOGIN_BU
0x0380: 5454 4f4e 3d4c 4f47 494e TTON=LOGIN

so, do you think ssl is available? well i can telnet to 443 on my3.statcounter.com... let's see:


and what do you know... it logs me in... let's see what tcpdump says... hrmm, lots of ssl foo w/ certs and such, and then lookit:

(the last ssl push)
05:06:01.601591 IP (tos 0x0, ttl 45, id 9839, offset 0, flags [DF], proto TCP (6), length 63) 67.15.80.69.443 > 192.168.13.113.4834: P, cksum 0x4e45 (correct), 5419:5442(23) ack 1125 win 8420
0x0000: 4500 003f 266f 4000 2d06 c5dc 430f 5045 E..?&o@.-...C.PE
0x0010: c0a8 0d71 01bb 12e2 466f 21b9 5f9f 5c66 ...q....Fo!._.\f
0x0020: 5018 20e4 4e45 0000 1503 0100 1243 c1f8 P...NE.......C..
0x0030: cb60 a052 d4d3 28f3 b8fc 1452 214b 64 .`.R..(....R!Kd

(ssl fin)
05:06:01.601659 IP (tos 0x0, ttl 45, id 9841, offset 0, flags [DF], proto TCP (6), length 40) 67.15.80.69.443 > 192.168.13.113.4834: F, cksum 0xf49f (correct), 5442:5442(0) ack 1125 win 8420
0x0000: 4500 0028 2671 4000 2d06 c5f1 430f 5045 E..(&q@.-...C.PE
0x0010: c0a8 0d71 01bb 12e2 466f 21d0 5f9f 5c66 ...q....Fo!._.\f
0x0020: 5011 20e4 f49f 0000 0000 0000 0000 P.............

(ssl ack)
05:06:01.601735 IP (tos 0x0, ttl 128, id 38227, offset 0, flags [DF], proto TCP (6), length 40) 192.168.13.113.4834 > 67.15.80.69.443: ., cksum 0x18ad (correct), 1125:1125(0) ack 5442 win 64727
0x0000: 4500 0028 9553 4000 8006 040f c0a8 0d71 E..(.S@........q
0x0010: 430f 5045 12e2 01bb 5f9f 5c66 466f 21d0 C.PE...._.\fFo!.
0x0020: 5010 fcd7 18ad 0000 0000 0000 0000 P.............

(ssl ack-ack)
05:06:01.601803 IP (tos 0x0, ttl 128, id 38228, offset 0, flags [DF], proto TCP (6), length 40) 192.168.13.113.4834 > 67.15.80.69.443: ., cksum 0x18ac (correct), 1125:1125(0) ack 5443 win 64727
0x0000: 4500 0028 9554 4000 8006 040e c0a8 0d71 E..(.T@........q
0x0010: 430f 5045 12e2 01bb 5f9f 5c66 466f 21d1 C.PE...._.\fFo!.
0x0020: 5010 fcd7 18ac 0000 0000 0000 0000 P.............

(cleartext syn)
05:06:01.763055 IP (tos 0x0, ttl 128, id 38257, offset 0, flags [DF], proto TCP (6), length 48) 192.168.13.113.4836 > 70.85.96.58.80: S, cksum 0xdac5 (correct), 1060888897:1060888897(0) win 65535
0x0000: 4500 0030 9571 4000 8006 f0ad c0a8 0d71 E..0.q@........q
0x0010: 4655 603a 12e4 0050 3f3b e141 0000 0000 FU`:...P?;.A....
0x0020: 7002 ffff dac5 0000 0204 05b4 0101 0402 p...............

(cleartext syn-ack)
05:06:01.805390 IP (tos 0x0, ttl 46, id 0, offset 0, flags [DF], proto TCP (6), length 44) 70.85.96.58.80 > 192.168.13.113.4836: S, cksum 0x8285 (correct), 1186140239:1186140239(0) ack 1060888898 win 5840
0x0000: 4500 002c 0000 4000 2e06 d823 4655 603a E..,..@....#FU`:
0x0010: c0a8 0d71 0050 12e4 46b3 104f 3f3b e142 ...q.P..F..O?;.B
0x0020: 6012 16d0 8285 0000 0204 0518 0000 `.............

(cleartext ack)
05:06:01.805390 IP (tos 0x0, ttl 128, id 38258, offset 0, flags [DF], proto TCP (6), length 40) 192.168.13.113.4836 > 70.85.96.58.80: ., cksum 0xb076 (correct), 1:1(0) ack 1 win 65535
0x0000: 4500 0028 9572 4000 8006 f0b4 c0a8 0d71 E..(.r@........q
0x0010: 4655 603a 12e4 0050 3f3b e142 46b3 1050 FU`:...P?;.BF..P
0x0020: 5010 ffff b076 0000 0000 0000 0000 P....v........

(cleartext post-login page)
05:06:01.815469 IP (tos 0x0, ttl 128, id 38259, offset 0, flags [DF], proto TCP (6), length 763) 192.168.13.113.4836 > 70.85.96.58.80: P, cksum 0xa53a (correct), 1:724(723) ack 1 win 65535
0x0000: 4500 02fb 9573 4000 8006 ede0 c0a8 0d71 E....s@........q
0x0010: 4655 603a 12e4 0050 3f3b e142 46b3 1050 FU`:...P?;.BF..P
0x0020: 5018 ffff a53a 0000 4745 5420 2f70 726f P....:..GET./pro
0x0030: 6a65 6374 2f3f 6163 636f 756e 745f 6964 ject/?account_id
0x0040: 3d32 3034 3238 3330 266c 6f67 696e 5f69 =2042830&login_i
0x0050: 643d 3226 636f 6465 3d38 3033 6333 3939 d=2&code=803c399
0x0060: 3430 3261 3633 6363 3833 3966 3238 6336 402a63cc839f28c6
0x0070: 3564 6162 6262 6432 3026 2048 5454 502f 5dabbbd20&.HTTP/

so yea, statcounter is completely set up and ready to process your logins securely, they'd just rather save that one extra 's' they'd have to gen from their php source to crypt it... so maybe their admins thing they are wicked cool b/c they're still running leet apache 1.3.37, but they should remember they're also running mod_ssl 2.8.28... and use it... by default...

scuse me, mr ranum sir... can not using crypto for passwords when you have crypto available be the 7th dumbest thing in security? ;)