I thought I would make a quick mention of a web page I came across that introduces really useful third-party Firefox plugins which a person such as myself who gets involved in hanky-panky from time to time can make really good use of. I know I have relied on Firebug on far too many occasions to mention to slice and dice and hack away at the source of live web pages, and on Live HTTP headers slightly less so for inspecting the crud that goes back and forth under the hood while browsing. But the page lists other more tempting plugins that could make your life a lot easier if you swing that way. :)
OK, this is a bigger problem than it may sound or look. If you are one of those many who do not use a secure (encrypted) session (SSL, that is) to not only authenticate to but read and write your emails on Gmail, you are in trouble. At the time of writing, I suspect Mike Perry, a security researcher and reverse engineer who has been complaining about cookie hijacking and SSL sessions over at defcon.org and elsewhere, may have already released a tool to the public at large that will make taking over anyone’s unencrypted Gmail session as easy as stealing a candy from a baby — maybe even easier.
On the upside, on the bottom of the settings page of your Gmail account, Gmail folks have made it possible for users to switch Gmail to always use a secure session (which is commonly known in geek circles as “over HTTPS”). If you have not done that, definitely waste no time and get on and over with.
If you are one of those who log into their Gmail account in the morning, and keep logged in throughout the day, it would be less convenient but well worth it, if you have not already turned off the ‘always use https’ setting on Gmail, to access the Gmail page by manually typing the following address: https://mail.google.com/ Before Gmail got around to realising how big a problem this all is, using the manual link I have mentioned was, I believe (but I may just be wrong), the only way to keep your entire Gmail session encrypted. Otherwise, before, Gmail would only use an encrypted session during authentication (which is common and until now was sufficient in terms of providing reasonable security), and settle back to a normal, non-encrypted session for the rest of the email reading/writing operations (which, simply, means that anyone sniffing your network, while not in a position to make heads nor tales of what went on when you logged into your Gmail, could easily read all your emails). This was of course done to cater to the users at large that have a slow Internet connection, because clearly having an SSL or encrypted session poses a burden on Internet bandwidth.
However, now, we do have a big problem, and it is worse than someone eavesdropping on your emails. It is all too technical to explain, but, let’s just say (and I am being way way over-simplistic with this), anyone with malicious intent or coming off a bad day can fool your non-encrypted Gmail session into sending them all the information they need to take over your Gmail account. If that doesn’t scare you, hats off to you.
As a general rule, whenever authenticating to any website, please always, always try to use the secure authentication mechanism provided by the website (almost all sane websites that require any sort of authentication provide it). Most security-conscious websites will go one step further and automatically switch your session to an encrypted one. The easiest way to spot that is to look at the address bar and ensure that instead of “http://”, you have “https://” (note the ‘s’ there). Additionally, browsers also display a coloured lock icon somewhere on the status bar indicating that the session is encrypted. If a website is not courteous enough to automatically do that, chances are good that it may provide a link to the effect of ‘use secure login’ that will take you over a secure channel for you to safely authenticate with the website. If it does not, well, that is just too bad.
Have fun, and be safe.
Woah. This zapped in like lightening.
iDefense is putting up the biggest bounty ever for individuals to detect critical holes in as many as six different major software systems that form the backbone of the Internet’s infrastructure. There are six bounties of $16’000 each for any remote hole detected in latest stable versions of the following applications: Apache, BIND, Sendmail, OpenSSH, IIS, MS Exchange.
The few security researchers referenced in the article express their doubt that there will be any submissions, stating that all of the six applications listed are really really difficult to have remote holes in them and that the amount offered is just not worth the time and expertise that would need to be expended on finding holes. I am pretty excited, nonetheless. Yes, the odds of anyone finding a critical remote bug in any of these is substantially low, and that each one of these applications has gone through a long history of major bug fixes and has matured over the years like no other application, they are still pieces of software and prone to bugs.
Those of you who write proof of concept exploit code in Python might have run into trouble trying to interpolate some hex value in between NOP sleds in Python. Consider the following code as an example:
code = "%X" % (130 + length(var), )
shellcode = '\x00\x00\x00\x00' + '\x%s' + '\x00\x00' % (code, )
Python won’t let you do that. It will spit back an “invalid \x escape” error and die. A friend today ran into a similar problem. I tried a couple of variations of %s and %X but to no avail. I then did what I do when I am stumped over a problem: went over to #python on irc.freenode.net to seek advice. A kind soul pointed out the solution.
shellcode = '\x00\x00' + ('\\x' + code).decode('string_escape') + '\x00\x00'
Backdoor PHP shells are receiving a lot of attention from script kiddies. Unless you know what PHP backdoor shells do, they provide a web-based interface to execute shell commands on systems on which they have been maliciously setup.
A friend once asked me to write him a script to upload files from a server via the PHP shell interface to some anonymous FTP server. I wrote the following minimalist Perl script.
my $host = '';
my $port = 21;
my $user = '';
my $pass = '';
my $file = shift || die "usage: $0 file";
my $ftp = Net::FTP->new($host) or die "failed.$!";
I am making it available here for I don’t know what reason.
If you need an all-in-one great penetration testing kit, look at Backtrack. If you need a test bed to try out your penetration testing skills, look at Damn Vulnerable Linux. Yes. There actually is something with that snazzy name. It is a small Linux distribution, based on Damn Small Linux, which provides a vulnerable platform for beginning and intermediate security peeps to try their acquired knowledge and skills on.
The following article on Linux.com briefly introduces Damn Vulnerable Linux. Thanks to BBBart for pointing it out.