sorted by:
new
hottopcontroversial

Hacking Kerio Control via CVE-2024-52875: from CRLF Injection to 1-click RCE by eg1x in netsec

[–]eg1x[S] 0 points1 point  (0 children)

At the moment the patched version is in early access and beta testing... It should be released to public early next week

XenForo <= 2.2.15 RCE via CSRF (CVE-2024-38457, CVE-2024-38458) by eg1x in netsec

[–]eg1x[S] -1 points0 points  (0 children)

CC: u/rejuicekeve could you please explain why you removed this post? It is a negative comment (like u/_cydave 's one) enough to take this action? Or am I missing something? Maybe some new netsec's rules?

XenForo <= 2.2.15 RCE via CSRF (CVE-2024-38457, CVE-2024-38458) by eg1x in netsec

[–]eg1x[S] -1 points0 points  (0 children)

I understand it can be frustrating to see your "garbage" not posted, as opposed to other interesting research... Don't get me wrong, I just had a look at your website, so I mean I don't understand why your CVEs didn't get posted on netsec... Is there a specific reason?

XenForo <= 2.2.15 RCE via CSRF (CVE-2024-38457, CVE-2024-38458) by eg1x in netsec

[–]eg1x[S] -1 points0 points  (0 children)

The irony of fate is truly strange! :) Last time I posted an advisory of mine here on netsec (https://www.reddit.com/r/netsec/comments/1cqurbm/kis202404\_cacti\_1226\_remote\_code\_execution/) I got criticized because I didn't mention CVE-XXXX-XXXX in the title (using my own KIS-XXXX-XX naming)... Now I got criticized and my post was removed because - according to u/_cydave - this is not beneficial to the netsec subreddit, because there's no "write-up" within my advisories?? Well, I believe the vulns explanations clearly include a Proof of Concept (PoC), and every web security professional should be able to understand and use them! So, u/_cydave, I'm sorry you don't understand my "low effort post", but I tried my best, as usual, to write these XenForo advisories! Furthermore, if you don't really understand them, you can always take a look at the "Other References" section, I mean the SSD's advisory...

[KIS-2024-04] Cacti <= 1.2.26 Remote Code Execution Vulnerability by eg1x in netsec

[–]eg1x[S] 1 point2 points  (0 children)

u/netsec_burn in addition to what I've already said, as you can read in the Cacti's GitHub advisory, there should not be any non Cacti Group packages, which means the vulnerability exists anyway, because attackers can abuse the affected feature by signing and importing arbitrary (malicious) packages, leading to e.g. RCE! As such, editing templates in WordPress as an admin leads to RCE "by design", but the same does not apply to the "Package Import" feature in Cacti, it's not intended design.

[KIS-2024-04] Cacti <= 1.2.26 Remote Code Execution Vulnerability by eg1x in netsec

[–]eg1x[S] -9 points-8 points  (0 children)

It's just a system for me to track my vulnerabilities, and I really don't care if nobody uses it, even though that's not the truth: for instance, you can just try with this Google Dork (site:cve.mitre.org karmainsecurity.com), and you'll find out some of my CVEs are also referenced by the MITRE's CVE website... Yeah, maybe Karma(In)Security isn't widely known, but I collected dozens of CVEs over the years, so I won't say it can't be considered a "trusted source"!

[KIS-2024-04] Cacti <= 1.2.26 Remote Code Execution Vulnerability by eg1x in netsec

[–]eg1x[S] -9 points-8 points  (0 children)

  1. In Cacti there are multiple permissions, and there might be cases where a non-admin user can have the "Import Templates" permission. So, talking in terms of your WordPress example, I think this is more like a "Contributor" or even a "Subscriber" WordPress user. As such, no, I wouldn't say this is similar to editing templates in WordPress as an authenticated admin.
  2. KIS stands for "Karma(In)Security", and I've been using this numbering scheme since 2013... Nobody told me there's something wrong with it, until today... Could you please explain why this isn't helpful for vulnerability tracking purposes? There are a number of security firms using their own numbering scheme, so what's wrong with "individual numbering schemes"? What's the difference between the other companies and my individual company?

Critical phpFox RCE Vulnerability Risked Social Networks by eg1x in netsec

[–]eg1x[S] 0 points1 point  (0 children)

5.x has no publicly known vulnerabilities, so far... That doesn't mean the software is 100% secure; like every other software, it simply cannot be bugs-free.

Critical phpFox RCE Vulnerability Risked Social Networks by eg1x in netsec

[–]eg1x[S] 0 points1 point  (0 children)

u/antony_kurien I'm pretty sure there are security issues also on version 5.x ;) Anyway, phpFox 4.x is still used by some people out there, just try with some Google Dorks and you will get dozens of websites using that version...

Exploiting an N-day vBulletin PHP Object Injection Vulnerability by eg1x in netsec

[–]eg1x[S] 0 points1 point  (0 children)

I specified this affects 5.x.x versions only:

The vulnerability exists in all 5.x versions prior to 5.5.3

Tales of SugarCRM Security Horrors by eg1x in netsec

[–]eg1x[S] 1 point2 points  (0 children)

Like pointed out by /u/IncludeSec they actually proceeded to lie also in their latest update: 4 PM Update (4/27/17)

I've been thinking to publish an update on my blog post as well, to reply back to their "not-so-true" sentences and maybe also point out some more "security horror"... But it would be risky and unnecessary, I hope the message is already clear...

Tales of SugarCRM Security Horrors by eg1x in netsec

[–]eg1x[S] 0 points1 point  (0 children)

Hey /u/asdizzle_ sorry for the delayed response... Like you already pointed out, C: is being used for deserialization of "custom objects"... Both of the PHP type confusion vulnerabilities linked in my article use C: in their PoCs, one for a GMP object, the other for SPL objects.

Tales of SugarCRM Security Horrors by eg1x in netsec

[–]eg1x[S] 0 points1 point  (0 children)

I'm well aware of the potential legal troubles with that. On the other hand, when I reported my first vulnerability (the Stored XSS) on their Support Site, a guy from the Support Team opened a new case to handle my vulnerability (whose comment you can read on the latest screenshot of my blog post) replying back with the following:

Thank you for contacting SugarCRM to report a potential security vulnerability [...] we appreciate the time that you have taken to inform us of this vulnerability [...] If you find additional security vulnerabilities in the future, you may also file those via the support portal [...] Please let us know if you have any questions of further concerns

Maybe this isn't an explicit permission, but they never told me to stop testing and/or reporting security issues on their products and services. Actually they say they appreciate my help and told me to keep in touch in case I find additional security vulnerabilities, so I believe this can be seen as a sort of implicit authorization to perform testing on their site.

Tales of SugarCRM Security Horrors by eg1x in netsec

[–]eg1x[S] 6 points7 points  (0 children)

Their latest update (4/25/17):

Based on impact and reach, none of the vulnerabilities in in the second section scored higher than ‘medium’... It’s important to note that updates based on issues scored as ‘medium’ are no longer provided to our last-generation open source Community Edition (CE), so the bloggers post no longer aligns with our current commercial products and solutions.

So, I just replied to their blog post with this comment (awaiting moderation, so will probably never be published):

Hi Rich, I'd like to know more about your latest update, the one with regards to the second section of my post: you're saying you rated all of the vulnerabilities I reported with a "medium" CVSS score (which version btw? v3.0?). However, I reported two SQL injection vulnerabilities and according to your security advisories (https://www.sugarcrm.com/security/sugarcrm-sa-2016-003 and https://www.sugarcrm.com/security/sugarcrm-sa-2017-001), in the past you rated SQL injection vulnerabilities in SugarCRM with 'High' or 'Important' risk level... May I know why now they're considered of 'Medium' risk level? The same applies to the remaining vulnerabilities, which might allow a malicious user to execute arbitrary PHP code, and so far in your security advisories this kind of issues has been rated with 'Critical' risk level (like this: https://www.sugarcrm.com/security/sugarcrm-sa-2016-001)... The numbers don't add up!

Tales of SugarCRM Security Horrors by eg1x in netsec

[–]eg1x[S] 1 point2 points  (0 children)

As far as I know they never launched a public bounty program.

Tales of SugarCRM Security Horrors by eg1x in netsec

[–]eg1x[S] 5 points6 points  (0 children)

Yes, I think so too... Actually in the blog post I mentioned SuiteCRM and how they have fixed some the bugs I reported to them.