I’m supposed to go exercise. And someone sent me the google cache address. Dang you to heck!!!
Part VI.
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.
No shit, Sherlock.
Doug immediately asked that that capability be shut down. The third security risk was now sealed.
Three: count them three.
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.
No shit, Sherlock. (This is so well know that one can installd a Timthumb Vulnerability Scanner. It’s been around since at least 2011.) Anyway, this would be the 4th security hole associated with the ‘leak/hack’.
Turns out someone did upload a file. It was called either “temp.php” or “temp3.php”.
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.
Well… yeah. That’s because the TimThumb vulnerability was well know, had been around for some time, and script kiddies were sharing scripts.
It’s what let the hacker easily find and view the site’s source code, and also to find the SQL injection logs.
But how did he get access to John’s ID? […]
So how did the hacker get them? Until we knew that, even with all of the other security holes closed, everything was at risk.
How about this: He read them in an email John Cook sent to himself at the university? Of John has a stupid one like “password” and he guessed? Or it turns out John stored it in clear text in a “super-secret obscure directory” and someone ran across it? Or… Oh. It goes on and on you can read. * (DGH told me to be clearer here.
And the guy’s name is now “dieter”. And SkS tells us how “dieter” tricked the SkS system into giving him escallated privileges: He edited his cookie to tell the server he was John Cooke. Well, sort of: his cookie told the server he was user #1. Which is how the SkS system recognizes “John Cook” or “the guy will all the admin privileges”.
But evidently there is more: I guess well have to wait until someone find part VII in cache.
hang on.
How’d somebody get this? Is this a hack? Is this ANOTHER HACK!?!
:p
Lessons on how to build a website…
https://web.archive.org/web/20020607193622/http://www.sev.com.au/webzone/
Mark Bofill,
“Deep Link” told he how he found it and… no… it was not a hack. 🙂
FWIW: Google found it first.
DGH,
Doesn’t say anything about security.
The hackers probably deleted that chapter.
I haven’t had a chance to read the two posts yet, but something jumped out at me in part V when I was skimming:
It’s annoying Lacatena doesn’t believe the hacker did this, yet he tells us the “only two ways a hacker” could do it. This series is already ridiculously long as it is. I don’t get why he’d pad it more.
More importantly, this makes Lacatena sound like a moron to me. He says there are only two ways someone could gain those credentials. I doubt anyone here would be surprised if I could name half a dozen other ways.
At the very least, I don’t get how anyone could fail to note the, “Looked over Cook’s shoulder” method.
I had the same reaction to that bit.
I’m mystified why he thinks those would be the only two ways it could be done. How
By the way, I’m not very interested in these latest two posts. These new posts have some actual information, which is nice, but fifteen thousand words for what could have been said in five is obnoxious. I’ll probably read these posts and try to answer questions that come up about them, but I don’t expect to do much more. We now know they were hacked. Aside from that, the stupidity of their security speaks for itself.
If I’m going to spend time responding to anything, it’ll probably be this recent post of theirs. I’d argue it is far dumber, and it is certainly more offensive (even heavily implying global warming killed 400 people in a specific heat wave).
Actually, I just noticed another remarkable statement by Bob Lacatena in Part V:
Lacatena clearly portrays the supposed “Tor browser” and the “Crawler” as separate programs. If the hacker used a non-Tor browser program practically from the start, that proves what I pointed out when this series first began: Lacatena has no basis for claiming a Tor browser was used. By his own story, it is far more likely the hacker was using Tor directly all along.
Heck, I’m pretty sure you couldn’t switch your entry method to the Tor network like that and get directed the exact same exit node. If I’m correct about that, Lacatena’s own words prove him wrong.
Even if you could, I don’t see why he would try to get the same one while also cycling through lots. That said: Some exit nodes carry much more traffic. So even though thousands exist on any given day, a person using Tor might use similar ones over and over.
lucia, you’re terrible:
“his cookie told the server he was user #1. Which is how the SkS system recognizes “John Cook†or “the guy will all the admin privileges—
#1, how original.
A University I was at decades ago had the Administrator password ‘admin’, which made it easy for them all to remember.
Never one to shy from stirring the pot our host stopped by SKS to comment on Chapter 6 of the series. Her missive apparently hit a nerve.
Rob Honeycutt at 11:24 AM on 14 March, 2014
Lucia… So, the one comment you come here to make is a spoiler?
How is it that a fellow who trolls his own threads with such passion and consistency thinks that this was Lucia’s “one comment” on the matter? In Part 1 of the tale she commented,
“2)It’s trivially easy to block Tor. The IPs are publicly available for free.”
The moderators and peanut gallery were oddly silent on this point.
I’d like to encourage the folks on this side of the conversation to refrain from assigning one of those inane, cliche “gates” to this incident. Names like Cookiegate and Insertiongate and Insecuritygate might leap to mind after reading the VI chapters. But those should be avoided in deference to the seriousness of the matter.
Might I suggest something a bit more academic?
“Recursive Incompetence” has quite a ring.
1) I post a comment at SkS.
2) Two moderators respond and also delete my comment.
3) Rob Honeycutt posts what appears to be a complaint that I don’t comment there.
Uhmm… who wants to comment at sites where their comment are deleted? Seriously! Hah!
The acoustics in that echo chamber of skeptical conformists dot com ring pure.
DGH,
Tomorrow we can look to see if my 2nd comment is deleted. 🙂
lucia, I like how they didn’t even give a reason for deleting your comment. Do you have any idea what rule your comment supposedly breaks?
@Brandon,
Lucia tempts the cardinal rule of skeptical conformance.
Brandon,
I have no idea what ‘rule’ my comment broke. Comment 1 included
In my comment (#2) I told him how “he” got in, mentioned “his” name was Dieter and told them were were discussing part VI. Oh… I linked this post where we are discussing Part VI.
I’m not distressed about their deleting the comment. But given Rob’s apparent snark about my not commenting there and the obvious erasure of my comment, I should think the reason why people might prefer to discuss their posts elsewhere would be rather obvious even to Rob.
ROTFL
“Rob Honeycutt at 13:25 PM on 14 March, 2014
Lucia… I actually have access to part 6 internally but was not participating in reviews because I was enjoying the suspense. But you pretty much ruined it.”
Well… booo hooo!
Perhaps John N-G is ready to reassess his endorsement of SkS?
Oooops….sorry, forgot about no rhetorical questions.
SkS seems to have problems with integrity, its leaders participate in faux science projects with Lewandowsky, and now it seems that their head guy, an internet professional, does not know or practice the basics of web security.
And of course their creepy, not at all well explained self-nazification pics. Yet these are the go too guys, endorsed by serious scientists like John N-G.
DGH,
In terms of naming this bit of soap opera over at SkS,
the name for me would have to utilize “kook” as well as “keystone”:
Skeptical Keystone Kooks?
hmmm, seems the release date may have a meaning: http://seanellery.com/sevilization/sevday.html I don’t think this is an evil attack by ‘deniers’ but maybe old friends that don’t like the direction John went in life… Maybe we’ll see in part VII even though it’s apparent it’s all been written but just being released in drips… (still think my first instinct that this was all to distract from discussions about MM’s lawsuit is correct)
hunter, I decided Skeptical Science doesn’t have “problems with integrity” a while back. I found out they used a fabricated quote several times, such as in this post (first figure, “reposition fact as theory”). I wound up writing a post that got published at WUWT, and at least one member of the Skeptical Science team (Rob Honeycutt) commented on a post responding to it. A couple months later, Skeptical Science used that quote a second time, and I wrote about it at my blog. The Skeptical Science team had an active discussion of my post in their forums but took no public actions. To this day, the fabricated quote remains on their site in several posts. That’s when I decided they don’t have “problems with integrity” – they have no integrity.
Others may view it less harshly, but to me, it seems clear they’re knowingly lying to people and simply don’t care.
aww Lucia, in moderation? was it the d word or the link? I’ll try again without both.
hmmm, seems the release date may have a meaning: I don’t think this is an evil attack by ‘d……’ but maybe old friends that don’t like the direction John went in life… Maybe we’ll see in part VII even though it’s apparent it’s all been written but just being released in drips… (still think my first instinct that this was all to distract from discussions about MM’s lawsuit is correct)
I think the words they’re looking for are: “Oh, Good Grief!”….
I just need to add this even though I think it will go into moderation. This link of Rob defending the d word: http://theconversation.com/is-misinformation-about-the-climate-criminally-negligent-23111#comment_333439 and then this link to JC in the old days: https://web.archive.org/web/20130821112704/http://www.cricket-blog.com/archives/2007/05/13/JCs-Law/
Ok… so how many obvious security blunders have we seen:
1) ‘Forgot password reminder’ function sends registered users passwords as clear text.
2) Admin’s response to SQLinjection attacks was to create SQLI log files and post them in clear text on a web accessible location beginning in 2010. (We know this because the WayBack crawled to the /logs file.)
3) Unique Captcha system that creates ‘code’ based on uri. See how the code will match the word in code=Lucia in the folllowing? (http://www.skepticalscience.com/securityimage/securityimage.php?code=LUCIA ) This is easy for bots, hard for people.
4) Special online back door to editing the database: web accessible.
5) Permitted image upload that seems to share the well know “timthumb” vulnerability (which has been widely discussed since at least 2011.)
6a) “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. ”
6b) User editing of cookies sufficient to gain admin capability for the forum.
7) Seems likely they didn’t properly escape SQL.
8) Generally, little screening of administrative area. (Ideally, if very few people -need access, you whitelist IPs and ban all others. But in SkS case they let any IP into admin. Servers? Tor? Malaysia? China? Russian? What have you. And only 2 people needed access.)
9) Looks like they can ‘POST’ with a blank (spoofed) referrer. (Based on example access log entry for 87.225.253.174 ; the behavior makes it easy fir hackers to use off-the-shelf hacker tools or maintain anonymity while hacking.)
10) Permits “crawler” user agents in admin. (Yeah. Some security people say screening user agents isn’t a good way to do security because the attacker can spoof it. But it’s only ‘not good’ in the sense that it has too many false negatives. But a “crawler” UA in admin? You can ban it with a false positive rate of “0”. That’s right: zero.)
11) John Cook has created a “test” user for the forum, given it superuser privileges and forgotten about its existence.
The attempt to make the narrative “exciting” means things are all jumbled and collecting together meaningful facts is like finding parts in a badly organized junk yard or garage sale. I think we still don’t know:
0) How the user (‘dieter’, ‘francois’ or ‘other to be named later’) first gained access as an “author”– and on what date. (As far as I can tell, we are being told everything he did after first getting access as “author” and then escalating privileges, but not how he first logged in. But maybe it’s in partI? Such spaghetti writing!!)
1) How the user (‘dieter’, ‘francois’ or ‘other to be named later’) created their very first “author” identity.
2) How far back SkS’s Apache logs go. (I think for all we know Feb 21 is the “first” identified intrusion because their apache logs don’t go back to Feb 20 or earlier. There’s a quote in part IV “Doug also discovered, while looking at the long list of log file downloads the hacker had conducted through February and March, that the hacker used a different IP address every time. ” Did Doug have January logs?)
3) Whether any of the SQLI attacks were ever successful.
4) Whether they detected the Waybacks visits to /logs.
5) Are the “f2” and “un” files discussed in previous articles the same as the “temp.php”, “temp2.php” and “temp3.php” discussed in Part VI or are they different files?
12. Leaving private directories and pages open to the public.
http://www.skepticalscience.com/stats.php
That didn’t take long to fix.
Now that it’s secure I might also mention that:
13) they listed all of their translators names and email addresses in the pages below that link and
14) they exposed mySQL errors which included various table names.
Brandon,
As our climate obsessed friends keep on digging, I find myself inclined to be as generous as possible. In my world a ‘lack of integrity’ *is* a ‘problem’.
But of course I agree with you.
I think that very unwise asst. professor from RIT will likely regret his very inappropriate and inflammatory call for the jailing of skeptics. Or that poor grad student with his deeply flawed lobster study will soon be receiving some serious counsel on rent seeking and phonied up studies.
Or that academics who have been blithely referring people to SkS will reconsider.
But maybe I am an optimist.
BTW: I put a timeline together.
http://rankexploits.com/musings/2014/timeline-sks-forum/
The only really interesting bits are Feb 21. The hacker seemed to have a good idea what he was likely going to be able to do. He
1) arrived at site.(not a hack.)
2) registered. (not a hack.)
3) confirmed registration. (not a hack.)
4) immediately started fiddling with cookies. (could be called a hack.)
5) very quickly gained admin status. At this point, he can read whatever he wants at the forum, and do anything that an admin can do.
6) poked around apparently interested in learning about image uploads.
7) used an image upload method that had “timthumb” type vulnerability to upload files.
8) At this point, SkS is powend. His files let him look at everything on their server.
9) He hunts around, finds database credentials, adds that to one of his files, gets the database.
10) Cleans up. Leaves.
All the lamentations making negative evidence claims like “he couldn’t have done it this way because….” (most of which were laughable claims) really don’t matter because the reason to believe the hack happened a certain way is that there is positive evidence it happened a certain way.
Could a hack and leak still happen at same time… well.. maybe. But if I were on a jury, I’d think that the hack is much, much more plausible. SkS has laughable security. They got hacked by someone who — for some reason– wanted to hack them. It appears to have been pretty easy because the security was p*ss poor and that’s pretty much that.
DGH, that’s why I’m not inclined to talk about these things in public. A lot of people have a tendency to cover up problems then pretend those problems never existed. Or if that’s not possible, they’ll act like they discovered the problem/were alerted by someone they like. It’s obnoxious.
The funny thing is I’d happily help Skeptical Science with its security if they asked. I wouldn’t even tell anyone I did so if they wanted to make that a condition. I’m confident they’d never ask me to though. The only thing they seem to hate more than admitting mistakes is giving any credit to people they disagree with.
As a tease, I inadvertently found under the right circumstances, I can force their server to output entire tables. I think I know why, and if I’m right, I could probably do a lot more. Imagine if I were willing to actually try.
Bradon,
Oy. Gotta say: I believe it.
Remember their ‘consensus project’ survey would barf up every entry instead of just 10 occasionally– seemingly at random? Several people experienced the ‘full data dump’ (not as a full table– but way more info than John Cook meant to post.)
Yup. After that happened to me, I actually sat down and figured out how to make it happen again. It turns out you could do it whenever you wanted.
I wish I could remember just what it was you had to do. I probably should have kept notes.
DocMartin
Re “A University I was at decades ago had the Administrator password ‘admin’, which made it easy for them all to remember.”
I find some “commercial” equipment still uses that amazingly secure method. Wonder how they discovered that?
David, Doc,
Not going to identify specific cases, but yes. It’s been my experience that well known default passwords (and systems that don’t require the user to change the default password immediately) are a problem in at least a couple of industries.
Lucia, “Oy. Gotta say: I believe it.”
Of course, you can believe it. Don’t bother trying to force the SKS site to spew information, SQL puke from their database is well cataloged on the WWW. That bit I posted yesterday was but a small, carefully redacted tease.
DGH-
What’s the “tease”? I looked for stats.php at google. The pages now display ‘invalid’ but google cache provides mystery data that likely meant something to someone.
I like monthly deleted comments here.
Tease was probably the wrong word. I didn’t want to spam your blog with SQL statements from SKS. Nor did I want to expose their database structure any more than their bad practices have already done.
That small bit was just to make the point that weaknesses that they should have addressed by now persist. The time stamps on the spewed code are all recent.
BTW: The reason so much stuff is in google cache is their robots.txt only says this:
User-agent: *
Disallow: comments.php
Lucia:
I don’t know. If you have a hacker who modified permissions (made things public that shouldn’t have been), it wouldn’t take much for somebody who was e.g., trying to copy all of the publicly accessible files on SKS (aka “mirroring”) to then realize he had gotten more than he/she bargained for.
In fact, the person could have their pull script set up so that it periodically copies new files from the SKS server using a cron script, and have the script email him/her a list of changed files.
See this explanation for a description of how to do this
I do a similar thing already when I’m mirroring my own data directories to my back-up server, except I’m using rsync (local system with ssh access to backup server) rather than wget or curl.
On Mac/Linux/UNIX, any output from the commands run by cron are automatically sent to the account the commands were run on via the “mail” command. So getting the changed files is a trivial thing to do in my case.
With regard to Lucia’s point 11-0 above (author access):
Have we given up on the logs directory as an initial entry point?
Bob writes in part III,
“Because the file contained every SQL statement from a given day, it also inadvertently contained the values which users had been entering as passwords. When the logs were set up to automatically record every database query issued by the system, it never occurred to John and Doug that some of those values might be unencrypted passwords…”
But then Bob subsequently excludes that as a possibility because the folder wasn’t browsable and the file name would have to be guessed, and no trace of such guessing existed. He writes, “That was not how he did it. There must have been another way in.”
Following that we’re interrupted by a detour into irrelevant Heartland Affair territory before getting back to the SkS hack…
Under “Another Day, Another Dollar”,
“He first viewed the recent comments on the site for two full minutes, and then began downloading all of the SQL injection database logs from the 23rd and the 24th. He didn’t need a hacked user ID to get these, as has been explained, because they were erroneously accessible to anyone if you knew exactly where to look, which the hacker did. ”
“Knew exactly where to look” – how Bob how?!?
1. We write publicly accessible logs which contain passwords but Schultz couldn’t have known where they were.
2. Schultz was downloading our logs which were easy for him to get because they were publicly accessible.
Huh??
Yes I too am struggling to read any further.
Only if you give up the “simultaenous leak and hack” theory. But here we do see the hacker visit the logs directory after looking at the directory tree. So, the theory of ‘hack only” does hang together.
Yes. Bob’s exclusion principle appears bogus. The file name could be guessed and the existence of the logs directory was evident from the Wayback machine. So, not only could it be found it was. But that doesn’t mean the intrusion happened that way. They had skillions of vulnerabilities– but certain ones seemed to be “the way”.
Bob’s method of discussing stuff is ridiculous. He posts all sorts of obviously wrong ‘theories’ of why it “couldn’t” happen a certain way. But it “could” have– it’s merely that later evidence suggests it happened a different way. If you just skip parts 1-5 and and read part 6 (which is not currently public– but was in cache which I saved– the intrusion is clearer.) But lots of stuff in parts 1-5 merely confuses the matter — and includes Bobs implausible– shall we say “bogus” theories of what “couldn’t” happen.
Yes Lucia I did skim part 6 but was turned off by blocks of code and prior exposure to Bob’s prose. Now you’ve made me keen but I can’t find it. I think the google cache has been removed?
I see you’re now summarizing in point form. I was thinking before a ‘Cliffs’ would be a good idea for each part; would make clear how convoluted the whole thing is.
http://www.urbandictionary.com/define.php?term=cliffs
when a person begins telling you a story that drags on and on and is full of irrelevant details and not getting to the point… you can hurry things up by asking for “cliffs”.
– derived from cliff notes
“Hey, hey, i dont want you life story just gimme the cliffs!”
Danderson,
Yes. The cache is removed.
I’m not going to put together “Cliff’s” for each part. Among other things, after reading 6, it’s clear the “Cliff’s” for parts I-IV” would bin nearly all paragraphs into:
“this is either
(a) unimportant
(b) bogus or
(c) a revelation of a security flaw (often a stupid one).
”
Generally, the claims of “it couldn’t have happened way X because Y” are nearly always bogus– often because Y is simply untrue. Other stuff- like “The German” might have sipped red bull or looked at John Mashey’s profile are “totally and completely unimportant wastes of time”. Admissions of that in response to seeing SQLI attackes, SQLI logs page was created and posted in a public location where anyone could see it is a ‘revelation of a rather unique security flaw dreamed up and implemented by John Cook’ .
That’s pretty much all that’s in Parts I-IV. Useful tidbits begin to appear in V and Part VI has useful stuff– most of which I put in the table above.
I was just writing Cliffs myself but now you’ve put me off!
So far…
A Hack By Any Other Name — Part 1: Cliffs
– 2 years ago SkS was hacked.
– SkS has enemies — climate bad guys — who don’t like the SkS climate good guys.
– SkS has a private forum which was leaked by the hacker.
That was 6 paragraphs, or about 1/4 of the part 1.
That does seem about right! I guess I was interpreting “in terms of learning anything about ‘the hack/leak'”.
The cached version of Part VI is available again.
All caught up now.
The SKS Stooges have published then hidden yet another embargoed post.
http://webcache.googleusercontent.com/search?q=cache:d0IsJ_u3CPgJ:skepticalscience.com/contrarians-bully-frontiers-lewandowsky.html+&cd=1&hl=en&ct=clnk&gl=
This one is a doozy. Recursive Fury will be retracted. (h/t Ben Pile on twitter)
One can imagine John Cook poking Dana in the eyes. “why I oughta…”
Lucia,
How is it that Google caches those pages so quickly? How often does it/they stop by your site?
Can one automatically demand or request a visit when new material is posted?
Lew has removed the paper with the retraction notice from his UWA website: http://websites.psychology.uwa.edu.au/labs/cogscience/Publications/LskyetalRecursiveFury4UWA.pdf
A Hack By Any Other Name — Part 7
Posted on 21 March 2014 by Bob Lacatena
http://skepticalscience.com/hack-2012-7.html
What about the irony that Part VII was published on the same day as Desmog and Steve McIntyre published the complaints that were submitted to Frontiers In vis Recursive Fury.
It turnsmout that Steve’s claims of malice were partially based on quotes derived from the hidden forum. It becomes clear from those quotes that he and others are held in great contempt by forum contributors. Although we don’t know the specific legal issues that concerned Frontiers In’s lawyers it seems likely that Steve’s well written, on point complaint factored into their decision making.
Accordingly the forum released by the hacker may have had a role in the the retraction of Recursive Fury. This would tend to undermine Lacatena’s assertion that the hack resulted in “Nothing” (or “…almost nothing” several paragraphs later).
DGH,
It made it a busy day for conversation. That means I only tweeted the things that made me laugh in Part VII!
Things that made me laugh in Part VII:
*
He doesn’t know this wasn’t sent by “a bot”. It may not be a garden variety crawler bot”. But “dieter/francois” could have written his own bot. Or he could have purchased a fingerprinting bot that uses starting points, and a degree of learning (with some human intervention) and set that on the site. Then, he’d release that bot, go drink red bull with his buddies and come back later. (Lacatana should know about these things as he himself ran his ” hackcomiler.sh script. That script started with a set of seed patterns.” All a “bot” is is a script that someone set to do certain sorts of automated tasks.)
* On “day 1” (Feb 20), “dieter/francois-bot” begins to act pretty much like a bot. It (a) visits the top page– which probably showed the post published that day (https://www.skepticalscience.com/2012-SkS-Weekly-Digest_7.html) , (b) next visits the first link in the article on that post http://www.skepticalscience.com/denialgate-heartland.html. Both people and bots are very likely to do this.
* After brief visits to a few other links, it visits the register link. A bot would do that. Bots are programmed to look for &form>&/form> in the html. A person might do that too. It started registration, then halted. Both people and bots would do that because– among other things– one needs to get a confirmation email. That would happen both to people and bots.
* During the pause, the entity began to look for pages with numeric strings in the query. Also: something both bots and people do. It specifically starts with “translation” which– to a human– likely has no special significance, but happens to be the first thing one finds if the search “php?” on the html. Visiting the very first thing that has ‘.php?’ and starting to substitute strings is exactly what a bot programmed to find vunlnerabilities on pages with ‘.php’ scripts would be likely to do. It starts to substitute letters and numbers after the lang=. This is exactly what a programmed finger printing bot might do.
* “When that failed to produce a result, he backtracked to the registration process.”. How about this theory: ‘When the confirmation email arrived, he/it returned to the registration process?’ This is what both a bot and a person would do.
*
Ok… so now what does it do? It starts to really truly act like a bot. It reads the html (something few people do) then start to load addresses like “https://www.skepticalscience.com/securityimage/securityimage.php?code=1″. Then it repeats various ones. Why? If it was human and just wanted to register, why not just solve the captcha and finish registering. But a bot? It does what it’s programmed to do. A human looking at that page would very quickly see what it does– but a bot? It just continues doing what the programmer told it to try and then moves on.
* dieter/francois-bot then moves onto another item that ends in ‘.php?querystring=something” and identifies ‘querystring’ is ‘u’ (by reading html) and starts guessing ‘somethings’. This is exactly what a bot would do.
* “There is a deliberate method to this seeming madness” Of course there is method. It is acting just like a bot that “dieter/francois” might use to find vulnerabilities.
*
More likely “The German’s bot tried …” and the bot was likely programmed to systematically build the SQL statement. Because that’s the systematic but totally tedious thing people program these things to do.”
* the entity continues to do tedious but systematic guessing and building– acting just like a bot.
* Bob later concludes:
Well… the calendar time might have been 25 hours. But it’s a bit like baking bread, beer or wine or even growing crops. The human does a few things… then the process takes over… and you do nothing. In the fullness of time, the human might do another process. And then the process takes over. The amount of human time is small relative to calendar time.
Was this done ‘on purpose’? Looks like it. But it succeeded because SkS security was pretty much crap. Mind you, mine might be too. But theirs appear to be clearly worse. (I need to go to my sewing klatch. I’ll write about other silly claims later!)
I have chosen not to comment over at SKS and so I don’t know about their registration scheme. Are you sure that they send a confirmation email? It seems unnecessary and a bit complicated for JC.
Generate a random string, email it, create a change password screen and all of that…
BTW I’ve been meaning to compliment the SKS folks in one regard. They have been remarkably consistent about generating content and adding features to their site over these several years.
One might argue that the quality of the content is low and generally misguided. Count me in that pool. But it would be difficult for anyone who is responsible for maintainsing a website and to a greater degree a blog not to be impressed by the daily updates and regular from their volunteers. Consider that they present that information in multiple languages!
I would argue user security was a compromised by this focus on content. And I suspect that the priorities and deployment of resources haven’t changed much based on the current practices that have been identified.
Despite Bob’s blasé the practice of sendimg plain text passwords is irresponsible. I was also underwhelmed by their method of notifying users of the security breaches which I understand consisted simply as notices on the website and perhaps an email. Anybody who didn’t take notice is still using the same password.
DGH,
I registered again recently with a different email. SkS sent me a confirmation email. If the purpose is to slow bots, confirmation email is useful.
Then it’s entirely possible that a program targeted at SKS did the heavy lifting for this hack.
Did you notice Lacstena’s comments regarding hack vs. leak? I have to assume that was targeted at Brandon’s blog post. Brandon used the term “leak” several times referring to the open /logs directory. In Brandon’s post, John Cook was the leaker, albeit accidentally. Of course Lacatena doesn’t understand that point.
DGH,
I think security was compromised when, back in 2006 or so, John Cook didn’t even think about sanitizing or validating user input. This despite the fact that introductory textbooks about creating web pages discussed the issue.
DGH,
I have no idea whose blog Lacatana was targeting because Lacatana didn’t say. To my eye, it read like he was posting a counter argument against a fictional ‘opponent’. After all, as far as I’m aware, Brandon’s position was the same as mine. That was that we meaning for example, Brandon and I, did not know if material leaked because it was a hack or a leak. And that was perfectly true: We didn’t know. And the reason we didn’t know is that until freakin’ part 6 of this series posted two years after the main event, SkS did not share information that one would need to know to determine whether the event was a leak or hack.
On the one hand, it’s fine for SkS to not share the info they have that they use to diagnose what happened. But on the other hand, it’s beyond idiotic for any SKS insider to think that outsider who do not have access to info and who are– in fact– denied information — to say they “know” whether something was a hack or a leak. Worse, the SkS insiders kept saying we “knew” it was a hack because the leaked could not be recreated from the SQLI leak file– and that claim appears to be utterly false. It would have been possible to do so. It just seems not to be the way that it happened.
Given utter lack of info– and worse– claims about what couldn’t happen, it was entirely rational, reasonable and so forth for both Brando and I to say we didn’t know if this was a hack or a leak. And that’s what both of us said.
Ok… other hilareous (to me) things in VI:
*
In php– the programming language SKS (and wordpress and many sites ) use, there are built in programs to assist with this. For example: to make sure query strings that should only pass interger values are integers, you can do
http://www.php.net/manual/en/function.filter-input.php
$u= filter_input ( INPUT_GET, ‘u’ , FILTER_SANITIZE_NUMBER_INT);
The variable $u will then contain an integer (or nothing) no matter what the person passed after ……php?u=hack_attempt.
It is actually pretty easy to clean up and use everything sent through $_GET, $_POST and so on– if one bothers to try. And while it is not recommended to replace anything in these, if worst comes to worst and you need to do something fast on a system operated by one person (e.g. John Cook) one could drop in a “cleaner” include file that at least does minor– but pretty effective– clean up on all $_GET, $_POST. (Actually, ZBBlock looks for the most likely dangerous calls one might do. It won’t catch everything– but if one drops that in the file with the ‘config’ variables required to call the database, you can make things pretty darn safe quite quickly. And, if necessary, one can add about 10 additional lines to do custom cleaning. )
Does one need to go through every line? NOPE. (Might it be a good idea? Yes. Because cleaning up the main code to be save will result in a safer better operating code. But the fact is: These issues of hackability by SQLI injection could have been dealt with when John Cook first set up his little “log” file which was in 2010 two freakin’ years before the ‘unauthorized disclosure that resulted from the hack’.
(I am btw, planning to do some extra protection on $_QUERY based on those calls. Not beacuse my site would have been hacked by those– but because anyone sending “select” , “union” or “INFORMATION_SCHEMA” in a $_QUERY at my site is up to no good. They should be vaulted into space. )
Oh…even if I hadn’t already been blocking Tor (which is what dieter/francois was using) ZBblock would already have blocked the most dangerous of the ‘dieter/francois’ queries. The rule that would have gotten them is
$ax += (inmatch($querydec,”union”,””)) && (inmatch($querydec,”select”,”RFI attack/SQL injection (QU-024). “));
Having read part VII, I suspect their site security is still extremely weak. To go on about escaping quotes as a security mechanism in 2014, when the knowledge of SQL injection vulnerabilities and tools to bind inputs have been well known for years before any version of SkS was created (as noted above, in introductory textbooks)? Not to mention they were aware of the threat due to the very existence of their “SQL injection logs” and ignoring all of the other vulnerabilities they address.
I was also amused by the dismissiveness of the leak vs. hack discussion as “comical” when he was already recalling the Gleick phishing affair and had noted back in part I how the presentation of the forum dump was phrased almost identically to Gleick’s post as “heartland insider”. Don’t some of them think the strategy memo was legitimate and leaked to this day?
Levi,
the knowledge of SQL injection vulnerabilities and tools to bind inputs have been well known for years before any version of SkS was created (as noted above, in introductory textbooks)? People have known about these for more than a decade — so well before SkS was even launched. And it’s worse than merely “not escaping”. One should validate or sanitize user supplied data routinely. And it’s easy to do.
People have known you should validate or sanitize user data for a long, long, long time. It’s true that lots of people don’t do it. But heck, my betting code contains lines like this:
$Metric = preg_replace('/[^a-z0-9., ]+/i','', filter_var($_POST['Metric'], FILTER_SANITIZE_STRING ));$DateMetric = preg_replace('/[^a-z0-9., ]+/i','', filter_var($_POST['DateMetric'], FILTER_SANITIZE_STRING ));
$units = preg_replace('/[^a-z0-9., ]+/i','', filter_var($_POST['units'], FILTER_SANITIZE_STRING ));
$cutOffDate = preg_replace('/[^a-z0-9., ]+/i','', filter_var($_POST['cutOffDate'], FILTER_SANITIZE_STRING ));
These are all for variabiles most better don't normally see-- but one would see them if they read the html. I imposed my own format-- and it's ok to send the stuff that the filters above permit.
Now, if programmer looks at that they might tell me the coding is inefficient and they'd be right: I was either unaware of more specific built in filters than " FILTER_SANITIZE_STRING" which I could use to avoid the "preg_replace" bit. But even if this coding is laughably inefficient, it's way more safe than whatever Cook did because making sure anything sent in $_POST, $_QUERY or $_COOKIE is 'safe' before using it prevents people successfully creating queries by that include arithmetical operations (i.e. +, -, *, /), function calls (which would contain either () or []) or even including spaces-- which eliminates people adding "sq.cm and 1=1" or something like that in a query.
And-- mind you-- all of this is in the script itself. I've also used ZBBlock since at least 2011 to help protect the site-- That's a year before SkS was hacked by "dieter/francois".
I need ZBBlock because I don't write all the scripts and so can't be sure plugin writers sanitize everything-- it could be the case that they would write insecure code of the sort written by John Cook. ZBBlock makes sure people can't create the truly dangerous query strings-- and reading the things that "worked" at SkS, "dieter/francois" would have been rebuffed if they had merely been using ZBBlock. Using it would have required installing ZBBlock and then dropping in 1 line of code into each of their php scripts. But their reaction to seeing SQLI attacks was not to improve security, but to create a log file, put that in a publicly readable location and do.... pretty much nothing.
The only thing their response to the SQLI attacks did was make the site more vulnerable!!
Skeptical Science is taking all of these leaks and blunders very seriously. Recently they instituted a policy which will prevent pages which are accidentally published from being cached by Google.
meta name=”ROBOTS” content=”NOARCHIVE”
That should fix the problem.
Well, that will prevent people from reading “part VI” when they accidentally publish it. It won’t improve site security much. Maybe a little ….
They did need to beef up security. Lacatana seems to think that the hacker “must” have not used a script. Evidence is pretty ridiculous. For example: the hacking tried queries instead of post and some how that “proves” it’s not a script. Well… ridiculous. Scripts can do query based hacks. Here’s a 2005 article
http://www.oreillynet.com/onlamp/blog/2005/07/launching_attacks_via_tor.htmla
The author writes “Here are some of the entries in my Apache log that were a result of the scan:”
192.168.1.1 - - [10/Jul/2005:17:29:56 -0700] "GET /Agents/ HTTP/1.1" 404 205 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
192.168.1.1 - - [10/Jul/2005:17:29:56 -0700] "GET /cgi-bin/viewpic.php?id=7&conversation_id=&btopage=0 HTTP/1.1" 404 217 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
192.168.1.1 - - [10/Jul/2005:17:29:57 -0700] "GET /index.php?err=3&email= HTTP/1.1" 404 207 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
192.168.1.1 - - [10/Jul/2005:17:29:57 -0700] "GET /scripts/fom/fom.cgi?cmd=&file=1&keywords=nessus HTTP/1.1" 404 217 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
192.168.1.1 - - [10/Jul/2005:17:29:58 -0700] "GET /scripts/viewpic.php?id=7&conversation_id=&btopage=0 HTTP/1.1" 404 217 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
192.168.1.1 - - [10/Jul/2005:17:29:58 -0700] "GET /Album/ HTTP/1.1" 404 204 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
192.168.1.1 - - [10/Jul/2005:17:29:59 -0700] "GET /fom/fom.cgi?cmd=&file=1&keywords=nessus HTTP/1.1" 404 209 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"
192.168.1.1 - - [10/Jul/2005:17:29:59 -0700] "GET /cgi-bin/wiki.pl? HTTP/1.
I’ve highlighted the first three query searches in blue. But every one of these has a query in the script run vulnerability scan.
All his “analysis” is like that. He just decrees scripts don’t “do” things that scripts do do, and concludes it was a human sitting there with his butt in a chair. Then he makes a suggestion about my “motives” about suggesting it was a script. Well… I’m suggesting it’s a script because it looks like a script!