This Message Is From an External Sender
This message originates outside of MITRE. If you feel this is suspicious, please report it via "Report Suspicious Email" button in Outlook.
> * By default it uses an external network connection that is NOT authenticated or encrypted. Network connections should be authenticated & encrypted (e.g., TLS, SSH, etc.). If a user specifically requests it (e.g., non-default config or "http://") that's fine, but if it's unspecified, it must be authenticated & encrypted. Protocols like telnet (port 80) should only work if the user specially configured it. > On Jan 10, 2024, at 1:05 AM, Kurt Seifried <[email protected]> wrote: > One comment: it's not always up to users, e.g. I'm just clicking links, I still occasionally run across http:// stuff, it's not like I want to use it... I would suggest it's time to draw a line in the sand on this topic, especially for http/https. I agree, this will come up often, so this is the kind of detail it would be wise to gain agreement on (if possible). In this case I think we have 2 users, the one using the link (e.g., by clicking on the link) and the one who specified the protocol ("http://" in this case). I'd be willing to accept that if someone *expressly* says they want the recipient to use the insecure protocol ("http://"), then it's okay to use it *because* that was what was expressed. In this case, the problem isn't that the *browser* used http (that's what it was told to do), the problem is that http was specified at all (so the "insecure default" vulnerability would charged against the website that specified http:). If we're going to claim it's a security vulnerability to use http on the public web, then the fault would be whoever stated that http was to be used. I can see a counter-argument, that is, web browsers shouldn't support http at all, and/or should always try to use https even when http is specified, and then only back down if https fails to work when given an http link & they have no HSTS or similar information suggesting that https should be used. It's a tricky situation, and I can see good arguments either way. I could be easily swayed one way or another right now. > * It has a default password that's known to anyone other than that specific user. it's fine for a system to request a password on startup, or have a unique password set per instance, but a default password shared among instances is insecure. > I would also make sure that the password that is uniquely set is not predictable, e.g. some devices use the hardware MAC address as the password: > > https://www.qnap.com/en-in/how-to/faq/article/default-password-of-admin-is-changed-to-first-mac-address-after-qts-4-4-2 > > So if the attacker is on the LAN... or device makers use known ranges of MAC addresses .. which they do... Fair enough. "Default password" was an example of a bad default, and "default password" is a special case of the more general bad default "predictable password". > * Uses a known insecure algorithm for security purposes, e.g., MD5 or SHA-1 or DES as a security mechanism. Non-security uses are fine. > Can you define security/non security? Overall, "Security requirements can be broken by available computing capabilities". DES is a symmetric encryption algorithm, its 56-bit key is so short it's vulnerable to brute force breaking. Cryptographic hash functions must meet 3 criteria that MD5 & SHA-1 no longer meet, e.g. https://duo.com/decipher/sha-1-fully-and-practically-broken-by-new-collision https://shattered.io/ --- David A. Wheeler
