infosex.exchange <3

You are probably looking for the infosec.exchange Mastodon instance

This host is mostly for my random stuff, and in little part acts like a well-intentioned placeholder for the typosquatted domain.

Discoverability and Archiving

Currently I'm using this host for saving the items from my own feeds to the Wayback Machine and provide in-links for search engines. I hate that I have to do this, but the non-sense ideology of Mastodon pretty much ruined the search feature for Fediverse as a whole, and this wasn't changed by the fact that they owned their mistake and implemented search eventually.

Yes, I (or anyone else) could do similar things with other peoples published feeds, regardless of the tantrum. No, you can't defederate this, because the process doesn't rely on an instance.

Gluttony Section for Search Engines

[RSS] Micropatches Released for Windows OLE Remote Code Execution (CVE-2025-21298)

https://blog.0patch.com/2025/02/micropatches-released-for-windows-ole.html
this post | permalink
@screaminggoat @zeljkazorz @GossiTheDog "However, due to inadequate server configurations, attacks become possible if *the serialized data is not verified* (CWE-642)" - this sounds more like disabled MAC than leaked key to me
this post | permalink
@GossiTheDog Forgive my ignorance, what is nom?
this post | permalink
@cynicalsecurity @jeroen "I don't understand what exactly happened last night on LinkedIn, but I know it is dark and sad and reeks of unfulfilled wants. The executive sat before me has been marketed to."

https://ludic.mataroa.blog/blog/brainwash-an-executive-today/
this post | permalink
@GossiTheDog 1) 3000 is not a big number on the Internet (quality matters though) 2) This is an overestimation because not all keys are useful (as the captured text also implies)

I haven't touched ASP.NET for a while, but I'd risk to say that app configuration also affects exploitability as i) not all apps rely on signed ViewState (IIRC) ii) deserialization gadgets are not universal.

These are of course solvable problems, but still need to be taken into account for risk assessment.
this post | permalink
@GossiTheDog That is technically true, but scanners already look for exposed web.configs, so any affected, but not already exploited Internet-facing sites would be simultaneously extremely negligent and lucky.

https://github.com/projectdiscovery/nuclei-templates/blob/2390fd195ab00f2bb1142dd27ac2ab888622d9bd/http/exposures/configs/web-config.yaml#L22
this post | permalink
@GossiTheDog The dangers of exposing ViewState encryption keys (or encryption oracles) were popularized at least by 2010 because of the padding oracle fixed with MS10-070:

https://web.archive.org/web/20101225182433/http://netifera.com/research/poet//PaddingOraclesEverywhereEkoparty2010.pdf

Similar attacks can be executed against frameworks that also protect stateless session data with encryption/MAC's, see CVE-2018-15133 of Laravel:

https://mogwailabs.de/en/blog/2022/08/exploiting-laravel-based-applications-with-leaked-app_keys-and-queues/

We've been hunting for web.config's during pentests too - the latest exploit I remember must've been written around last December by teammate based on a file read vuln exposing web.config.

So yeah, don't expose your private keys... If you do, that's not the problem of the crypto system (or ASP.NET in this case).
this post | permalink
[RSS] CVE-2024-55957: Local Privilege Escalation Vulnerability in Thermo Scientific(TM) Xcalibur(TM) and Foundation software

https://tierzerosecurity.co.nz/2025/02/07/cve-2024-55957.html
this post | permalink
Status: after two days of intensive calculation the whopping 1MB CalDAV import failed somewhere between 87-100% and I have no clue what was done and what needs to be fixed. #Thunderbird

Fortunately I found a solution that did the job in 5 mins at server-side:

https://www.reddit.com/r/selfhosted/comments/jbnu1l/how_would_i_push_an_ics_to_a_caldav_server/
this post | permalink
Here are the differences in the generated documentation:

https://gist.github.com/v-p-b/c148f7e41d922682e89e57feccedec24
this post | permalink
Next Page