As part of my day to day work, I deal with a wide range of technologies. Recently, a client asked me to help out with adding some affiliate links in to their site. Easy, huh? Well, it's a bit of a pain to be frank. The site runs on a Joomla framework, which means it's incredibly easy to configure - if you've never used Joomla before, I'd suggest popping over to their site and having a look.

So, getting your content laid out as you want it is easy enough. However, when it comes to adding scripts, all bets are off! Even though it's now 2008, the default WYSIWYG editor tinyMCE has no facility for adding in scripted content - you have to go all the way in to the site global preferences and turn the editor off, add your scripts, then go and turn it back on. God help you if you then edit that content and forget to turn it off again - make sure you have backups!

So Joomla guys, if you read this, can we please have a default WYSIWYG editor that at least has the option to insert scripts? Please!

If you've done any sort of network management, you'll know that most will be targeted at some point. Have a think - how much sensitive data do you hold on your desktops and servers? What would happen if that data made the public domain? More importantly, who would get the blame?

The best way to protect your network is to try to break in to it before someone else does. Penetration testing is the acceptable face of hacking - by looking at your network as a hacker would, you can identify weak spots and close the holes that you find. The down side is that to get it done by a professional is extremely expensive. This is where BackTrack comes in.

This live CD is based on the Slackware distro, and is optimised for penetration testing.

The CD runs the KDE windowing package, and contains all the tools you'll need for attacking your network. The CD its self cam about from the joining of forces of the Whax and Auditor Security Collection teams, and is aligned with all of the major testing and best practise frameworks.

The CD currently boasts over 300 tools - if you can't find what you're looking for here, you'll probably have to write it yourself!

Please pay these guys a visit - it's not a promotional link, just one that'll make your life a hell of a lot easier. www.remote-exploit.org

As you'll probably know, vbScript has no defined data types - they're all interpreted as required. Sometimes 12.3 may be a number, sometimes it's a string. This is all well and good, but what happens when you try to pass variables from vbScript into a more structured environment?

At the moment, I am currently writing a web front end to sit over some archived financial data. The brief is fairly simple - the back end database is to be read only, and should be searchable by invoice amount, customer name, customer reference, and postcode. All fairly simple. As it's going to be used only sparsely, I've decided to go with URL variables. The web front end will be accessible to certain people via directory security, so there is no need to obfuscate the data.

So, we create the ODBC link, put together a front end page for the users, then pass the variables via the URL to the backend processing page. Here, the URL variables are used to create a dynamic SQL SELECT statement like this:

strSQL = "select gl_account, gl_amount, gl_batch_ref, gl_date, gl_description, gl_contra, gl_ref, gl_sub_ledger, gl_year from dbo.gl_transactions where gl_amount = " & amount2 & " order by gl_contra ASC"

So we then pass this to SQL Server, and this happens...

Problem - as you can see from the error message, SQL is treating the variable as a string and using this to do a select against a numeric field... Result - dead app!

So, how do we get SQL to recognise this as a number?

The first thing to try is CAST. This is an in-built SQL function that is used to transform variables from one type to another. So, we rewrite the query like this:

strSQL = "select gl_account, gl_amount, gl_batch_ref, gl_date, gl_description, gl_contra, gl_ref, gl_sub_ledger, gl_year from dbo.gl_transactions where gl_amount = cast(" & amount2 & " as decimal) order by gl_contra Asc"

You would think that converting the variable to a decimal would solve the problem. Well, you're wrong. If you have a look at this page (beware - it's huge, and will open in a new window) - Cast as Decimal, you'll see that the constrained column, gl_amount, contains hundreds of different values, not just the one we passed, which in this case was 18.69. If you look closer, you'll see that all of the values are in the range 18.50 to 19.49. It appears that even though you've specified a decimal, it's rounded it to the nearest integer, 19. Therefore, again, SQL is technically correct, as all of the values in the gl_amount column will round to 19...

We need to get more accurate. Fortunately, SQL includes a couple of useful data types. We could use float, but this would give us far more precision than we need. Instead, we'll use money. This'll give us the precision we need, without eating up too many resources. Have a look at this page Cast as Money for the results.

Hopefully you should now see why it's important to keep track of your variables, and wherever possible to declare them explicitly - it'll save you a lot of headaches in the long term!

I recently purchased a Sandisk Cruzer 4GB memory stick. Well, I say 4GB, but it was actually closer to 3GB once all the pre-installed crap was taken in to consideration.

As you may be aware from my previous posts, I'm a bit of a security freak, and in my opinion, U3 is a disaster waiting to happen. Anything that automatically runs software on your PC is a security threat, and given the amount of support for U3, the threat is massively multiplied. I have enough problems with students bringing in disallowed software on USB keys without SanDisk giving them a suite of tools that make cracking my security much easier.

You may be aware of the guys and gals at Hak5. If you're not, they've made some interesting and frankly frightening advances in U3 hacking. One of their tools is the USB Switchblade. This quote, taken from the site, should tell you all you need to know:

"The goal of the USB Switchblade is to silently recover information from a target Windows 2000 or higher computer, including password hashes, LSA secrets, IP information, etc..."

How do you feel about your shiny new USB technology now Sandisk?

Another of their tools is the USB Hacksaw, which performs a similar service to the Switchblade. Take a look at the video below for a lot more info.

By now, as a sysadmin, you should be fuming. This technology may look pretty, but in my opinion it's dangerous fluff that should be wiped out as soon as it's found. To this end, I've included a link to the U3 Removal Tool. Click the link, download, insert your U3 memory stick and run the tool. It'll remove the U3 component and you'll have a nice, normal memory stick.

Apologies if I sound a bit rabid over this, but that's because I am! This software serves no decent use and should be eradicated on sight...

Rant over :-)

As you probably know, I hate anonymous proxies... They ruin my network security, and little 17 year old snots use them to compare themselves to Ghandi. So, here is my easy guide to closing them down. Of course, 10 will take their place, but at least you get the thrill of doing something...

1) Get an IP address - ping the site, simple as that.
2) See who shares that IP address (nearly all proxies are on shared IP's).
3) Contact the abuse or postmaster addresses at each site and inform them that they're likely to be blacklisted by filtering software.
4) With a little digging, you can also find the hosting company - try www.domaintools.com. Contact their abuse address and report them - most legitimate hosting companies will have clauses in their T&C's about proxy scripts.
5) Watch the site get taken offline. Possibly stop to admire your work, and reply to the email you got from a webmaster who simply stated, "Try and stop me!"