3 ms·

>>>> Probably because there's no demand for it - people who care about security don't use windows. I actually DO care about security and go to great lengths t

>>>> Probably because there's no demand for it - people who care about security don't use windows. I actually DO care about security and go to great lengths to secure my Windows 8.1 laptop and several physical Windows 2012 servers I maintain. If you know anything about security, it's actually pretty easy to secure a Windows machine. One of the main reasons I'm stuck with MS is because there are no Adobe products available on Linux. The alternatives suck donkey balls and I hate Apple (too long of a story to get into here). Thus, I use Windows. Full disclosure, I have several Linux boxes running Mint and an Ubuntu server and I'm actually quite fond of Linux. Unfortunately, a majority of my development is done with Adobe tools so I'm stuck. Give me a decent set of dev tools that mimic my Adobe tools (Fireworks, Illustrator (not Inkscape), Photoshop (not GimpShop), InDesign and now their Edge tools) and I'd drop MS in a heartbeat go 100% Linux.

riskable 13y ago
If you know anything about Windows security you will know that it is completely broken by default and there's no workarounds. I know, I know, "Citation Needed". Here you go: > Neither the NT hash nor the LM hash is salted. Salting is a process that combines the password with a random numeric value (the salt) before computing the one-way function. Windows has never stored hashes in human-readable form, so there has never been a need to salt them. Taken from Microsoft's own documentation: http://bit.ly/1juRmCT http://bit.ly/1juRmCT (Using Bitly because the link has parens and HN sometimes doesn't like that). Microsoft's argument boils down to this: Because they don't provide a GUI to view password hashes they're secure! People gave LinkedIn and Adobe crap for their leaked password dumps not using a salt (or using reversible encryption!) and yet here we have MILLIONS of Windows installations all over the world doing the same damned thing. What's worse is that Active Directory also doesn't store password hashes using a salt. If your domain admin credentials ever get stolen the attacker is mere minutes away from cracking every damned password. For giggles, here's a tool you can use to dump not only your saltless Windows password hashes but the actual passwords. This is because Microsoft also uses a reversible encryption scheme: http://blog.gentilkiwi.com/mimikatz http://blog.gentilkiwi.com/mimikatz
- quasque 13y ago
  > For giggles, here's a tool you can use to dump not only your saltless Windows password hashes but the actual passwords. This is because Microsoft also uses a reversible encryption scheme: http://blog.gentilkiwi.com/mimikatz http://blog.gentilkiwi.com/mimikatz The passwords it displays (using the "sekurlsa" module) are from probing the process memory of LSASS.EXE to view cached credentials. So it will only display the plaintext credentials of currently logged in users.
  - ThatGeoGuy 13y ago
    I can't speak for the guy you're quoting, but I'm sure this is relevant in the context of software you mistakenly trust executing such code. Naturally, if you're not logged in, there's less vulnerabilities to worry about. Hell, I can disconnect the power source if I'm after that kind of security. However, this is actually an important exploit / factor to be aware of if you're considering installing software securely on a platform. Is it possible to blast through account credentials with a small method like this? I certainly wouldn't want to run any scripts on my machine if I knew that was possible on Linux, because merely being on the sudoers list would mean that my credentials are enough to damage my entire workstation. This doesn't even speak to the effect this would have if you got access to a sysadmin's account on a large network.
    - riskable 13y ago
      You're exactly right: This is a huge vulnerability in Windows and the really important part is that it's an architecture vulnerability. Meaning, to fix it would require changes to how Windows works at a fundamental level in such a way as to break backwards compatibility (which is sacrilege in Microsoft land). Consider for a moment all the tools and mechanisms in place to synchronize Active Directory passwords across domains, realms, and even 3rd party systems. Every one of those would completely break if you were to implement simple change such as the use of a salt. That's why I've been saying for many years now that, "if you care about security do not use Windows." There's no mechanism available to actually make it secure because you can't change how it works internally. The best you can hope for is some obfuscation/hacks/tricks in regards to hardening (e.g. rename Administrator account, use entirely different credentials for administrative tasks, disable zillions of insecure defaults, etc). Then just hope you're never targeted. If just one workstation is compromised an attacker can elevate their privileges to that of Domain Administrator with a few simple steps: 1. Install keylogger or password-dumping tool. 2. Force workstation to unjoin from the domain or cause some other problem that requires a Domain Admin to login to correct the issue. 3. Use credentials of Domain Admin to access a Domain Controller. 4. Dump the entire password database of Active Directory. 5. Crack the password database using some GPU instances in minutes. After step #2 the attacker basically "owns" your network and can do whatever they want. You can mitigate it by joining Windows workstations using credentials that only have the power to perform a join but this is usually just a minor setback for an attacker as there's a plethora of tools and tricks they can take advantage of to escalate to Domain Admin. For more information on how easy all this is: http://pentestmonkey.net/uncategorized/from-local-admin-to-domain-admin http://pentestmonkey.net/uncategorized/from-local-admin-to-d...
greg0ire 13y ago
Maybe you could run these Adobe tools in a Virtual Machine ?

riskable 13y ago

If you know anything about Windows security you will know that it is completely broken by default and there's no workarounds. I know, I know, "Citation Needed". Here you go: > Neither the NT hash nor the LM hash is salted. Salting is a process that combines the password with a random numeric value (the salt) before computing the one-way function. Windows has never stored hashes in human-readable form, so there has never been a need to salt them. Taken from Microsoft's own documentation: http://bit.ly/1juRmCT http://bit.ly/1juRmCT (Using Bitly because the link has parens and HN sometimes doesn't like that). Microsoft's argument boils down to this: Because they don't provide a GUI to view password hashes they're secure! People gave LinkedIn and Adobe crap for their leaked password dumps not using a salt (or using reversible encryption!) and yet here we have MILLIONS of Windows installations all over the world doing the same damned thing. What's worse is that Active Directory also doesn't store password hashes using a salt. If your domain admin credentials ever get stolen the attacker is mere minutes away from cracking every damned password. For giggles, here's a tool you can use to dump not only your saltless Windows password hashes but the actual passwords. This is because Microsoft also uses a reversible encryption scheme: http://blog.gentilkiwi.com/mimikatz http://blog.gentilkiwi.com/mimikatz

quasque 13y ago
> For giggles, here's a tool you can use to dump not only your saltless Windows password hashes but the actual passwords. This is because Microsoft also uses a reversible encryption scheme: http://blog.gentilkiwi.com/mimikatz http://blog.gentilkiwi.com/mimikatz The passwords it displays (using the "sekurlsa" module) are from probing the process memory of LSASS.EXE to view cached credentials. So it will only display the plaintext credentials of currently logged in users.
- ThatGeoGuy 13y ago
  I can't speak for the guy you're quoting, but I'm sure this is relevant in the context of software you mistakenly trust executing such code. Naturally, if you're not logged in, there's less vulnerabilities to worry about. Hell, I can disconnect the power source if I'm after that kind of security. However, this is actually an important exploit / factor to be aware of if you're considering installing software securely on a platform. Is it possible to blast through account credentials with a small method like this? I certainly wouldn't want to run any scripts on my machine if I knew that was possible on Linux, because merely being on the sudoers list would mean that my credentials are enough to damage my entire workstation. This doesn't even speak to the effect this would have if you got access to a sysadmin's account on a large network.
  - riskable 13y ago
    You're exactly right: This is a huge vulnerability in Windows and the really important part is that it's an architecture vulnerability. Meaning, to fix it would require changes to how Windows works at a fundamental level in such a way as to break backwards compatibility (which is sacrilege in Microsoft land). Consider for a moment all the tools and mechanisms in place to synchronize Active Directory passwords across domains, realms, and even 3rd party systems. Every one of those would completely break if you were to implement simple change such as the use of a salt. That's why I've been saying for many years now that, "if you care about security do not use Windows." There's no mechanism available to actually make it secure because you can't change how it works internally. The best you can hope for is some obfuscation/hacks/tricks in regards to hardening (e.g. rename Administrator account, use entirely different credentials for administrative tasks, disable zillions of insecure defaults, etc). Then just hope you're never targeted. If just one workstation is compromised an attacker can elevate their privileges to that of Domain Administrator with a few simple steps: 1. Install keylogger or password-dumping tool. 2. Force workstation to unjoin from the domain or cause some other problem that requires a Domain Admin to login to correct the issue. 3. Use credentials of Domain Admin to access a Domain Controller. 4. Dump the entire password database of Active Directory. 5. Crack the password database using some GPU instances in minutes. After step #2 the attacker basically "owns" your network and can do whatever they want. You can mitigate it by joining Windows workstations using credentials that only have the power to perform a join but this is usually just a minor setback for an attacker as there's a plethora of tools and tricks they can take advantage of to escalate to Domain Admin. For more information on how easy all this is: http://pentestmonkey.net/uncategorized/from-local-admin-to-domain-admin http://pentestmonkey.net/uncategorized/from-local-admin-to-d...

greg0ire 13y ago

Maybe you could run these Adobe tools in a Virtual Machine ?