GitHub - compr00t/CVE-2024-42327: PoC for CVE-2024-42327 / ZBX-25623 PoC for CVE-2024-42327 / ZBX-25623. Contribute to compr00t/CVE-2024-42327 development by creating an account on GitHub.

So here is my #PoC for #CVE-2024-42327, that actually exploits the vulnerability in order to test if you are vulnerable or not: github.com/compr00t/CVE...

Well, Easytax is a local application and the vulnerability is a client-side XXE, only exploitable locally as correctly declared by the researcher with a CVSS score of 4.6 and AV:L (CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/SC:L/SI:N/SA:L) in CVE-2024-9044.

But hey, easy news, right? (2/2)

Swiss news talked all day long about a vulnerability in Kanton Aargau‘s tax software Easytax today: „No malicious activity was detected in an immediate post-mortem analysis“ or „no data was accessed by an attacker at any point in time“. One could conclude, that sounds quite alarming, right? (1/2)

https://linpeas.sh ownership · Issue #450 · peass-ng/PEASS-ng The linpeas.sh version hosted at https://linpeas.sh is sending info to a remote server: curl -s "https://log.linpeas.sh/?uuid=$(cat /proc/sys/kernel/random/uuid)&id=$(cat /var/lib/dbus/machine-id)&...

It seems that linpeas[.]sh is hosting a modified version of linpeas with an additional line of code making callbacks to a logging endpoint. Not really malicious though - maybe a researcher showcasing why you should always properly check the sources of your tooling?

github.com/peass-ng/PEA...

The #sneakpeek as a video (as you posted it on LinkedIn) looks way more promising than as a picture here 😅

A great example why you should always pin your VPN server endpoints

fully agree. and if never heard of your idea, this would drive me crazy for sure. But as more it get‘s known, the less harder I have to think ;-)

and you are right, in that case I would fight the WAF first, but how is that different from a classical WAF that responds with RST? I need to bypass that as well before I can exploit anything.

For example a legit search request that returns some data. As long as I get the data as a response, the app runs properly. So if I expect stability issues, I would resend the legit request and if data is returned, something is off but def. no stability issue

If I wanna find vulnerabilities, I could still do that. I can not relay on response codes but can still try to exploit something and if I receive a response similar to the baseline, I bypassed the WAF successfully.

well for example if I get a 5xx error, I would initially assume stability issues. I would then send the correct request and would expect to get a response similar to the baseline, right?

not sure about the idea, could be quite fun but once this gets known, it should be rather easy to detect with a bit of baselining as the legit request still has to work reliably…

I like #AI chatbots... I asked Microsoft Ignite's #chatbot (who dared me to ask anything about Microsoft Ignite) about the program and it pointed me to an URL for the UAT environment. What could possibly go wrong?

(don't worry, the UAT is not publicly accessible - as it should be for reasons!)