Cryptocurrency Miner Spread via PHP Weathermap Vulnerability

[camerabob]

Read the below: http://www.securitynewspaper.com/2018/0 ... x-servers/

[Howie]

"an outdated Network Weathermap (0.97a and prior)"

0.97b came out in April 2013 (CVE announced in March 2013).

As I understand what happens, you also need to have allowed untrusted third-parties to access the editor, having ignored the warnings in the manual about httpd access, and enabled the editor (ignoring a web-browser-based warning about access control too).

Editor was disabled by default from 0.97a (Jan 2010) onwards. Specific issues from CVEs (unvalidated paths and XSS) addressed in 0.97b (April 2013).

At the time of the CVE announcement, up until 0.98 came out (about 3 years), there was a sticky note on this forum also. Since 0.98 (May 2016), the editor uses Cacti's own permissions, unless you specifically bypass that by editing the editor.php file.

So yes, please update (or check for updates) more than once every 5 years...

[camerabob]

LOL! I wasn't aware that these dates in this 'recent' article were so old. Still good to know for those folks out there that 'set it and forget it'. Good old Ronco-matic.

[Howie]

It's really the triple threat of "set it, forget it, and allow everyone in the world to access it".

If weathermap checked for new versions, do you think people would mind?

[camerabob]

It's really the triple threat of "set it, forget it, and allow everyone in the world to access it".

If weathermap checked for new versions, do you think people would mind?

Only if it broke something during the updates...

[Howie]

Oh, not automatically updating, just checking the current version every now and then, and adding a notice on the map management page. "You are running 0.97a. The current version is 0.98a. There are 4 years of updates available. These updates include security updates [if they do]"

Once upon a time, it was a feature of Cacti (well, the Update plugin anyway), but it never made it into the modern plugin architecture.

[netniV]

Hmm, I like that idea. Can you open it as an issue on the github website? I recently added the "requires = <plugin> <plugin_version>" to help where one plugin needs another of a specific version (minimum). A version update URL in the INFO file (which points at an INFO file) would be a good way to go. Thus it can compare the two and on the plugin page give a warning. We might have to make it configurable on the reporting interval of plugin updates for example, once a week check and notify. Maybe even sent an email if configured?

[Howie]

viewtopic.php?f=19&t=15176

There used to be a 'version_url' field in the version info (old version of the INFO file).

You send it your version, and it returns a current version and also a message (so the server-side can be a simple two-line php script, or something that's a bit cleverer and presents the right parts of a changelog).

Because the update part was a plugin itself (on top of what at the time was an optional plugin architecture), it didn't get much use, but it was really easy to add support. I had it in all of the small plugins I made then.

[netniV]

The links on that page just go back to a blog but as it was cigamit posting, he may still have the sources. Either that or I just implement my own way of doing it.

[Howie]

His http client was pretty sketchy to be honest (didn't follow redirects, didn't do ssl, didn't understand proxies). Something that uses the php curl functions would be a lot more reliable.

The basic idea though was:

Fetch from $version_url . "?fetch=version&plugin=$plugin_name" to get the current version number (only)

Fetch from $version_url . "?fetch=changes&plugin=$plugin_name" to get the changelog

I think it might be better to do this instead, to allow people to use different versioning schemes:

Fetch from $version_url . "?action=check&plugin=$plugin_name&my_version=0.97" returns true or false

Fetch from $version_url . "?action=changes&plugin=$plugin_name&my_version=0.97" returns relevant changes and potentially more information

Now Cacti doesn't have to understand the versioning scheme, and the changelog can be optimised for the changes between version A and B, rather than all-time. Weathermap's all-time changelog is enormous, for example.

[netniV]

I think we've kind of derailed this topic so rather than continue to discuss this here. Lets get an issue opened to track it properly and then we can see which milestone to put this in, but I think it's a good idea.

[camerabob]

This topic was kind of dead and stinking already. Glad to see something very positive did come out of it though.