Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Michael]

I've just noticed that the bay12games.com site has been slightly corrupted by a SEO spammer.  Buried in the source of the root page is:

Code: [Select]

<div id="navinav" style='width: 1px; height: 1px; overflow: auto;'> <a href="http://aucasinosonline.com/">au casinos online</a></div>
It's prefixed by many spaces, so you have to scroll right to see it in Firefox's view source.

I noticed because I browsed to the site in lynx, which can see this hidden link more clearly than the real links on the page.

Note that someone with the power to do this could have done far nastier things, such as redirecting to an exploit kit or replacing the game with a trojan.

[smjjames]

Ouch, better let Toady One know ASAP.

Also, I wonder how long that has been there.

[Vilanat]

That's a great find. how the heck did they manage to inject that?

Although, i am not entirely sure this was beneficial to the casino site owner since a 1X1 font is a red flag for Google's algorithms and it is entirely unrelated to bay12. but since google can't tell who put that link in there, it could have actually hurt bay12 rather than that casino site.

[Toady One]

I replaced it with the old index file, but I don't imagine that helps much.  I have no idea how to handle the larger issue.

[Bauglir]

Well, step one would probably be to change whatever passwords allow somebody to mess around with that, and see if you can't check on what accounts exist with rights to modify the main page (that is, make sure nobody made their own admin account after getting in). If you're running your own webserver, making sure all your stuff is updated is good, and if you've got any activity logging stuff running you might be able to get some idea of how they got in and when. If you've got regular backups of the main page stretching back in time long enough that might also help figure out the timetable, but I don't really know how web development works and so don't know how reasonable it is to expect that sort of thing.

If that's the only thing that's changed then I suppose they were more set on being subtle than being malicious, which would hopefully make this fixable. Especially if it was a one-off sort of thing by somebody paid to do a SEO job, in which case they might not ever bother returning to make sure it stuck.

Good luck.

[Flying Dice]

Yeah, I wasn't sure whether you run your own server, so I wasn't sure how much access/control you have.

That aside, it's sort of a weird thing; it's not the actively malicious nonsense I'd expect from the individuals who have had a hate-on for B12/Toady in the past, and it looks as if nothing was ever done past the initial insertion. Maybe part of a project by some two-bit web casino operation that went into the red and shut down? That's what I'd guess as far as motive goes, anyways.

[wierd]

This is the more malign form of the "British Kitchens!" spambot MO.

The british kitchens spam was link spam, intended to increase the page rank of a target website with google, and other high profile search engines, in order to direct more traffic to their target site.

This is similar, but more nefarious. An invisible link is injected into the source code, but the page-rank engine tracks links between pages. Every time Bay12 is linked, this link is also processed, increasing their score. Because it is so low key, Toady never saw it, and thus never deleted/corrected it.

The purpose here is to not draw attention, and to leave the site completely functional-- while still increasing page rank scores.

Reverting the spam injection stops feeding the spammer, but the underlying problem was that the injection was possible in the first place. If the site runs on a linux or other *nix server (I think it is nginx, so probably.) then I would suggest running the daemon under a user credential that has only read-only access to the HTTP host directory structure. That way any further attacks against nginx would get cockblocked by the host OS's file system security.

I would also look into seeing if there are any updates to nginx. (The version in the maintainer's Repo might be out of date.)

Here is a current list of NGINX vulnerabilities.

The thing to remember here-- Don't run a service daemon that interacts with the internet at large with any more access than it absolutely needs to do its job. Should the daemon process be compromised through an exploit, if it is already locked down by the OS, then the hacker can't easily escalate further.  NGINX needs write access to its log folder, but that's about it. The SQL back end needs write access to where its database files and log files are stored. Everything else needs to be read only access (system libs, etc..) or forbidden totally (There is no reason for these daemons to see ANYTHING in /dev, for example. Deny even read access there.)

[Michael]

I think I downloaded 42.02 (the version just before last) with lynx without noticing anything off.  That would indicate the breach occurred this month.

I checked the headers, and apparently the Bay12 webserver is nginx 0.7.65, released in 2010.  That's 7 major versions behind the stable mainline.

On another note, it would probably be a good idea to take checksums of the games so that we can be sure they haven't been quietly tainted.

[SirQuiamus]

Yikes.

Not entirely unlike hanging up a "script kiddies welcome" sign, to be frank. :/

Are the forums hosted on the same server?

[Akura]

I think not, but this isn't really my area of expertise.


I was going to download the latest version, but I think I'll wait until it's verified clean.

[endlessblaze]

Well then...

[Michael]

Are the forums hosted on the same server?

No, in fact they are at completely different ISPs. (bay12games is at "Lunarpages", while bay12forums is at "Linode").

Not that this matters, however. Bay12forums is on exactly the same version of nginx....

[wierd]

Keeping old versions of server software is kind of a long running industry practice.

The bugs are known, and the configuration options are known. This is preferable to unknowns that might break the infrastructure during an upgrade.  This is why many companies run obsolete versions of critical infrastructure software.  Upgrades might break things all over the place, and become very costly very quickly.  They have to approve all upgrades through a laborious QA process, by which time the software they just approved is now also obsolete.

That's why hackers will always be a thing.

(Sometimes this is due to dependencies and the hardware being used. Say for instance, if the newer versions of the software rely on having a newer kernel version running underneath, but the hardware they have in their industry is not supported by that kernel version-- Well, guess they can't just upgrade then, can they? Etc.)

[Michael]

Still waiting for verification that the Dwarf Fortress downloads weren't tainted....

[TheBiggerFish]

Yikes.
PTW.