A reminder that upgrading your server might shut down parts of the security related components and leave services unintentionally exposed.
Upgrading should not be done without proper filtering of unwanted incoming traffic (via for example a firewall in front of the server).
Here we can see some database passwords and cryptographic secrets exposed during #debian13 upgrade due to PHP being down while the httpd was not.
#infosec #cybersecurity
@jerry It largely depends on how well the initial impact is cleaned up. I'm hoping we won't see a ton of backdoors in various components next.
The httpget 0.2 doesn't quite work in the form it was uploaded.
First it uses hardcoded argv, argc instead of getting from the app invocation (as args in main, the code uses void main).
Second obtaining any data from the socket will result in the app stopping and leaving behind an empty file (if (nread) break;).
This program could never download anything. It is likely some work in progress or modified test version of httpget. Since it includes some windows specific headers and has disabled the unix ones I can only presume it was some earlier attempt to get the tool running on windows.
So while the code has a local stack buffer overflow it can't be triggered for this early version.
If this trend continues, we will be losing the ability to use secure means of communication with UK friends and colleagues. For example, #signalapp will rather get out of the UK than add backdoors: https://www.bbc.com/news/technology-64584001
"#Nordnet admits that it was possible to trade in other people's depots during the IT breakdown"
#Nordnet services appear to be back.
Nordnet has a lot of technical issues to sort out. If the malfunction allowed unauthorized parties to operate the accounts it will be quite messy to sort out.
Among with technical part, they will have to deal with the regulatory issues, in particular the Financial Supervisory Authority. They will demand answers.
@SatyrSack@feddit.org Curl will likely address this eventually even though they don't consider it a vulnerability. See https://github.com/curl/curl/issues/16197
The latest curl version 8.12.0 (released today) is affected.
The details of the #AMD Microcode Signature Verification #Vulnerability are out:
#infosec #infosecurity #cybersecurity
The company doing this is https://www.n-able.com/ - here's are the details: https://sintonen.fi/advisories/n-able-ecosystem-agent-improper-certificate-validation.txt
...except for the PoC exploit which is insanely simple to pull off. Anyone with #mitmproxy and half a brain can do it.
So what could you do if the microcode signature verification can be bypassed? While not directly applicable, this #defcon presentation "DEF CON 31 - Backdoor in the Core - Altering Intel x86 Instruction Set at Runtime - Krog, Skovsende" gives some ideas: https://www.youtube.com/watch?v=Zda7yMbbW7s
Post mortem:
This issue was made possible by a misconfiguration whereas "AllowOverride none" was used by accident. That made it possible to read the configuration file even though .htaccess file preventing it is in place.
So this in part this specific issue was a mistake by the admin (read: myself). I think it still highlights an issue that could occur in many other ways as well. It is best to restrict network access to servers when upgrading them.
PS: If you can't do things right at least make it possible for others to learn from your mistakes. π