Mechanical

Web Site Hacking Made Easy

You know, I really, really get annoyed at developers who don't even have a basic knowledge of security yet make their applications available to everyone. "Available to everyone" frequently means "web pages".

If you've ever heard of SQL injection, you know that any URL which allows its data to be injected directly into an SQL query is a security hole waiting to be exploited. So consider the basic structure of an SQL SELECT statement:

SELECT [something] FROM [table or tables] WHERE [some condition]

So any URL which has that basic structure potentially has a massive security hole allowing you to search their database and possibly cause plenty of damage. So how would you find those URLs? Enter Google Hacking. Google allows you to add a inurl: term to your query. Whatever you include with that term should be included in the URL. So what you're looking for is any URL which has select, from and where (the %3A is the encoding for a colon ':' character):

inurl:select inurl:from inurl:where

Now as it turns out, that returns a lot of questions about SQL queries in addition to URLs which execute queries. So to make it easier to find our target, let's look for anything which embeds 'cgi' in their URL:

inurl:cgi inurl:select inurl:from inurl:where

Bingo. Lots and lots of hackable Web sites. These people keep me employed.

Update: while playing around with this, I stumbled across the following URL (deliberately not made clickable):

http://140.127.211.214/cgi-bin/nlrdf_publ/update.pl?sql=UPDATE%20language%20set%20valid_from=**********%20where%20id=246

Inspired by the latest horror at the Daily WTF

  • Current Mood: depressed depressed
  • Current Music: Nitzer Ebb | Belief
Keeps you in a job and keeps me busy telling idiots why its bad to install script X on their site for above reasons :(
is it really a good job?
when you have to clean up messes like this? chances are, the people you replace have been telling management that the whole internet is like that, and you have to spend years fighting every dumb decision to exhaustion.

like having all of your machines out on the internet without patches and without firewalls.

and running everything obfuscated, because hackers can't figure it out.

or running everything as administrator or root, because that's the way operating systems are designed to work.

yup. no thanks.

I started working a developer but in the last 9 years have been working as an infosec engineer. You think that's bad? I find that most application developers are equally as clueless about security. Part of my job now and then is code audits and I'd say at least 75% of the time (at this and other jobs) developers are still not accounting for even basic things like buffer overflows. Not only for internal code and tools but code to be sent to clients or software the public will be buying/using. :-/
I'm not surprised...

PArticularly when I think about the 'applications' that such idiots have coded for my organisation through the years, and also the vegetables that approved them as fit for use...

One app died when we went from Winnt4.0 to XP...
The reason why?
It needed to have a .ini file in C:\Winnt\ and yes, the path was hardcoded...

A 'networked, multi-user' database was just access and VB.
Worked reaaaaaally well on our WAN which used 'Frame Delay' back then...
But it made very pretty reports...
Which the real users had absolutely no use for at all.
They went back to using old Lotus 123(for DOS) spreadsheets, because while that was awkward and slow, it at least worked...

Not that these kinds of bloopers only happens with 'custom' software, either.
A while ago we returned half a dozen A3 flatbed scanners as 'unfit for purpose' because the software insisted on toring temporary files in C:\program files\company\app\temporary.
(Our PCs are set up as reccommended, with users not having admin rights)

We got a standalone DVD-burner with 25 DVD magazine and built-in inkjet printer recently...
It may also end up being returned because it won't work unless the logged-in user has admin rights.
('Runas' doesn't seem to work)
A 'networked, multi-user' database was just access and VB.
Worked reaaaaaally well on our WAN which used 'Frame Delay' back then...


Hahahaha!! And I thought I was the only one who'd experienced that.