MyBB Community Forums

(2014-11-17, 07:01 PM)StefanT Wrote: [ -> ]No, you are not affected at all.

thanks. 

Hi Pirata Nervo. I admin 2 boards, and they have this in update_check

Array
(
    [last_check] => 1416266931
    [news] => Array
        (
            [0] => Array
                (
                    [title] => [UPDATED - IMPORTANT] GitHub Account Compromised
                    [description] => UPDATE: Updated the page in which you should check for suspicious activity. It should be the Admin Logs page, not the Database Backups. You should also rebuild the cache (if you’re on 1.8) for ‘update_check’.   Hello, Yesterday, 14th of November, my (Pirata Nervo) GitHub account was compromised. By taking advantage of that, the attacker […]
                    [link] => http://feedproxy.google.com/~r/MyBBDevelopmentBlog/~3/9jWBtaXX3d8/
                    [author] => Pirata Nervo
                    [dateline] => 1416069961
                )

            [1] => Array
                (
                    [title] => MyBB 1.8.2 Released – Security Release
                    [description] => MyBB 1.8.2 is now available from the MyBB website. It fixes 1 high risk vulnerability, 2 medium risk vulnerabilities and 2 low risk vulnerabilities. We recommend everyone upgrades to this release immediately. MyBB 1.6.15 is not affected by these vulnerabilities. What’s added/changed in this version? The vulnerabilities are: High Risk: A SQL injection vulnerability in […]
                    [link] => http://feedproxy.google.com/~r/MyBBDevelopmentBlog/~3/EkqazJvmZXc/
                    [author] => StefanT
                    [dateline] => 1415917805
                )

            [2] => Array
                (
                    [title] => MyBB 1.8.1 & Merge System 1.8.1 Release
                    [description] => MyBB 1.8.1 – Maintenance Release MyBB 1.8.1 is now available from the MyBB website and is a maintenance release. What’s added/changed in this version? This release fixes 74 reported issues causing incorrect functionality of MyBB. Please be aware that to be able to provide easy to manage updates not all issues have been fixed in this version. Bugs […]
                    [link] => http://feedproxy.google.com/~r/MyBBDevelopmentBlog/~3/erxFg7H84tQ/
                    [author] => StefanT
                    [dateline] => 1414093168
                )

        )

)

and **********************************

on the other forum, I have 

Array

(
 [last_check] => 1416235062
 [news] => Array
 (
 [0] => Array
 (
 [title] => [UPDATED - IMPORTANT] GitHub Account Compromised
 [description] => UPDATE: Updated the page in which you should check for suspicious activity. It should be the Admin Logs page, not the Database Backups. You should also rebuild the cache (if you’re on 1.8) for ‘update_check’.   Hello, Yesterday, 14th of November, my (Pirata Nervo) GitHub account was compromised. By taking advantage of that, the attacker […]
 [link] => http://feedproxy.google.com/~r/MyBBDevelopmentBlog/~3/9jWBtaXX3d8/
 [author] => Pirata Nervo
 [dateline] => 1416069961
 )

 [1] => Array
 (
 [title] => MyBB 1.8.2 Released – Security Release
 [description] => MyBB 1.8.2 is now available from the MyBB website. It fixes 1 high risk vulnerability, 2 medium risk vulnerabilities and 2 low risk vulnerabilities. We recommend everyone upgrades to this release immediately. MyBB 1.6.15 is not affected by these vulnerabilities. What’s added/changed in this version? The vulnerabilities are: High Risk: A SQL injection vulnerability in […]
 [link] => http://feedproxy.google.com/~r/MyBBDevelopmentBlog/~3/EkqazJvmZXc/
 [author] => StefanT
 [dateline] => 1415917805
 )

 [2] => Array
 (
 [title] => MyBB 1.8.1 & Merge System 1.8.1 Release
 [description] => MyBB 1.8.1 – Maintenance Release MyBB 1.8.1 is now available from the MyBB website and is a maintenance release. What’s added/changed in this version? This release fixes 74 reported issues causing incorrect functionality of MyBB. Please be aware that to be able to provide easy to manage updates not all issues have been fixed in this version. Bugs […]
 [link] => http://feedproxy.google.com/~r/MyBBDevelopmentBlog/~3/erxFg7H84tQ/
 [author] => StefanT
 [dateline] => 1414093168
 )

 )

)





Do I have the same problem, or Im clean?
Thanks
 regards

Looks like you're OK @begincaos

Thanks. ^^ hope the most us us are the same. ;/

(2014-11-17, 05:38 PM)Pirata Nervo Wrote: [ -> ]

(2014-11-17, 05:23 PM)Maechlis Wrote: [ -> ]Then as I said above it makes sense to adopt your blog recommendation to that case. Because I think there are lots of people now who read the post, go to their ACP and have the malicious code executed, like I had it.

Perhaps they would better disable the admin panel backup first (by modifying the php code or something)!

I'm not sure I'm following you. I mention in the blog post to clear the cache entry. Are you suggesting that I suggest people to delete the backup module first?

@jshort it affects all boards.

I'd like to note that right now it's still targeting the backup module but it can change at any minute (e.g. deleting users).

I'm fairly sure there is a language barrier here.

The poster is asking why you originally recommended people to logon to ACP if that's what triggers the hack...

What is being done to keep this from happening in the future? Why would such a security hole exist in the first place? It seems almost fantastical.

If there's no way to close the hole, perhaps auto version checks should not be happening at all. Just securing your GitHub accounts seems an extremely weak measure.

Now that I'm done griping...

Mine reads:
Array

(
[dateline] => 1406476664
)

Does that mean I'm good to go? If so, is there anything else I need to do to secure myself?

Please read here: http://community.mybb.com/thread-162862-page-5.html

Yes, you're safe. And I recommended people to go to the ACP because I either recommended them to go there and rebuild their cache or I'd tell them to open up PHPMyAdmin, go to the datacache table and empty the update_check entry. I'm sure most of the users would complain - as always, people will complain if you say X and people will complain if you say Y.

(2014-11-18, 11:13 AM)DrXotick Wrote: [ -> ]The poster is asking why you originally recommended people to logon to ACP if that's what triggers the hack...

I don't think anyone realized right away the extent of this hack (that it got stuck in the cache). At the time the blog post was made it was believed to be safe (because the malicious GitHub change had been reverted) but as it turned out later it wasn't the case because of the cache. MyBB 1.8 even has a task to update that cache regularly but the way it is implemented, it took in the malicious code but never got rid of it even after it was removed from GitHub, since it only updates with version increments.

^Yeah that's right. I guess we could have waited a few more days and investigate the issue more deeply but that would cost our users time and would give our attacker more time to attack our users. We preferred to alert everyone of the fixing steps we knew about without knowing the full extent of the problem, rather than knowing the full extent of the issue and not allowing people to prevent themselves during that time. In the end, I guess we'll never know which one was the best.

(2014-11-18, 11:13 AM)DrXotick Wrote: [ -> ]If there's no way to close the hole, perhaps auto version checks should not be happening at all. Just securing your GitHub accounts seems an extremely weak measure.

1. Who said there is no way to "close the hole"?
2. If you read few posts here, you'll notice it's not the only countermeasure..

(2014-11-18, 11:22 AM)Pirata Nervo Wrote: [ -> ]And I recommended people to go to the ACP because I either recommended them to go there and rebuild their cache or I'd tell them to open up PHPMyAdmin, go to the datacache table and empty the update_check entry. I'm sure most of the users would complain - as always, people will complain if you say X and people will complain if you say Y.

Strange. I wonder why the MyBB staff fails to understand that the current recommendation in the blog post forces at least some admins to themselves trigger the malicious download of their database, given that there's that cache problem in place.


Take my example (sorry!) once again. We know that my DB was not stolen during 14-15th (because I was not in my ACP those days). Very well.

The problem has been fixed on the GitHub side since then. So the reasonable outcome would be that after 15th I would be safe against the problem, if following your recommendations.

Now what was the actual outcome was that I did follow your recommendations and thus got my DB stolen yesterday - this exclusively because the recommendations were incomplete - they did not take that cache issue into account.

OK, what's done is done, we discussed the matter yesterday and realized that it was the cache issue that led to that unfortunate result.

But why do you not correct your recommendations to account for that cache issue? Why are you still actually recommending people: "Go to your ACP and trigger your own DB to be stolen" ???

I think the recommendations should be corrected asap.

UPD: I read in the parallel thread that the malicious code has been removed from its URL, so now it does not matter whether the recommendations are corrected or not.

Anyway, please excuse me, but they were poorly and inadequately engineered. If I did not follow them yesterday, I would not have been compromised. Security should be in the first place, all possible "user inconvenience" of going into phpmyadmin should be in the second.

Those guys might have been millionaires by now if they prepared a bit better to this attack and ventured to download complete databases, not just the "users" table. Thanks God that attackers have limited aspirations.