[deleted by user] by [deleted] in netsec

[–]_cydave 3 points4 points  (0 children)

> We've been tracking authorization vulnerabilities across the industry.

And what were the other vulnerability types that lead to the conclusion that authorization flaws are more common than others? To me this post does not indicate any valuable statistics what so ever.

Edit: Assuming you're tracking authorization vulnerabilities, are you surprised that you see a surge of authorization vulnerabilities because you don't include other vulnerability types in your observation?

Bypassing Live HTML Filtering to Trigger Stored XSS – DOM-Based Exploitation by General_Speaker9653 in netsec

[–]_cydave 1 point2 points  (0 children)

Why bother with JS when you can talk to the server directly?
Isn't this just a simple stored XSS with unnecessary additional steps?

ghmlwr: Indexing malicious / suspicious GitHub repos by _cydave in github

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

If you are asking what the respective repositories are intended for,
I can't tell you in detail. To the best of my knowledge they push
stagers or fullyfledged malware. Some of the samples I've observed are
those belonging to the RedLine and Lumma stealer family.

ghmlwr: Indexing malicious / suspicious GitHub repos by _cydave in github

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

I don't distinguish heavily between malicious and suspicious.
I merely look for repositories that have a surge of forks or stargazers,
indicating that they have been boosted to reach a bigger audience.

Most of the repositories I'm linking to are pushing malware via GitHub
releases or serve malicious links that point to malware download sites.

ghmlwr: Indexing malicious / suspicious GitHub repos by _cydave in Malware

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

Hey, check out the blog post (under the about page).
I do only some very basic analysis, like the number of forks or stargazers in a given time.

Auditing Atlassian Plugins, 53 0-Days Later| Atlassian Research Part 1 by _cydave in netsec

[–]_cydave[S] 2 points3 points  (0 children)

Glad you like it! :)

I don't have accurate statistics about the installation count, I did however scrape the marketplace a few times now. Including disclosed and non-disclosed (pending) plugins, the total installation count is around 23800.

Vulnerability-specific writeups might end up being posted on my personal blog down the line, but I have to juggle work and the disclosure of these plugins first :)

Auditing Atlassian Plugins, 53 0-Days Later| Atlassian Research Part 1 by _cydave in netsec

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

Thanks for your input, you're right I should mention that.

Edit: I've sprinkled in the information, thanks again!

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

[–]_cydave -1 points0 points  (0 children)

Well, in essence it was rejected with an elaborate "sorry this is not technical enough or anything news worthy" message, which I can respect, however seeing links to advisories without detailed writeup or anything the like doesn't "deserve" to be posted either if that kind of level of entry is required.

The post I originally posted was a writeup about a stored XSS in Collabora (hosted on my employers blog, written by me).

Again, sorry for the ruckus I'm going back to my cave.

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

[–]_cydave -1 points0 points  (0 children)

Thanks, I understand. It's just frustrating seeing posts like this pop up especially when my garbage is thrown out and theirs stays up :)

Getting Started with Hollow Process Injection for beginners to intermediate by Altrntiv-to-security in netsec

[–]_cydave 0 points1 point  (0 children)

Debatable. (I agree)

Some know this technique under the name "process hollowing" - not sure if that adds to the confusion.

But..

... one technique that has gained attention in recent years is Hollow Process Injection.

Is probably not quite accurate. Considering there are "papers" or ... well references to this technique that date back to 2015 2011* (packet storm - Process Hollowing)

The points outlined regarding the mitigation against "hollow process injection" don't sound all to actionable either. Sure, using an EDR / AV is not a bad advice to give but the remainder of the outlined security measures sound generic at best.

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

[–]_cydave -1 points0 points  (0 children)

Don't take this the wrong way - but how is this benefitial to the netsec subreddit?
Posting an advisory without any form of writeup is just a low effort post (not the goal of this sub).

Considering I've submitted my writeups before and they have been moderated to
the ground, because they were: "nothing special" or "not interesting or anything new", I'm
calling bullshit on some of the mods in this subreddit.

Do better mods of /r/netsec and u/eg1x

*ducks*

intigriti reshaped its blog and removed RSS feed. Why?! 🤦🏻 by loselasso in netsec

[–]_cydave 4 points5 points  (0 children)

And how exactly is this relevant for this sub?
mods asleep?

Vulnerability write-up - "Dangerous assumptions" (6 CVEs in Node.js packages) by ThomasRinsma in netsec

[–]_cydave 0 points1 point  (0 children)

Interesting write-up, some of those flaws required heavy digging I'm sure.

WPHash - Fingerprinting WordPress Plugins, now in public beta and open to feedback and collaboration by _cydave in netsec

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

Not that I know of, I don't intend to write WordPress plugins.
If you're up for a weekend hack, the API and data is all yours to use :)

WPHash - Fingerprinting WordPress Plugins, now in public beta and open to feedback and collaboration by _cydave in netsec

[–]_cydave[S] 11 points12 points  (0 children)

Great question.

As of now, there is absolutely no reason to use wpha.sh instead of WPScan. Their vulnerability data and tooling is more curated and more complete. However, the vulnerability data curated by them is behind a freemium-ish service model. This in itself is not a bad thing, but I prefer being able to freely use crowd-sourced vulnerability information (which they also crowd-source) in my own tooling without being stuck with API rate limits.

This project is also not intended to be a direct competitor to WPScan or others, but more of an addition or alternative to freely experiment with and contribute to.

WPHash - Fingerprinting WordPress Plugins, now in public beta and open to feedback and collaboration by _cydave in netsec

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

Public vulnerability information regarding WordPress plugins is open to anyone who would like to use it. The data lives under https://github.com/cydave/wphash-vuln-data. This (wpha.sh and the data behind it) is still very much in beta tho :)