Intrusion into Cmsimple 3.1

[beate_r]

Hi there,

i would like to inform You that some mentally ill people have intruded (several times) into an Cmsimple 3.1 installation i have set up and destroyed the data there.

I do yet have to find out what happened. Possibly the password was too weak.

Which means that we need a protection against brute force password guessing attacs. Has anyone done something like this?

Beate

[cmb]

Hello Beate,

Which means that we need a protection against brute force password guessing attacs

If it was a brute force attack, cmsimple/log.txt should confirm that.

Which means that we need a protection against brute force password guessing attacs.

Which security_type did you use? wwwauth should provide some help in this regard. At least square brute force will be necessary.

But an additional protection against brute force attacks could be implemented easily IMO. On each login failure a file will be written with the timestamp of the failure. The next login attempt will be refused, if not a least a certain amount of time has passed, say 1-10 sec.

But I'm not quite sure, if a brute force attack has happened:

destroyed the data there.

Could you provide more detail what was destroyed? Was the whole content.htm purged? It might be helpful to detect the attacker's motivation/intention, and what else might happened: did they really get full access to CMSimple's back-end? Or even more?

Another not unlikely possibility is, that the attacker stole your login cookie! Perhaps by means of XSS, e.g. see http://jehiah.cz/a/xss-stealing-cookies-101

I'm really interested in this issue, for security is an extremly important point for all kinds of web applications, and perhaps CMSimple's security could/should be improved. So I'm really happy if you could provide more details on what has happened, and what you've found out about this attack.

And BTW: you absolutely should consider updating to a newer version.

Christoph

[beate_r]

Hi,

Which means that we need a protection against brute force password guessing attacs

If it was a brute force attack, cmsimple/log.txt should confirm that.

It did show two foreign logins at the relevant time. From a cell phone provider, unfortunately not locatable in detail (for us).

Which means that we need a protection against brute force password guessing attacs.

Which security_type did you use? wwwauth should provide some help in this regard. At least square brute force will be necessary.

We are using wwwauth, but with very weak user (admin) and too weak password - a tribute to the site owner and his talent to lose passwords. Of course i changed that to something better after the incident.

Could you provide more detail what was destroyed? Was the whole content.htm purged? It might be helpful to detect the attacker's motivation/intention, and what else might happened: did they really get full access to CMSimple's back-end? Or even more?

At least they succeeded to log into the CMS and edit the data. They purged part of the contents - that providing important information (it is a volunteered self support site). Not the first time - in its pre cmsimple days the site had also been hacked. And again, that information had been copied (to another site) and purged. So we do have an idea where to look.

I'm really interested in this issue, for security is an extremly important point for all kinds of web applications, and perhaps CMSimple's security could/should be improved. So I'm really happy if you could provide more details on what has happened, and what you've found out about this attack.

Which will be difficult due to lack of time.

And BTW: you absolutely should consider updating to a newer version.

AFAIK, 3.3 will not improve this, and a migration to XH is currently not an option to go. Again lack of time. Can't do everything at once in Your free time. This evening i had to disregard working on book-keeping and taxes handling for my company due to this mentally ill person.

Beate

[Gert]

Hallo Beate,

are you using older versions than the newest of AdvancedForm or AdvancedNews? That could be the problem:

http://www.cmsimpleforum.com/viewtopic.php?f=36&t=2382

Gert

[cmb]

Hello Beate,

so it seems the intruder has a personal interest in hacking this particular site!

To be sure if the attack happened by brute force, and to make such attacks more difficult, you could change cmsimple/login.php by including the following two functions:

Code: Select all

function login_allowed() {
    global $pth;
    $fn = $pth['file']['log'].'.ts';
    if (file_exists($fn)) {
        if (time() - intval(file_get_contents($fn)) < 10) { // time in seconds to wait between two consecutive unsuccessful login attemps
            return FALSE;
        } else {
            unlink($fn);
            return TRUE;
        }
    } else {
        return TRUE;
    }
}

function login_failure() {
    global $pth;
    $fp = fopen($pth['file']['log'].'.ts', 'w');
    fputs($fp, time());
    fclose($fp);
    writelog(date("Y-m-d H:i:s")." from ".sv('REMOTE_ADDR')." login failed\n");
}
 

and by modifying the already existing login code:

Code: Select all

if ($login && !$adm) {
    if ($cf['security']['type'] != 'wwwaut') {
        if (login_allowed() && ($passwd == $cf['security']['password'] && ($cf['security']['type'] == 'page' || $cf['security']['type'] == 'javascript'))) { // edit: added parentheses
            setcookie('status', 'adm');
            setcookie('passwd', $passwd);
            $adm = true;
            $edit = true;
            writelog(date("Y-m-d H:i:s")." from ".sv('REMOTE_ADDR')." logged_in\n");
        }
        else {
            login_failure();
            shead('401');
        }
    } else {
        if (login_allowed() && (sv('PHP_AUTH_USER') == '' || sv('PHP_AUTH_PW') == '' || gc('status') == '')) { // edit: added parentheses

            setcookie('status', 'login');
            header('WWW-Authenticate: Basic realm="'.$tx['login']['warning'].'"');
            shead('401');
        } else {
            if (login_allowed() && logincheck()) { // edited
                setcookie('status', 'adm');
                $adm = true;
                $edit = true;
                writelog(date($tx['log']['dateformat']).' '.sv('REMOTE_ADDR').' '.$tx['log']['loggedin']."\n");
            } else {
                login_failure();
                shead('401');
            }
        }
    }
}
 

IMO this should be enough to prevent further brute force attacks, as the attacker has to wait for an amount of time he does not know (see the comment in the code above, and increase the value). If he doesn't wait long enough his attempt will fail even with the correct user/pwd without any special indication, so he might suppose, that the user/pwd combination was wrong. At least the log file will show heavy activity on a brute force attack.

But I'm still not convinced, that the attack happened by brute force. If you could give a link to the site, we could check for possible security issues with used plugins (not only the both plugins mentioned by Gert might be dangerous).

And you should check if there are suspicious files somewhere in the installation, or if you find suspicious code in content.htm or in the data files of the plugins.

Christoph

[beate_r]

Hello Christoph,

thanks for the code. Some work for the forthcoming night...

(IMO this code should be part of any cmsimple version, maybe with an increasing time interval between login attempts)

But I'm still not convinced, that the attack happened by brute force. If you could give a link to the site, we could check for possible security issues with used plugins (not only the both plugins mentioned by Gert might be dangerous).

Meanwhile i know enough not to be convinced any more of the brute force attack. BTW: if it was an exploit of the XSS vulnerability, an upgrade to 3.3 will not help - it still has that vulnerability, hasn't it? What about XH in this respect?

And you should check if there are suspicious files somewhere in the installation, or if you find suspicious code in content.htm or in the data files of the plugins.

A first check was negative. But i will have a closer look; sometimes intrusive code is not seen at the first moment.

BTW: without forgetting the idea of a hacking attack, i am taking in account something completly different: accidental and unnoticed deletion of the pages by the admin (the site uses oedit, and i usually edit content.htm directly, but did not work on the content for months). He was logged in at that time and looked for some coding examples. Aside of this, it is important to check the security issues; i did already observe several successful attempts to hack other people's sites over the past few years.

Anyway, thanks for Your helpful comments.

Beate

BTW: it is a site i discussed here a while ago: http://www.cmsimpleforum.com/viewtopic.php?f=11&t=969

[cmb]

Hello Beate,

IMO this code should be part of any cmsimple version, maybe with an increasing time interval between login attempts

I've already suggested that the logging of login failures should be included to CMSimple_XH. I'm not quite sure, if waiting for the time interval should be included also. An impatient user might not be able to log in any more

if it was an exploit of the XSS vulnerability, an upgrade to 3.3 will not help - it still has that vulnerability, hasn't it? What about XH in this respect?

AFAIK XSS vulnerability can't be avoided completely by any CMS. If the user is loged in, the cookie with login information is stored in his browser's cache. If he navigates to another site, the cookie could be read by a malicious JS script. It's perhaps a bit like answering a phone call while driving your car. But at least it could be made more difficult for anyone who steals the cookie to get access to CMSimple. I will make a proposal in this regard.

it is important to check the security issues; i did already observe several successful attempts to hack other people's sites over the past few years.

One problem might be with plugins. They could introduce different vulnerabilities to an otherwise "secure" CMSimple installation. And this is hard to check, because of the huge amount of plugins and extensions.

And thanks for the link. I'll have a look at it ASAP.

Christoph

[cmb]

Hello Beate,

I had a look on the site, and read in the forum about the hacking attack. It seems possible that someone indeed hacked the site out of envy. But that would mean, he had to find the login password, and he must know at least the basics of CMSimple to delete the desired pages. And he had to log in and out afterwards several times to overwrite the backups.

i am taking in account something completly different: accidental and unnoticed deletion of the pages by the admin (the site uses oedit, and i usually edit content.htm directly, but did not work on the content for months). He was logged in at that time and looked for some coding examples

I've seen that Menumanager is installed on the site. I've had a look at it's stylesheet, and it's missing some parts of my version. Perhaps it's an older version (< 2010a)? I remembered that Holger wrote about Menumanager in a thread about mixed up XH pagedata lately:

könntest Du uns bitte die Version des installierten Menumanagers verraten? Du findest die Info am Anfang der admin.php des Plugins.
Wenn da irgend etwas mit 2008 steht, ist das Problem gefunden.

da hast du die Rechnung aber ohne den Menumanager gemacht (der versteckt oder löscht dann manchmal Seiten, die eigentlich sichtbar sein sollen...)

Probably the mentioned problems were according to XH's pagedata. But I'm not quite sure.

But anyway: it might be best if the user downloads content.htm from the back-end just before he logs out, so that it can be restored if this happens again.

Christoph

[beate_r]

Hello Chritoph,

I've seen that Menumanager is installed on the site. I've had a look at it's stylesheet, and it's missing some parts of my version. Perhaps it's an older version (< 2010a)? I remembered that Holger wrote about Menumanager in a

Yes, of course the menumanager is pre 2010a - the site has been established two years ago in 2009, and i have used the latest version available at that time.

But the official version of cmsimple does not use the pagedata.php. Which rises the question how the (old) menumanager behaves in non-XH installations.

Beate

[cmb]

Hello Beate,

Which rises the question how the (old) menumanager behaves in non-XH installations.

I have no idea. I don't have the old version, so I can't test it. Perhaps somebody else could give a hint?

But anyway: did you check the backups of content.htm directly after the incident and took a look at their dates? That might provide additional clues, what has happened.

Christoph