Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
Wednesday, August 27, 2008
Border Gateway Protocol
Close on the heels of the publicity surrounding cookie hijacking there is now another potentially much more serious problem, this time with the Border Gateway Protocol the core routing protocol underlying the Internet...
Wednesday, August 20, 2008
Cookie Hijacking
Things are looking a bit grim on the security side. Close on the heels of the DNS cache poisoning flaw discovered by Dan Kaminsky last month, there is now a new bogie man, automated HTTPS cookie hijacking...
Time progression showing vulnerable DNS servers: Red dots represent unpatched servers, yellow dots patched servers with NAT problems, green dots are patched servers.
The problem has gotten a lot of attention with respect to unencrypted GMail sessions, in fact there is now a widely available automated tool which allows you to steal session cookies on
Surf Jacking Gmail demonstration from Sandro Gauci on Vimeo
However the problems is more widespread than just GMail, although there are still problems even there, and potentially affects a much broader range of sites.
Of course we can't all go hide in a darkened room and realistically, unless you're a high profile target, your chance of getting caught by this vulnerability is fairly low. However potentially at least, this is serious. You email, merchant account, banking and other personal information are potentially at risk. Right now it's not clear how widespread this problem actually is, so be careful out there...
Time progression showing vulnerable DNS servers: Red dots represent unpatched servers, yellow dots patched servers with NAT problems, green dots are patched servers.
The problem has gotten a lot of attention with respect to unencrypted GMail sessions, in fact there is now a widely available automated tool which allows you to steal session cookies on
HTTP and HTTPS sites that do not set the cookie secure flag. Surf Jacking Gmail demonstration from Sandro Gauci on Vimeo
However the problems is more widespread than just GMail, although there are still problems even there, and potentially affects a much broader range of sites.
Since so many sites are likely vulnerable, the actual reporting process is probably going to fall on the shoulders of users. To check your sites under Firefox, go to the Privacy tab in the Preferences window, and click on "Show Cookies". For a given site, inspect the individual cookies, and if any have "Send For: Encrypted connections only", delete them. Then try to visit your site again. If it still allows you in, the site is insecure and your session can be stolen. You should report this to the site maintainer. - Mike Perry
Of course we can't all go hide in a darkened room and realistically, unless you're a high profile target, your chance of getting caught by this vulnerability is fairly low. However potentially at least, this is serious. You email, merchant account, banking and other personal information are potentially at risk. Right now it's not clear how widespread this problem actually is, so be careful out there...
Friday, August 08, 2008
Paper Phishing
So we're all used to identifying and avoiding phishing attempts via email, but what about when it happens on paper? Today I received an actual paper letter, purporting to be from one of my banks, advising me that they had contacted me some time ago and hadn't had a reply, and that the due to a change in the law they needed to update the information about my extra card holder.
The letter looked genuine and included a 'Extra Cardholder Information Form' and a prepaid envelope to provide the details, and a freephone number that I could alternatively call to provide them. It went on to advise me that if I still needed my extra cardholder I must provide the information within 28 days or they would remove the extra card from my account.
So it looked genuine, except it sort of didn't. My finely tuned spider sense was tingling, if this was an email it wouldn't have even made it past my spam filter.
Despite the fact the letter had my account number on it, and was sent to my address, I was suspicious. So I called the fraud division of the bank in question, they had no record on my account of sending out such a letter, and the freephone number didn't, as far as they knew, belong to them. I'd just been the (almost) victim of a paper-based phishing attack.
Both of us were surprised, this is the first example of a paper-based phishing attack that I, and perhaps more worryingly the bank, had come across. If you get a letter that doesn't look quite right from your bank and is asking for personal information that, as far as you know, they should already have, call your bank on a number you know is genuine to confirm that it was actually from them.
It looks like the bad guys just raised the stakes, and we're now playing a new game entirely. It also looks likely that there has been some sort of major compromise with this specific bank, there were too many details in the letter to have come from a retail source. So this is your warning, keep your guard up...
The letter looked genuine and included a 'Extra Cardholder Information Form' and a prepaid envelope to provide the details, and a freephone number that I could alternatively call to provide them. It went on to advise me that if I still needed my extra cardholder I must provide the information within 28 days or they would remove the extra card from my account.
So it looked genuine, except it sort of didn't. My finely tuned spider sense was tingling, if this was an email it wouldn't have even made it past my spam filter.
Despite the fact the letter had my account number on it, and was sent to my address, I was suspicious. So I called the fraud division of the bank in question, they had no record on my account of sending out such a letter, and the freephone number didn't, as far as they knew, belong to them. I'd just been the (almost) victim of a paper-based phishing attack.
Both of us were surprised, this is the first example of a paper-based phishing attack that I, and perhaps more worryingly the bank, had come across. If you get a letter that doesn't look quite right from your bank and is asking for personal information that, as far as you know, they should already have, call your bank on a number you know is genuine to confirm that it was actually from them.
It looks like the bad guys just raised the stakes, and we're now playing a new game entirely. It also looks likely that there has been some sort of major compromise with this specific bank, there were too many details in the letter to have come from a retail source. So this is your warning, keep your guard up...
Monday, July 21, 2008
OSCON: Perl Security
This afternoon I'm breaking my no Perl rule and I'm sitting in "Perl Security" given by Paul Fenwick. I'm sitting next to Brad and Chris, and Sam is supposedly in here somewhere...
From the looks of things, Paul is trying to pull a Dick Hardt with his talk. If you've ever seen Dick's Identity 2.0 talk you'll know that this tutorial is going to be virtually un-bloggable...
Update: First pointer is to his own
Update: Paul is talking about exposing vulnerabilities in CGI code, and trying to emphasize that you must validate your input data, from users, from files and very much from the network. You need to use taint mode. He's also recommending that you don't use "baby taint" mode and call Perl with
Update: Interesting he's just shown a three line example that will allow you to get root access by running any Perl script that respects the
Update: But there are problems with taint mode
Update: One of the things that Perl is good for is making tasks easy. One of those things is opening a file. There are lots of ways to open files in Perl, which means there are lots of way to break things. If you are opening a file you should always specify a mode, and never use the two argument version of
Update: Symbolic links (are awesome but) can be used to do evil things. Don't use temporary files with predictable names, you could even use anonymous files
or you could just use the Tim's
Update: Now talking about
if
which is rather bad.
Back ticks are worse; "this" is a string, 'this' is a string and `this` is executing arbitrary code on your system. Depending on your font, it's rather hard to tell the difference.
The alternative is
Update: We're breaking for afternoon coffee...
Update: ...and we're back and talking about
Update: On to database security and injection attacks. He's advising us not to do our own quoting and use instead use place holders. As I've mentioned before, I rarely have to do heavy weight database work, and I'd view my knowledge of DBI as only fairly sparse, and even I know about place holders. Why does everyone think they're worth talking about at length. Bemusing!
Update: On to tricks and tips... and the poisoned null byte. Strings in Perl (are awesome but) can contain any character you want, including control codes and null bytes. In Perl a null byte is just another character, but in C it represents the end of a string. So if you can get a null byte down to the C layer, bad things can happen, and it's easy to pass a null byte can be easily passed in URLs.
Update: ...and we're done (with the main material) about an hour ahead of time. The course notes, although not the slides, for the tutorial are available online. On to the 'bonus' material, random numbers and cryptography...
Update: ...we're done. Now go read Brad's and Chris' posts on the Perl Security tutorial as well.
From the looks of things, Paul is trying to pull a Dick Hardt with his talk. If you've ever seen Dick's Identity 2.0 talk you'll know that this tutorial is going to be virtually un-bloggable...
Update: First pointer is to his own
autodie module, which was released onto CPAN (very) late last night. It's a lexical equivalent of Fatal for Perl 5.10, it also upgrades the Fatal module to contain better diagnostics and reporting.Update: Paul is talking about exposing vulnerabilities in CGI code, and trying to emphasize that you must validate your input data, from users, from files and very much from the network. You need to use taint mode. He's also recommending that you don't use "baby taint" mode and call Perl with
-t...You may not use data derived from outside your program to affect something else outside your program - at least, not by accident. - perlsec
Update: Interesting he's just shown a three line example that will allow you to get root access by running any Perl script that respects the
PERL5LIB environment variable.Update: But there are problems with taint mode
If the regular expression match formy ($url, $file) = @ARGV;
$url =~ m/ pattern match /;
my $safe_url - $1;
$file =~ / pattern match /;
my $safe_file = $1;
$safe_file fails then $safe_file is set to $safe_url and that could easily be set to something like http://foo&/bin/sh, which would be bad. You always need to check for success, either use an if( ) block or by explicitly check the return value from the regular expression.Update: One of the things that Perl is good for is making tasks easy. One of those things is opening a file. There are lots of ways to open files in Perl, which means there are lots of way to break things. If you are opening a file you should always specify a mode, and never use the two argument version of
open which does much deep magic. Use the three argument version instead.However this doesn't get you out of validating your input, you still need to do that...open($fh, "<", $filename );
Update: Symbolic links (are awesome but) can be used to do evil things. Don't use temporary files with predictable names, you could even use anonymous files
use autodie qw(open);
open($fh, "+>", undef );
or you could just use the Tim's
File::Temp module instead...Update: Now talking about
system and back ticks, Paul really hates system. You really need to use the two argument version of system rather than the one argument version, except of course@args = ();
system( $cmd, @args );
if
@args is empty, then it calls the one argument version of system, which in turn calls the shell rather than executes the passed command directly. Which means that you can this happens,system ( "finger $username; rm -rf *", ( ) );
which is rather bad.
Back ticks are worse; "this" is a string, 'this' is a string and `this` is executing arbitrary code on your system. Depending on your font, it's rather hard to tell the difference.
The alternative is
IPC::System::Simple, which works all the way back to Pelr 5.6 and (magically) doesn't have any dependencies. Which from the sounds of it goes a long way to fixing a lot of the problems with system. It also provides capture which replaces back ticks.Update: We're breaking for afternoon coffee...
Update: ...and we're back and talking about
setuid and setgid programs. Apparently Perl is ignorant of the saved uid, which means that it's really hard to drop privileges and make it stick. Also a dark secret, Perl's $< and $> variables are cached. Ouch!Update: On to database security and injection attacks. He's advising us not to do our own quoting and use instead use place holders. As I've mentioned before, I rarely have to do heavy weight database work, and I'd view my knowledge of DBI as only fairly sparse, and even I know about place holders. Why does everyone think they're worth talking about at length. Bemusing!
Update: On to tricks and tips... and the poisoned null byte. Strings in Perl (are awesome but) can contain any character you want, including control codes and null bytes. In Perl a null byte is just another character, but in C it represents the end of a string. So if you can get a null byte down to the C layer, bad things can happen, and it's easy to pass a null byte can be easily passed in URLs.
Update: ...and we're done (with the main material) about an hour ahead of time. The course notes, although not the slides, for the tutorial are available online. On to the 'bonus' material, random numbers and cryptography...
Update: ...we're done. Now go read Brad's and Chris' posts on the Perl Security tutorial as well.
Subscribe to:
Posts (Atom)