Climate Science Glossary

Term Lookup

Enter a term in the search box to find its definition.


Use the controls in the far right panel to increase or decrease the number of terms automatically displayed (or to completely turn that feature off).

Term Lookup


All IPCC definitions taken from Climate Change 2007: The Physical Science Basis. Working Group I Contribution to the Fourth Assessment Report of the Intergovernmental Panel on Climate Change, Annex I, Glossary, pp. 941-954. Cambridge University Press.

Home Arguments Software Resources Comments The Consensus Project Translations About Donate

Twitter Facebook YouTube Pinterest

RSS Posts RSS Comments Email Subscribe

Climate's changed before
It's the sun
It's not bad
There is no consensus
It's cooling
Models are unreliable
Temp record is unreliable
Animals and plants can adapt
It hasn't warmed since 1998
Antarctica is gaining ice
View All Arguments...

Keep me logged in
New? Register here
Forgot your password?

Latest Posts


Climate Hustle

A Hack By Any Other Name — Part 6

Posted on 18 March 2014 by Bob Lacatena

Part 5 explained how apache logs are structured, and explained some of the avenues the hacker used in his attack.




Ginger: For someone the NSA once listed as the most dangerous hacker in America, you sure don't look like much.
Swordfish (2001)

March 27, 2012 — 12:25 AM PST — Better Lucky than Good

How had the hacker deleted 12 hours of activity from the SQL injection log file from the 21s of February, the first day of the hack?

Doug hit on the right answer, at first for the wrong reason.  The corrupted SQL injection log file suggested that the hacker had uploaded something, probably an empty file, to overwrite that log file.  There seemed to be one way to do that through the application.  Authors have the ability to upload images, PDFs, and other supporting files.  It struck Doug that this was the most likely path to corrupting the log file.

This turned out to be not entirely true, because the upload program would not overwrite a file.  If the file already existed, it completed the upload request by adding a numeric suffix to the file name.  But the intuition was right.  A program that could put files into the system was dangerous, even if it was only available to authors and moderators.

Doug immediately asked that that capability be shut down.  The third security risk was now sealed.

But again, it didn’t explain how the hacker had gotten in, because one needed at least an author’s administrative capabilities to use the image upload facility.  And how did he get a dump of the database?


Lex:    This is a Unix system.  I know this.  It's the files for the whole park.  It's like a phone book - -it tells you everything.
I've got to find the right file.  Oh no, this isn't right. This might be right, no this isn't it.
Jurassic Park (1993)

March 27, 2012 — 2:03 PM PST — Root Kit

Thinking on it further, it became apparent that the image upload tool was also a third avenue into accessing the database.  In theory, someone could upload a program, a web page which when accessed would do whatever the uploader wanted it to do.  In this way he could initiate his own database dump, and grab the resulting file.  First, he’d need to get the database password, but in theory he could get that, too, from another uploaded program.

It’s designed to give the hacker access to every level of the system...

Such a program could loosely be called a “rootkit”.  It’s designed to give the hacker access to every level of the system, but without itself being discovered.

It took a while to find, but by 2:03 PM Doug found the part of the logs that pointed to the rootkit.  The hacker had clearly uploaded a program into our images directory, where a blog post’s uploaded images would be placed.  The first program was called temp.php, and had been uploaded by user ID 6304, with the username “dieter”.  Once that was done, we had an even better trace of what he’d done.  We had far more information — all of the repeated uses of the later temp3.php program — with which to connect the dots in his trail.  We had a whole lot more breadcrumbs to look at. - [21/Feb/2012:09:15:35 +1100] "GET /admin_moderate.php?Action=UploadImageForm HTTP/1.1" 200 5811 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.10.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 684 6184 urchindyn - [21/Feb/2012:09:16:41 +1100] "GET /admin_author.php?Action=UploadImageForm HTTP/1.1" 200 7518 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.11.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 680 7891 urchindyn - [21/Feb/2012:09:33:52 +1100] "POST /admin_moderate.php?Action=UploadImageResults HTTP/1.1" 200 5493 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.18.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 1079 5866 urchindyn - [21/Feb/2012:09:33:57 +1100] "GET /images/temp.php HTTP/1.1" 200 10758 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.19.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 683 10980 urchindyn

Unfortunately, the temp.php program, as well as his later and more important temp3.php, was gone.  Doug spent several hours looking through many incremental backups, trying to find some trace of it, hoping that a backup had picked it up while the hacker was still at work, but without luck.  He also spent time making sure that the system was clean of any wayward programs, or unexpected changes to programs.  He compared absolutely everything to old backups, to make sure that the hacker hadn’t left himself a backdoor for later use.

It’s what let the hacker easily find and view the site’s source code, and also to find the SQL injection logs.

The rootkit itself was easy to find on the Internet, however, using the parameters it employed as a signature.  It was nothing more than an open source program for navigating a file system and using the shell commands via the web.  It was very easy to use, and conveniently came with translations in English, Portuguese, Spanish, French, Dutch, Italian, Turkish… and German.  It’s what let the hacker easily find and view the site’s source code, and also to find the SQL injection logs.

It still didn’t explain how he’d gotten author’s capabilities on an ID that he had just created, but now we were able to trace his entire path.  It took a while, with some tricky use of grep and other tools, but bit by bit we built an image of what he’d done, step by step.  We found where he registered the dieter username, where he gave it super administrative capabilities using the now defunct table maintenance program, where he navigated the directory structure to find and download the SQL injection file, and even where he created his own dump of the database, compressed it, and downloaded it.

But the room was still locked.  How did he get in?  He used John’s ID and its special administration capabilities to give his own dieter ID those same powers, which let him do everything.  But how did he get access to John’s ID?  Again, he discovered and downloaded the SQL injection file only after he was already in the system, so that wasn’t how he got John’s credentials.  I even checked, just to be sure.  John’s credentials weren’t even in the log file from February 21st.  In fact, his login credentials weren’t in any SQL injection log file between February 15th and February 25th.

So how did the hacker get them?  Until we knew that, even with all of the other security holes closed, everything was at risk.


Gary Winston: You're either a one or a zero. Alive or dead.
Antitrust (2001)

The Next to Last Answer

The answer to the hacker’s entry was so obvious, that it was hard to see.  Very early in his session on the 21st, his ID simply changed from 6304 (dieter) to 1 (John Cook).  It looked almost as if he’d simply logged out, and logged back in as John.  After that, the very next thing that he did was to use the super admin panel to look at John’s ID in detail, in the database.

The answer lies in the fact that the value we were seeing was a cookie, which was supposed to be reflective of the session’s user ID, but not control it.  The actual user ID associated with the session was stored on the server, keyed by the session ID.  When you submitted a request, the server would look up your session, get your user ID (if you were logged on) from there, and that would govern your capabilities.

What was odd, however, was that between the change from user ID 6304 to user ID 1, the hacker’s session cookie vanished.  It was clear, from this, that he had manually edited his cookies, deleting his session ID and changing his user ID to 1.  Looking back through the logs, he’d tried the same thing a few minutes earlier, without any luck, because he hadn’t deleted his session cookie. - [21/Feb/2012:07:49:01 +1100] "GET /profile.php?a=updateprofileform HTTP/1.1" 200 21118 "-" "-" "PHPSESSID=bfa907024e1f028377f57159b9e9ed13; UserId=6304" 173 21446 urchindyn - [21/Feb/2012:07:49:55 +1100] "GET /profile.php?a=updateprofileform HTTP/1.1" 200 21118 "-" "-" "PHPSESSID=bfa907024e1f028377f57159b9e9ed13; UserId=1" 175 21446 urchindyn - [21/Feb/2012:07:55:48 +1100] "GET /profile.php?a=updateprofileform HTTP/1.1" 200 5438 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=bfa907024e1f028377f57159b9e9ed13; __utma=198451757.559981952.1329767596.1329767596.1329767596.1; __utmb=198451757.8.10.1329767596; __utmc=198451757; __utmz=198451757.1329767596.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 612 5811 urchindyn - [21/Feb/2012:07:58:36 +1100] "GET / HTTP/1.1" 200 69774 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "UserId=1" 172 70206 urchindyn

Most people don’t realize that cookies can be edited, but web developers — and hackers — do it all the time.  A quick check of the code confirmed my fears.  In the earliest days of the site, long before there was functionality worth hacking or an obvious desire on the part of the pseudo-skeptics to do so, John had added an insecure “automatic-login” functionality which saved your user ID as a cookie.  If you weren’t otherwise logged on, it unguardedly accepted the user ID in your cookie. 

Using this, the hacker could simply edit his cookies and become any user he wished.

A properly secured implementation should have done three things differently.  First, the cookie’s name should have been obfuscated into something meaningless, to hide its functionality.  Second, the value itself should at least have been encrypted, or better yet replaced with a random token which was in turn used as a key to a database table that would contain the actual user ID, along with the user agent and an expiration date (to narrow its acceptable application).  Third, the functionality should have been negated for administrative users.  Such users should have been required to log in, providing full credentials, no matter what.

To make any use of a more secure implementation, a hacker would have had to guess at the functionality of the cookie (impossible), guess at and encrypt an existing, valid token value (impossible), use the exact same computer type and browser that went with the token (impossible) before the token expired — and even then, it would only let him sign on as someone else, but not someone with powerful capabilities.

Unfortunately, John’s implementation was far too simplistic.  Of course, he had also implemented it all the way back in 2007, when the site first began and all that a visitor could do was to post a comment.  It’s no wonder that such functionality, among other things, was not revisited and tightened up as the site literally began to explode with new functionality.

What did he do in those 24 minutes that gave him that answer?

Using this, the hacker could simply edit his cookies and become any user he wished.  This seemed to be the last piece of the hack puzzle… with one small exception.  Immediately after looking at John’s ID, he vanished for 24 minutes.  When he returned, he switched his ID to 4955.  That particular ID was a test ID, created and abandoned long ago, by John, to test code changes.

He used the 4955 ID to give administrative capabilities to his own 6304 dieter user ID, and then used that deiter 6304 ID for the rest of the day’s session.

But nowhere in his brief, initial intrusion had he yet done anything that would show him the 4955 user ID.  It’s probably reasonable to assume that he guessed at John’s ID being number 1.  Probably 97% of all developers have created the very first user ID in a system as their own, and given it administrative capabilities.  So guessing at user ID 1 for John was a fairly easy thing to do.

But how in the world did he know to use ID 4955, without doing anything else first?  What did he do in those 24 minutes that gave him that answer?


Robert Clayton Dean: Conspiracy theorists of the world unite.
Brill: It's more than a theory with me. I'm a former conspirer.
Enemy of the State (1998)

February 21, 2012 — 6:52 AM AEDT — Day 1

Author's Note: Many marginally relevant, intervening log entries have been omitted, to keep their presentation as clear and concise as possible.  Similarly, many irrelevant cookies, which only confuse the presentation, have also been eliminated.

At 6:52 AM AEDT, 8:52 PM CET, The German visited the site. He waited almost thirty minutes before registering a user named “dieter”. - [21/Feb/2012:06:52:41 +1100] "GET / HTTP/1.1" 200 20318 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "-" 322 20756 urchindyn - [21/Feb/2012:07:21:34 +1100] "GET /register.php HTTP/1.1" 200 5703 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=bfa907024e1f028377f57159b9e9ed13; __utma=198451757.559981952.1329767596.1329767596.1329767596.1; __utmb=198451757.1.10.1329767596; __utmc=198451757; __utmz=198451757.1329767596.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)" 622 6076 urchindyn - [21/Feb/2012:07:24:01 +1100] "POST /register.php HTTP/1.1" 200 5445 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=bfa907024e1f028377f57159b9e9ed13; __utma=198451757.559981952.1329767596.1329767596.1329767596.1; __utmb=198451757.2.10.1329767596; __utmc=198451757; __utmz=198451757.1329767596.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)" 855 5818 urchindyn - [21/Feb/2012:07:24:56 +1100] "GET /confirm.php?u=6304 HTTP/1.1" 200 5407 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=bfa907024e1f028377f57159b9e9ed13; __utma=198451757.559981952.1329767596.1329767596.1329767596.1; __utmb=198451757.3.10.1329767596; __utmc=198451757; __utmz=198451757.1329767596.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)" 585 5780 urchindyn - [21/Feb/2012:07:25:34 +1100] "POST /confirm.php?u=6304 HTTP/1.1" 200 5258 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=bfa907024e1f028377f57159b9e9ed13; __utma=198451757.559981952.1329767596.1329767596.1329767596.1; __utmb=198451757.4.10.1329767596; __utmc=198451757; __utmz=198451757.1329767596.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)" 793 5695 urchindyn

He checked the “Keep me logged in” checkbox, then looked at the resulting cookies.  He visited his profile, where he immediately tried to edit his own User ID cookie, changing it from 6304 to John’s 1, but without success.  He tried several variations before deleting all of his cookies except for the User ID cookie, still set to 1.  That worked.  With the next page display, he saw a menu of options beneath the login window which reflected John’s expanded capabilities.

He went straight into the Admin menu option, and from there was delighted to find a list of all of the database tables.  He went straight to the User’s table, where he then conducted a search for John’s user ID, to discover how to give his own dieter ID those same capabilities.  For twenty four minutes he was silent.  When he returned, perhaps worried that any update activity might be logged and noticed, he switched his user ID to 4955, a test user he'd found with the same capabilities as John’s.   He then pulled up his own dieter ID in the users admin page.  He waited (or pondered for) 18 minutes before updating his own dieter ID to match John’s.  User ID 6304 now had every capability that John had. - [21/Feb/2012:08:24:33 +1100] "GET /sksadmin.php?Action=EditForm&TableName=user&Search=&UniqueIdentifier=1 HTTP/1.1" 200 29103 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "UserId=1" 242 29503 urchindyn - [21/Feb/2012:08:48:46 +1100] "GET /sksadmin.php?Action=ViewAll&TableName=user HTTP/1.1" 200 49095 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "UserId=4955" 217 49511 urchindyn - [21/Feb/2012:08:54:28 +1100] "GET /sksadmin.php?Action=EditForm&TableName=user&Search=&UniqueIdentifier=6304 HTTP/1.1" 200 28707 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "UserId=4955" 249 29107 urchindyn - [21/Feb/2012:09:12:13 +1100] "POST /sksadmin.php?Action=Edit&UniqueIdentifier=6304&TableName=user&Search= HTTP/1.1" 200 21359 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "UserId=4955" 636 21752 urchindyn

From there he logged in as dieter, but unchecked the “Keep me logged in” box, eliminating his User ID cookie from the remainder of the apache log trail.  For the rest of the day, he’d use his newly empowered dieter ID.

He tried each of the newly available administrative links in turn, but went no further than looking at what each appeared to offer.  Then he tried a few of the options within the super admin panel.

When he came across the moderator and author pages for uploading images, he hesitated. First he investigated the graphics database table. - [21/Feb/2012:09:15:35 +1100] "GET /admin_moderate.php?Action=UploadImageForm HTTP/1.1" 200 5811 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.10.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 684 6184 urchindyn - [21/Feb/2012:09:16:41 +1100] "GET /admin_author.php?Action=UploadImageForm HTTP/1.1" 200 7518 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.11.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 680 7891 urchindyn - [21/Feb/2012:09:18:58 +1100] "GET /sksadmin.php?Action=ViewAll&TableName=graphic HTTP/1.1" 200 9024 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.13.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 682 9397 urchindyn

Eventually he wandered into the forum reading five threads under the Moderation topic, at first distracted from his mission of investigating the image upload process:

  • Goodbye
  • Judith Curry
  • being “outed”
  • Adam & Camburn

He read four more under Technical Stuff:

  • Removing SkS From the Wayback Machine
  • Something strange happened
  • Images not uploading now; anyone else having issues?
  • File Upload Functionality
10 Feb 2011, 6:14 AM File Upload Functionality

Could the file upload functionality be enhanced to give us the option to actually override an already existing file? This would have two advantages:

    1.    it would lessen the load on the server especially as some files can be fairly large (some graphics or eg. ppt-files)
    2.    updates to already existing posts referencing a specific file wouldn't always need to be updated

Or - but I guess this would require more programming - during the file-upload the already existing file could first be copied to another name (perhaps using the current numbering logic?) and in a second step the file gets uploaded but the original name can be reused.

It would also be neat if we could actually search for the files via a kind of directory listing to see what is already there.

And, on another note: could it make sense to have separate directories for pictures and other file-types?


That last, even though he’d already seen and visited the page in question, made him realize, or at least feel more secure in, what he could do with it.  Perhaps it was Bärbel’s suggestion of separating pictures from “other file-types”.  At 11:33 PM, using the moderation image upload page, The German uploaded one file, a test program named temp.php.  He ran it.  When that worked he uploaded two more, temp2.php and temp3.php. - [21/Feb/2012:09:29:39 +1100] "GET /thread.php?t=866&r=0 HTTP/1.1" 200 4463 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.18.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 687 4836 urchindyn - [21/Feb/2012:09:33:52 +1100] "POST /admin_moderate.php?Action=UploadImageResults HTTP/1.1" 200 5493 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.18.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 1079 5866 urchindyn - [21/Feb/2012:09:33:57 +1100] "GET /images/temp.php HTTP/1.1" 200 10758 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.19.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304" 683 10980 urchindyn

He tried running the temp2.php program, designed to access the database, several times, but he lacked the database user ID and password, which are distinct and separate from visitor user IDs.

The third program, temp3.php, was his “rootkit.”  With it, he began to explore the system.  He started with an "id" command, to discover the operating system level user (which is distinct and separate from both visitor user IDs and the database user ID) that was running his temp3 program.  That ID would determine what the temp3.php program's capabilities might be.

He navigated his way through the website's file system, looking first at directories.  At 12:07 PM he found the logs directory and downloaded his very first SQL injection log.  Then he began to navigate up the tree, out of the publicly visible area.  He could do this, with his uploaded program, because that particular web host allowed it.

At 12:17 PM, he found an old database backup file, from July of 2011, one that had never been properly removed, probably due to a script failure.  It couldn't be either seen or accessed via the web, but it could using his temp3.php program.  He downloaded it. - [21/Feb/2012:10:17:54 +1100] "GET /images/temp3.php?action=3&dir_atual=/home/7-web/74/95/ HTTP/1.1" 200 37695045 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmb=198451757.25.10.1329774687; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=1A;" 1208 37695463 urchindyn

He looked at a few log file fragments.  Starting at 12:22 PM, for the next 27 minutes, he looked at the actual programs that run Skeptical Science, including the one that gave him the database user and password.  At 12:57 he used his temp3.php program to edit his temp2.php program. - [21/Feb/2012:10:57:32 +1100] "GET /images/temp3.php?action=7&dir_atual=/home/7-web/74/95/ HTTP/1.1" 200 1215 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=1A;" 1084 1552 urchindyn

 He modified it, inserting the newly found database user and password. He ran it, then uploaded and ran two more programs, - [21/Feb/2012:11:01:31 +1100] "POST /images/temp3.php HTTP/1.1" 200 1052 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=1A; fm_root_atual=/home/7-web/74/95/" 3871 1389 urchindyn - [21/Feb/2012:11:01:51 +1100] "GET /images/b.php HTTP/1.1" 200 185 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=1A;" 934 405 urchindyn - [21/Feb/2012:11:04:23 +1100] "POST /images/temp3.php HTTP/1.1" 200 1051 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=1A;" 3909 1388 urchindyn - [21/Feb/2012:11:04:46 +1100] "GET /images/c.php HTTP/1.1" 200 21 "-" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=1A;" 934 240 urchindyn

When he was finally finished with that task, at 1:12 AM, he downloaded a compressed copy of the database and then immediately deleted it. - [21/Feb/2012:11:12:22 +1100] "GET /images/temp3.php?action=3&dir_atual=/home/7-web/74/95/ HTTP/1.1" 200 71744926 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=6D;" 1151 71745316 urchindyn - [21/Feb/2012:11:12:51 +1100] "POST /images/temp3.php HTTP/1.1" 200 83745 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329774687.1; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=6D;" 1400 84149 urchindyn

The German poked around for a while, exploring some more and cleaning up any files he'd left behind.  At 2:07 AM (12:07 PM, AEDT) he truncated first the day's SQL injection log file.  Then he left for two hours. - [21/Feb/2012:12:07:29 +1100] "POST /images/temp3.php HTTP/1.1" 200 5534 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "sel_dir_warn=true; PHPSESSID=dc2cbe0b2abcf0f069b234019197c8ca; __utma=198451757.686892950.1329774687.1329774687.1329784321.2; __utmc=198451757; __utmz=198451757.1329774687.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); UserId=6304;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=6D;" 1354 5871 urchindyn

Two hours later, he apparently realized that he'd failed to clean up his temp3.php program.  At 4:11 AM, nearly seven and a half hours after he'd begun, The German deleted his temp3.php program, and quit until February 23rd. - [21/Feb/2012:14:11:43 +1100] "GET /images/temp3.php?frame=3&action=8&cmd_arg=temp3.php&dir_atual=/home/7-web/74/95/ HTTP/1.1" 200 93468 "" "Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0" "PHPSESSID=c801ac4b76de22a05d5f1196224c0033; __utma=198451757.187278331.1329793825.1329793825.1329793825.1; __utmb=198451757.1.10.1329793825; __utmc=198451757; __utmz=198451757.1329793825.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);;; loggedon=d41d8cd98f00b204e9800998ecf8427e; order_dir_list_by=1A" 983 93872 urchindyn


Jack: Computers are your life, aren't they?
Angela: Yes. The perfect hiding place.
The Net (1995)


The hacker left behind a number of riddles, each of which had to be solved in turn.  How did he get the SQL injection log files?  He went straight to them, knowing exactly where to look, without fumbling or probing.  How did he know where to look, and download the database, and truncate the log file from February 21st?  He’d uploaded his own programs to do all three things.  How had he acquired the capabilities needed to abuse the image upload facility to install his own programs?  He used the re-login cookie trick.

Part 7 concludes by answering those questions that have answers.

And how had he gotten the uwatest 4955 user ID?  We still didn’t know.  Things still didn’t fit.

To be concluded...

0 0

Bookmark and Share Printable Version  |  Link to this page


Comments 1 to 6:

  1. This is a great thread, but it does make me feel a bit paranoid everytime one of my favorite climate sites is down, as Climate Progress seems to be right now for me. Is anyone else having this problem.

    OT (but is anything climate related really off topic?): The current official daily numbers at Mauna Loa now work out to the first 7-day period of above 400 ppm this year, by my calculations (but please do recheck my maths, someone).

    0 0
  2. I got 505 errors from Climate Progress from earlier on today here in the UK, it is now back but content that was posted recently, one on the Paris smog and another on fracking related quakes in Ohio state, has gone AWOL it does seem like they are having problems.

    0 0
  3. I still don't get anything.

    0 0
  4. will:

    Check out: CO2 on Path to Cross 400 ppm Threshold for a Month by Brian Kahn, Climate Central, Mar 18, 2014

    0 0
  5. Forgive me for asking a foolish question but is there any danger, from all this, to our PCs?

    0 0
  6. @#5 villabolo

    No worries.

    If you think someone might have the desire to retrieve files from your PC, the best security is to turn it off or disconnect it from the internet when it is not being used.  Also you need to provide good physical security so no one picks it up and walks off with it.

    Sometimes servers are easier to break into than PCs simply because they are providing data to the public 24 hours a day 7 days a week; this allows a hacker far more opportunity.

    0 0

You need to be logged in to post a comment. Login via the left margin or if you're new, register here.

The Consensus Project Website


(free to republish)

Smartphone Apps


© Copyright 2018 John Cook
Home | Links | Translations | About Us | Contact Us