Dice.camp

0 posts0 participants0 posts today

0x40kOh man, Fortinet *yet again*! 😅 A symlink bug that *still grants* read-only access even after updates? Seriously, that's my kind of 'funny'! 😂It just goes to show how crucial manual testing really is. You know, the kind of thing automated scans often just don't catch. Our clients are *always* relieved when we spot these things before a malicious actor does! 👌So yeah, updates are vital, but *don't forget* to double-check those configs! Otherwise, attackers might still have a foothold, even after you've 'patched'.Just remember: Security isn't just a product you buy; it's an ongoing process. And let's be real, it also needs to fit the budget. 🤷‍♂️What persistence tricks do you all have up your sleeve? 🤔<a href="https://infosec.exchange/tags/Pentest" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Pentest</a> <a href="https://infosec.exchange/tags/Fortinet" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fortinet</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://infosec.exchange/tags/OffensiveSecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#OffensiveSecurity</a> <a href="https://infosec.exchange/tags/InfoSec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#InfoSec</a>

XenoPhage :verified:Why is it that Home Depot has passkey support and my bank still wants me to answer those three questions?<a href="https://infosec.exchange/tags/security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#security</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://infosec.exchange/tags/FacePalm" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#FacePalm</a>

Suzanne Aldrich (she/her)Critical Next.js Middleware Vulnerability (CVE-2025-29927)A major auth bypass vulnerability in Next.js middleware (prior to v14.2.25 / v15.2.3) allows attackers to inject the x-middleware-subrequest header and bypass authorization entirely. Exploitable via simple HTTP requests—no user interaction, no special permissions.Patch. Now. Or block the header manually.GitHub scored this 9.1 CRITICAL, but the real issue? This flaw exposes a systemic weakness in middleware validation, and some vendors weren’t exactly upfront about the risks.Details + POC: <a href="https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-auth-bypass" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-auth-bypass</a> NVD: <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-29927" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://nvd.nist.gov/vuln/detail/CVE-2025-29927</a>Security theater is easy. Secure defaults and transparency are harder—but essential.<a href="https://hachyderm.io/tags/infosec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#infosec</a> <a href="https://hachyderm.io/tags/AppSec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#AppSec</a> <a href="https://hachyderm.io/tags/NextJS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#NextJS</a> <a href="https://hachyderm.io/tags/CVE202529927" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CVE202529927</a> <a href="https://hachyderm.io/tags/middleware" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#middleware</a> <a href="https://hachyderm.io/tags/securityfail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#securityfail</a>

Todd A. Jacobs | Pragmatic CybersecurityThis isn't Apple's fault, as it still has to follow local laws to sell its products. However, this is a huge <a href="https://infosec.exchange/tags/securityfail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#securityfail</a>.Even though Apple no longer fights for mindshare in the enterprise computing market as it once did, this will force companies that require secure data to either avoid iCloud-enabled apps altogether—which can be hard to do on a Mac—or stop using Macs altogether for anything that processes <a href="https://infosec.exchange/tags/PII" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PII</a>, <a href="https://infosec.exchange/tags/PHI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#PHI</a>, or even proprietary <a href="https://infosec.exchange/tags/sourcecode" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#sourcecode</a>. In particular, many <a href="https://infosec.exchange/tags/softwaredevelopers" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#softwaredevelopers</a> prefer <a href="https://infosec.exchange/tags/MacBooks" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MacBooks</a> since they offer a mainstream user experience but run <a href="https://infosec.exchange/tags/Unix" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Unix</a> under the hood. If they can't use MacBooks anymore for security reasons, companies will have to rethink some of their long-standing laptop and desktop <a href="https://infosec.exchange/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cybersecurity</a> practices.<a href="https://www.bbc.com/news/articles/cgj54eq4vejo" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.bbc.com/news/articles/cgj54eq4vejo</a>

Frank FilipponeWas slightly amused earlier today when looking at Task Manager on a Windows server and found a properly ancient version of TeamViewer running on it.Did I mention this server has direct internet access?And is part of the security system for this site?<a href="https://aus.social/tags/it" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#it</a> <a href="https://aus.social/tags/itsecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#itsecurity</a> <a href="https://aus.social/tags/securityfail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#securityfail</a>

🅰🅻🅸🅲🅴 (🗑️🔥)I know I'm late to the NPD-bashing party, but the complete disregard for other's privacy they've shown warrants another go at them.The fact that these companies buy, scrape, and steal our data, then compile it into a dox-bomb and secure it behind a "do not breach k thx" high-security post-it note, just fucking riles me.And because it's "publicly available" data, the repercussions of any breach typically amount to having to write a whoopsie apology email and maybe offer an identity scraping—er protection—subscription.It blows my mind that these parasites are legal-ish businesses. They basically provide doxxing as a service.<a href="https://infosec.exchange/tags/NPD" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#NPD</a> <a href="https://infosec.exchange/tags/Data" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Data</a> <a href="https://infosec.exchange/tags/Breach" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Breach</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Asta McCarthy<a href="https://mastodon.nl/@AlmereSP" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@AlmereSP</a> Want USA "publieke"cloud bedrijven zijn echt de enige die veilig een mailserver kunnen draaien :blobfacepalm: <a href="https://arstechnica.com/information-technology/2024/04/microsoft-blamed-for-a-cascade-of-security-failures-in-exchange-breach-report/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://arstechnica.com/information-technology/2024/04/microsoft-blamed-for-a-cascade-of-security-failures-in-exchange-breach-report/</a> <a href="https://mastodon.pirateparty.be/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> <a href="https://mastodon.pirateparty.be/tags/cloud" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cloud</a> <a href="https://mastodon.pirateparty.be/tags/cascadefailures" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cascadefailures</a> <a href="https://mastodon.pirateparty.be/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Andres SI installed <a href="https://social.ridetrans.it/tags/LibreElec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#LibreElec</a> on a pi4. During setup, it asked if I wanted to enable sshd (which, like, *of course* I do).Then it told me the default login and password, and suggested that I change the password. Okay, sure, good idea. I tried a shared, memorable password I use for home appliance devices (NAT'd & only accessible via sudo, as I use ssh keys). "Password too weak", and it didn't allow it. I tried two other passwords, both rejected. So I left it at the default. <a href="https://social.ridetrans.it/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Asta McCarthy<a href="https://mastodon.online/@bartgroothuis" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@bartgroothuis</a> Security by obscurity is een slecht idee. <a href="https://mastodon.pirateparty.be/tags/opensource" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#opensource</a> werken en onafhankelijke code reviews zijn een veel veiligere aanpak. <a href="https://mastodon.pirateparty.be/tags/microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#microsoft</a> <a href="https://mastodon.pirateparty.be/tags/securityfail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#securityfail</a>

Emelia 👸🏻This form here transmits your encryption key to Backblaze's servers, but they pinky promise never to use it or store it. <a href="https://hachyderm.io/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://hachyderm.io/tags/Security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Security</a> <a href="https://hachyderm.io/tags/Backblaze" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Backblaze</a>

Emelia 👸🏻I'm trying out Backblaze for backups, and setup an encryption key. Turns out if you ever use the “View/Restore Files" feature on their website, they send the full encryption key to their remote server.Which completely and absolutely defeats the point of the encryption key, because now they have a copy of the encryption key.<a href="https://hachyderm.io/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://hachyderm.io/tags/Security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Security</a> <a href="https://hachyderm.io/tags/Backblaze" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Backblaze</a>

C.Bank emails: Never click links in emails claiming to be from us, your bank! It's not safe.Also Bank emails: To complete this transaction, click this link.<a href="https://mindly.social/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://mindly.social/tags/security" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#security</a> <a href="https://mindly.social/tags/fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#fail</a> <a href="https://mindly.social/tags/stupidity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#stupidity</a> <a href="https://mindly.social/tags/idiocy" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#idiocy</a> <a href="https://mindly.social/tags/email" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#email</a> <a href="https://mindly.social/tags/scam" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#scam</a>

Claudius LinkMoving on to <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> <a href="https://infosec.exchange/tags/Guidance" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Guidance</a> in generalMicrosoft offers the following Password Guidance <a href="https://www.microsoft.com/en-us/research/publication/password-guidance/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.microsoft.com/en-us/research/publication/password-guidance/</a>Side note, the PDF contains no (visible) version information or date :-( Please, if you publish guidance, especially if you are an influential company, include a date in your documents. I treat a guidance form 2016 differently than a guidance from 2023Back to the recommendations. Most of the are solid but some stick out1. Maintain an 8-character minimumThat seem awfully short. <a href="https://infosec.exchange/tags/NIST" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#NIST</a> states "Longer is better", the <a href="https://infosec.exchange/tags/HPI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#HPI</a> recommends 15+ characters and, wait for it, Microsoft themself recommends 12 or better 14+ characters.4. Ban common passwords, to keep the most vulnerable passwords out of your system.The <a href="https://infosec.exchange/tags/NIST" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#NIST</a> recommendation check against "commonly used and compromised passwords" considerably extends this!Microsoft at other places recommends "Not a word that can be found in a dictionary or the name of a person, character, product, or organization."5. Educate your users not to re-use their password for non-work-related purposes.Work related reuse is OK????I would love to know if <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> internally really follows these password rule. Or if they enforce a stricter set. If anyone knows about this, please let me know (but don't if this would get you fired)BTW, the other place where Microsoft recommends a different/stronger set of password rules is here (again no date): <a href="https://support.microsoft.com/en-us/windows/create-and-use-strong-passwords-c5cebb49-8c53-4f5e-2bc4-fe357ca048eb" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://support.microsoft.com/en-us/windows/create-and-use-strong-passwords-c5cebb49-8c53-4f5e-2bc4-fe357ca048eb</a><a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Claudius LinkSome more context to my rant about the shortcomings of <a href="https://infosec.exchange/tags/EntraID" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#EntraID</a> <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Protection:1. The risk is greatly reduced if you use <a href="https://infosec.exchange/tags/MFA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#MFA</a> BUT while I'm not sure if <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> enforces MFA they enforce the weak password rules. And a recent event caused me to reevaluate my assumption on how well know <a href="https://infosec.exchange/tags/2FA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#2FA</a>/MFA really is:I gave <a href="https://infosec.exchange/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#cybersecurity</a> talk to non-IT people (still technical so) and closed it with a set of recommendation. One was to enable Second Factor Authentication wherever possible. Which lead to the question from one participant "What is Second Factor Authentication"That was quite a 😵 moment. I had the wrong assumptions. How can I assume that MFA reduces a risk if many people don't know about it.<a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Claudius LinkOne more thingAnother shortcoming of <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> <a href="https://infosec.exchange/tags/EntraID" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#EntraID</a> <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Protection, I can't wrap my head around:They recommend to not mandate regular password changes (good) BUT they check the password against known bad passwords ONLY when changing it!So, to detect weak passwords I have to enforce a password change which is (rightfully) not recommended 🤡You could simply do this on entry. Every time (or once a day) the user enters the password it is checked if it isn't well known and complies to the current rules.<a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Claudius LinkSleeping over it I noticed another issue with <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> <a href="https://infosec.exchange/tags/Entra" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Entra</a> ID <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Regarding the Global banned password list they write "The contents of the global banned password list aren't based on any external data source, but on the results of Microsoft Entra security telemetry and analysis." (<a href="https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad</a>)Now I have more questions:WHY are passwords part of the security telemetry data?The only case where I see this as ok, would be in a honeypot.And what kind of data would be in the security telemetry data? Usually it's failed attempts, so you risk overestimating passwords attacks which fail (anyway). Again, this would only be OK with honeypots.But if you are getting your data solely from honeypots, I fear you're getting a pre-selected type of data. Namely opportunistic, random attacks not targeted attacks.While I think it's valuable to protect against these kind ob attacks, I really would like passwords to withstand even targeted attacks, even from the inside. E.g when the attackers are in the Lateral Movement or Privilege Escalation. Especially if the attackers can start to crack hashes.For this Microsoft Entra ID Password Protection seems completely useless there.<a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Claudius LinkAnd the Custom banned password list of <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> <a href="https://infosec.exchange/tags/EntraID" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#EntraID</a> <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Protection just continues the joke.First, it can only contain 1000 entries. And yes, I really don't want to manage a big custom list.And it gets even worse. The list is intended to contain company specific banned words like brand or product names, company-specific internal terms as well as abbreviations. Entries must be at least 4 characters. WTF, half the companies I worked for had 3 letter names. And there are many other BWM, KIA, SAP, IBM, GM, BBC, NBA, NFL, UPS, DHL, ...And don't get me started on acronyms. <a href="https://infosec.exchange/tags/TLA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#TLA</a> (Three-Letter-Acronym) is a term for a reason.This means, taking my current company as an example, that SMA12 would be an accepted password (if it would be for the length) because 'SMA' 3 points + '12' 2 points is 5 points).To reach the necessary length you could simply combine it. E.g. 'SMASolar1' would be an accepted password even if 'Solar' was a banned word.And I CAN'T do ANYTHING!!!Or at least not anything sensible. If I start to put combinations of 'SMA*' in the custom banned pw list, I'm back at an inadequate big list I have to manage myself 🤮.And even then SMASolar1234 stays valid 🤬 <a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> Call for <a href="https://infosec.exchange/tags/Help" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Help</a>: I would be very happy if someone can show me that I'm wrong. The state of Microsoft Entra ID Password Protection is a MUCH bigger pain than that I would have been wrong 😜.

Claudius LinkI'm not sure if I get something wrong, but I think <a href="https://infosec.exchange/tags/Microsoft" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microsoft</a> <a href="https://infosec.exchange/tags/EntraID" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#EntraID</a> <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Protection is complete rubbish. E.g. when ban weak passwords with the ominous 5 points rule the results seem to be completely arbitrary.Microsoft speaks of including commonly used weak or compromised passwords in their Global banned password list. But the list isn't based on any external data source, so leaked passwords not leaked by Microsoft are not included 🤡.This leads to: Known leaked passwords are accepted. Location name plus year is accepted. Dictionary word plus year is accepted!!!Not sure if this applies only to German dictionary words.It gets even worse. Reading the documentation, I found "Characters not allowed: Unicode characters" WTF Coming back to the weird point system. A banned password is not really banned, it gives you "only" 1 point (and you need five).This leads to the question how many points do none-banned words give?If you think it can't get worse, you're wrong! It looks like each character of a none-banned word gives one point. Meaning "password1234" is an accepted password. (1 point for password and 4 for each digit)Or a real-life example: The <a href="https://infosec.exchange/tags/SolarWInds" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SolarWInds</a> <a href="https://infosec.exchange/tags/SupplyChain" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SupplyChain</a> attach which affected Microsoft, US government agency and countless other organizations worldwide, was cause by a weak FTP server password. Namely "solarwinds123", which would be accepted by <a href="https://infosec.exchange/tags/EntraID" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#EntraID</a> <a href="https://infosec.exchange/tags/Password" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Password</a> Protection (1 point each for "solar" and "wind", 3 points for the numbers. If "solarwinds" would be on the custom banned list, "solarwind1234" would have been enough.And you can't do anything against it.I actually hope that the documentation is somewhat wrong and that "123" is not 3 points but just 1 point, as they are consecutive numbers. But this would make it only marginal better (2023<a href="https://infosec.exchange/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Cybersecurity</a> <a href="https://infosec.exchange/tags/Fail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Fail</a> <a href="https://infosec.exchange/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

Stuart Longland (VK4MSL)<a href="https://social.taupehat.com/@me" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@me</a> <a href="https://m.ai6yr.org/@ai6yr" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@ai6yr</a> Not only is that a denial-of-service vulnerability… but if it then came to "trust" that "face"… anyone could defeat your security system by buying and wearing an identical T-shirt.<a href="https://mastodon.longlandclan.id.au/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a>

T.M. BaumgartnerAnyone have a preferred method for physically disabling the microphone on an indoor security camera? (Wansview Q5)I have the microphone turned off according to the app, but I'm getting audio feedback when I have the app running in the same room as the camera, so... I don't think it's really off.Would polymer clay in the hole do the trick?<a href="https://mstdn.social/tags/Wansview" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Wansview</a> <a href="https://mstdn.social/tags/SecurityFail" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SecurityFail</a> <a href="https://mstdn.social/tags/Microphone" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Microphone</a>

Recent searches

Search options

Administered by:

Server stats:

#securityfail