4 Unpatched Security Vulnerabiities as of 5.0.7 Fixed Yet?

Hi @indigetal

AIOS 5.1.8 For 2, 4? It is already solved and 3 solutions are ready for the next release. 1st I tried to answer as per my knowledge?I will get back?to you on that.

1. Broken encryption allows 2FA bypass – I will ask in detail internally but from first look the tfa_priv_key_64 stored based on random string of 10 char and user id https://snipboard.io/OLZlNH.jpg The issue they say with hashAndBin is used as salt with user id. in extra we use openssl_encrypt. Also as it says you require a hash password in extra 2FA. code to login. Also if SQL injection is possible why they would just change TFA code they can do more with SQL injection.
2. DOS through IP spoofing. – The REMOTE_ADDR if used as a method it will not be an issue. We provide in Settings > Advanced settings have this default method  also note “The default is to use the REMOTE_ADDR PHP server variable. If this variable does not contain the visitor’s IP address, then whilst you can make a different selection below, it is better to ask your web hosting company to have it correctly set. This is the most secure setup, because when set correctly it is immune from being spoofed by an attacker.”
3. Trivial comment spam bypass – Spam Prevention > Comment spam – The block spam bots posting comment is based on htaccess so it will not work on nginx. We have captcha for comment form and Comment Spam IP monitoring where we ask users to install akismet plugin to mark the comments spam and block IP.  Also right now this functionality regarding  Spam bot detection and deny and mark spam in PHP is implemented. It should be available in an upcoming release which will work on NGINX server. As it is ready I can send you the zip for it if you want.
4. Bypass login page IP allow list – Brute force > Login whitelist is php based not htaccess based

Hi hjogi,

Okay, great! Their review of an older version of AIOS was what stopped me from taking immediate action and instead to check with you guys first. It sounds like the issues are fixed or will be fixed in the next release. It would be great to know what the team’s response is to item number 1 regarding the implementation of 2fa but your response gives me the confidence that there isn’t any red flags on its current implementation.

I’m sure there’s always room for improvement, but there is probably some self-interest involved in Snicco’s recent announcement of widespread security vulnerabilities in popular WordPress security plugins as they are getting ready to launch their own security plugin and would want to convince as many people as possible to make the switch.

While there isn’t much information out there about their plugin, GridPane has put out some promotional material on it that outlines 4 security modules: 1) “A 2FA suite with unique defense-in-depth measures, impervious even if your entire database is compromised.” 2) “A drop-in, argon2-based password hashing schema…” for password protection. 3) A “custom rate-limit implementation that stops even the nastiest distributed, multi-IP brute force attacks in their tracks without frustrating captchas” for login protection. 4) “Fortune 500-level session hijacking and cookie-theft protection to WordPress” for session protection.

The expected cost of that plugin is out of reach for most site owners except those of large organizations and AIOS will continue to be the security plugin that I recommend for most sites, but it would be great to know that AIOS will remain competitive with it – even if those same “extra-mile” features are reserved for the premium version!

Cheers,
Brandon

This is quite strange. Why is he publishing security advisories about version 5.0.7, released in September 2022? It’s April 2023 now.

One of those he reported to us in September 2022 and we fixed it in days, and it was fully documented in the changelog of 5.0.8, released that same month (see the AIOS changelog).

So why in April 2023 is he publishing advisories that have an empty field for “patched version” and recommending removal? He was fully informed about the fix over half a year ago in direct conversation. He also knows how to contact us if he’s unhappy about something, since he has in the past (but hasn’t since then). Very odd behaviour.

There’s more oddness in the others too that we’re looking at internally, as he claims that we were sent one email by WPScan that we weren’t (how does he purport to know what emails WPScan send to people – though as I say, not well enough to get specifics right; that’s very interesting).

Hi David,

Thanks for looking into this! The older version number that they have listed is what gave me pause but because the listings of the issues with the plugin did not include a patched version yet I thought I would reach out. I am certain that the posting of security vulnerabilities of every popular wordpress security plugin is part of a broader launch campaign for Snicco’s new security plugin (fortress[dot]snicco[dot]io) that they are marketing as “the only wordpress plugin smashing real security threats overlooked by the wordpress ecosystem.” Following up with competing plugin developers is not exactly their priority but I checked the records at WPScan myself and I see that at least item 2 vulnerability was patched in 5.0.8.

However, the thoroughness of Snicco’s posts overall and their demonstrated expertise on the issue (not to mention their close partnership with the Automattic-backed enterprise-level WordPress hosting platform, GridPane) lends them a lot of legitimacy.

I don’t know how they would know about the exact correspondence dates with WPScan but it sounds like they were involved. They claim that the issue with AIOS implementation of 2FA as described was merely considered a security enhancement by AIOS and removed from WPScan after not being patched for 3 months, but Snicco argues in their posting of the issue that because AIOS (and UpDraft) “stores TOTP secret keys encrypted in the?‘wp_user_meta‘ table using a broken encryption scheme (a harcoded encryption key is used for every installation),” an attacker can decrypt the TOTP secret keys to generate a valid passcode “since the encryption key is public domain.”

I am not knowledgeable of security best practices but that sounds like a serious issue to me. Regardless, I hope that AIOS would take action. Say, for instance, if a drop-in, argon2-based password hashing schema is significantly better then md5 but is considered a security enhancement, maybe AIOS should include that (even if only as an added benefit in the premium version).

I do think Fortress’s angle of WordPress security is very good (see their promotional copy on their website listed above) and as you can see they’ve got me to re-evaluate my security stack (currently AIOS , MalCare, PatchStack-free), but I’m really rooting for AIOS to meet them where they are proposing to compete!

It’s interesting to see how you’ve read the post, because there are number of things in it which we saw as very misleading pointing in certain directions, and indeed, you’ve taken them to mean the things they don’t, but in the directions they were suggesting.

So, for an example of what I mean about that, you say “removed from WPScan after not being patched for 3 months”. The way they’ve written the post makes the reader think that if something isn’t patched after 3 months, then WPScan give up, remove it from their database, and change the description.

This is nonsense, and simply an insult against WPScan and the WPScan researcher that I talked to at the time, who is one of the mostly highly regarded in the WP industry (and first gave me details of a valid security vulnerability about 10 years ago now!). Nobody decided to label it an enhancement simply because time had passed; it was labeled as an enhancement *because that’s what it is, and the WPScan research agreed*. It’s an extra layer of security in case an attacker has already hacked your site in a way that gives him a very high level of access. It’s ironic that the writer both tries to quote WPScan to give himself credibility, but then also tries to suggest WPScan didn’t do their job too when it turns out that WPScan didn’t classify it as a real vulnerability.

I see that you, quite reasonably, think that a very serious issue is being described, because that’s they way it’s written. But the author was not at all at pains to explain all that has to be got past first to get to that layer, nor that if the attacker *could* do those things, then the attacker could also disable his own solution too! (Really – discussed below). He also doesn’t mention that *nothing* in the WordPress database is encrypted (passwords are hashed, which is different and not possible with secret keys that have to be used in their original form), and I see you’ve then come away with the belief that failure to encrypt is a very serious problem, rather than simply the normal state of all data in the WP database!

Note that WPScan are an appointed authority for issuing CVE numbers for genuine vulnerabilities. Note that neither of these reports has one. The author of the report has tried to use WPScan’s name to bolster his report’s credibility. But people who know about how the CVE system works will see through it: the idea that WPScan simply decided to give up, not issue a CVE number for a vulnerability, and cover it up for their own convenience is, as I say, just insulting to the professionalism of everyone involved.

Internally we looked at the post and decided it had a lot of clear technical errors and misleading statements by obvious omission or otherwise in it. Once you go through the mistakes (and the fact that they didn’t contact us in the 6 months before publication to allow us to see it or make any comments before publication), it can only make reasonable people wonder what the game is. We’ve gone through it internally, and I don’t mind sharing the list with you. This does repeat the above a bit, but anyway, here it is.

• Firstly, they claim that if your website is vulnerable to any SQL injection vulnerability, then the problem described exists. This is false; it would have to be a specific type of SQL injection vulnerability. “The following SQL is sufficient to compromise all secret keys of all users:” – SELECT meta_value from wp_usermeta where meta_key = "tfa_priv_key_64". This is totally ignorant of the fact that the MySQLi component of PHP which runs SQL commands in WordPress will not allow you to chain a second SQL command. So you can’t use an SQL injection to chain a second SELECT like that. If you try, you’ll get an SQL error.
• And by implication, since they apparently don’t know that, they’ve thus never tried to run their alleged exploit or even any other exploit like it. They don’t know what sorts of SQL exploits in WordPress are not even possible in theory, which is an interesting situation for security experts.
• In fact, you’d have to locate an SQL injection in a plugin that is in an existing SELECT query (i.e. making all SQL injections that use UPDATE, DELETE or any other query useless for this purpose) and that is formatted in such a way allows you to add a union to select extra data of another type. i.e. Find an existing SELECT that is already getting some other data from elsewhere, and inject inside it in a way that is still valid, and will also return the wanted data at the same time.
• Doing this would often then cause the calling PHP code to crash or otherwise not work, since the returned data is no longer in the format the code expects because of your modifications. But let’s suppose that the attacker manages to get past that….
• …. now that the SQL query has been run, this doesn’t help him, unless the results are also sent back to the web browser and included as part of the web page. i.e. A raw SELECT call like the one above is not sufficient – you also need to have PHP code that intends to purposefully send back the results to the browser. (Analogously, if you send a letter to someone demanding secret details, it’s useless unless you also have a mechanism to get a response back from them that you can then read).
• Similarly, in their other report, they claim that we talked to WPScan about that other report. We never did; we’ve never talked to anyone about that. The”date first reported to vendor” claim in their report is from thin air: today is the first time we’ve seen that report (which, by the way, has its own long list of impracticalities too…). Making stuff up in advisories is not a good look for someone in a field where trust is paramount.
• The report fails to mention that, if the attacker can run arbitrary SQL commands like in their example, then you could just run an SQL command that deactivates all your security plugins (since in WordPress, the list of plugins to load is just a field in the database). Including theirs! So, in their attack scenario (attacker can run arbitrary SQL), *their plugin is equally vulnerable*. No plugins will be running TFA checks when deactivated. Or run an SQL query to mark TFA as off for the relevant user, etc. etc.
• WordPress has not only had plenty of SQL injections vulnerabilities allowing people more access to the database than they should, it’s also had plenty of filesystem access vulnerabilities too. So, when an extra key for encryption is (as they suggest) put on the filesystem, this can be leaked too via one of those attacks. Two layers are better than one of course, but saying that isn’t quite as dramatic as “you must deinstall all these plugins now, as if there were no layers at all” which seems to be the conclusion they really wanted to get.
• They actually include a code sample in the report in which, if you scroll it to the right, you can see a full description of why the decision not to encrypt in the database is not considered a security issue .i.e. it’s discussed in detail in the public code and has been for years. Do they discuss that in the report? No. Instead, they spin the idea that it’s something we and WPScan conspired to keep secret (and use wording down the bottom too that suggests I just decided to be deliberately negligent for 7 years – which is ironic, since it’s them who neglect to discuss what I have written there). I don’t have a problem with being straightforward and honest, hence it’s fully commented there in the code. That’s important in security.

By the way, you mention password-hashing schemas – these are not relevant here. Hashing is a one-way operation. We’re talking here about reversible (i.e. each way) encryption. You have to be able to reverse the encryption because you need the raw secret key in order to calculate the current OTP code. A hash of the key wouldn’t allow you to do that. WordPress hashes passwords because you can compare a hash of the input password with a hash of the true password. But you need the raw original key in order to generate the final OTP code (which is itself the eventual hash effectively).

Anyway, since they’re using this to attack us, and since we had the enhancement on a feature list anyway, we’ll expedite doing it – especially as I see another competitor has responded to an identical unfair attack on them by doing it too, adding the new layer as a new feature. It’s easier to draw the sting of unfair attacks by removing their basis entirely rather than entering debates which may be what people want to win themselves publicity (we’ve had that in the past too).

So, short version: it’s not a vulnerability, WP Scan agree, hence no CVE number, but we’ll be adding the feature anyway so it can go away and we can spend our time on other stuff instead of responding to unfair attacks by people who don’t give us right of reply before publication.

David

Thanks David, I admit that I’m not at all knowledgeable in the security realm and am susceptible to being mislead – though I’m planning to step up my game. I’m also a poor mediator here, but for your records and review, they have elaborated on their thoughts regarding the decision by WPScan, saying:

“Almost every major security company around WordPress has this serious blockage in their thinking. Which is: ‘Well, if they already got a read SQL injection then… what’s the point?’ All of the security issues that Calvin found were effectively rejected by CVE authorities because they required ‘preconditions.’ Which I think is completely daft. Because it’s not like it’s a RARE thing for there to be SQLi issues in WordPress. It’s actually rare for there to NOT be SQLi issues. If the opposite were true, you wouldn’t need to hash passwords. There would be no point. Because you’d have a very secure DB. You should assume that the database can and will be breached. And you should build contingencies around that fact.“

Your last response was very thorough and I think it addresses some of these claims already. In any case, I very much appreciate that you and your team are willing to move some things around to resolve any potential confusion that others may be seeking to sow in us less informed users! I was hoping to get a positive response from you guys and you are delivering!

Cheers,
Brandon

Hi Brandon,

Thanks for sharing!

I tried to partly cover their anticipated response in the earlier one. If SQL injection attacks are common and normal, then so are file disclosure attacks. So, if they’re saying “you need a second layer, because the first layer is practically useless”, then they’d have to logically concede that the second layer is also practically useless (i.e. two times almost nothing is still almost nothing).

i.e. To make their solution work, (on their way of seeing it), a second layer is not enough; they’d need to *also* deliberately rotate the credentials in both layers very frequently too, because they expect both layers to be hacked often. So on their logic (your database will regularly be breached), their solution remains vulnerable and dangerous (since your filesystem will also regularly be breached) and they then need to enhance it further to mitigate that to be consistent with their view of things.

The response does still equivocate between “SQLi issues” and “SQLi issues you could actually exploit”, though. Again, if it’s easy to run SQL on their website, then we can just run an SQL command to disable the entire plugin (whichever plugin we mean), turn off TFA for the particular user without needing to know his secret key, etc., and then even if it has 600 different layers coded in to protect the key, they’re still no more useful than one was when they’re all inactive! (We can then run another SQL command to change the admin’s password too if we’ve got those powers).

Nice for them to admit that basically everyone disagrees with them though, that kind of honesty isn’t always there. Anyway, I’m not disputing that two layers can be better than one, and so, we’re adding it in our next release anyway, so hopefully everyone will be happy.

It’s always important, whatever locks you have on the gate, to have good backups. I would say that since I develop UpdraftPlus, but it’s true. It’s always an arms race with the bad guys. (The paid version of UpdraftPlus can encrypt the entire database backup so that all plugins’ data is covered, many other products are available etc. etc.! ).

I’ll mark this one “resolved” now since presumably when the feature is out, everyone will be happy whatever their view on the theory was!

David

The people behind Fortress have been given the link to this support thread and have personally read it, but they have not updated ANY of the 4 security vulnerabilities they have listed for AIOS (no patched version listed, recommendation to remove). Privately they are calling foul to what David is saying here but I guess they are choosing not to directly reply.

Feel free to use any of this info for a blog post on the AIOS website to confront these kinds of suspect claims that Snicco has posted on AIOS. Clearly their “Vulnerability Disclosures” were not meant as an up-to-date database of security vulnerabilities, but a one-time marketing scheme to suggest to potential customers who are not security experts that some wordpress security plugins have issues (at least in the winter of 2022/23) using technical jargon that they most likely wouldn’t be able to follow to convince them that the issues listed were legitimate and serious, when as David points out, to a security expert much of it is hot air.

As someone who falls within that non-expert bucket, I am a bit insulted and would of course like to see this kind of behavior addressed (especially given that as long as they do not update the vulnerabilities listed for AIOS, it is an ongoing problem).

Hi,

Just as an update on this in case anyone stumbles upon this thread.

The latest verson of AIOS 5.1.9 released yesterday, contains the feature “Encrypt TFA secret keys that are stored in the database (extra protection in case of your database being hacked)”.

This resolves the security enhancement mentioned above.

Best Wishes,

Ashley

An update to the update: it has been claimed that the second security issue originally listed, “DOS Through IP Spoofing” has not been adequately addressed. I am not knowledgeable in this space so I will just relay the message that I’ve received for your teams response/review:

“Unfortunately, the provided patch is not sufficient. While the statement ‘The REMOTE_ADDR if used as a method it will not be an issue,’ is true (from hjogiupdraftplus initial response), any other selection is still vulnerable, regardless of the hosting provider’s recommendation. Refer to ‘How to safely get the IP address of the current user in a WordPress plugin‘ for further details.”

I am confident that David and team will know how to address this and I do not otherwise presume what is and isn’t considered an adequate solution to the issue regarding DOS through IP Spoofing.

Cheers,
Brandon

Hi @indigetal

Sorry for late reply. REMOTE_ADDR? we have considered as default and best option and also provided the UI to show what host doing. Now they say it should not allow any thing else than REMOTE_ADDR and should educate need proper host.

But Cloudflare do not provide correct visitor IP address using REMOTE_ADDR. and if it is used it will block user to itself. So in real situation we have to allow the other IP method also according to me.

https://snipboard.io/VOp59B.jpg

Though I will internally discuss on this and get back to you.

Regards

Hi @indigetal

As per internal discussion also what best possible option to provide IP address detection has been worked on already and do not need change from our end.

Regards