8 ms·

> Another interesting fact is that ADS names can contain symbols which are normally forbidden for filenames like ” or * OK, this is going to completely mess up

> Another interesting fact is that ADS names can contain symbols which are normally forbidden for filenames like ” or * OK, this is going to completely mess up all of my (and most likely everyone else's) shell scripts. I always assume these characters cannot legally occur on Windows anywhere in the path... _________________________________________ And wow, this is quite clever and also quite difficult to foresee: > The best security vulnerability to explain directory junctions is in my opinion AVGater, where the attacker places a file in folder x. Then he marks the file as a virus and the installed AntiVirus solution will move it into the quarantine. After that the attacker removes the folder x and replaces it with a directory junction named “x” which points to C:\windows\System32\. If the attacker now clicks on the “restore” button the AntiVirus solution will copy the file to the x folder which now points to system32 with SYSTEM privileges (which directly leads to EoP).

quietbritishjim 8y ago
For that second one: That sounds like a vulnerability in virus scanners even without junctions, although junctions make it enormously easier to exploit: * Create a directory in a location you have permission to, but you think a higher-privilege user will create it later. * Create and quarantine a file in it. * Delete the directory. * When the higher privilege user creates the directory, you can restore your file into it. The fix is for virus scanners to operate at user permission level when restoring the file.
- zaat 8y ago
  > The fix is for virus scanners to operate at user permission level when restoring the file. "user permission" as such doesn't exist, it is always a specific user. Which user should the restore function run as? There is no easy solution to this, as the restore must be able to restore the file to locations like the windows directory as well as directories that only specific user have access to, like a home folder on a file server.
  - quietbritishjim 8y ago
    > Which user should the restore function run as? The one that clicks the "restore" button. > the restore must be able to restore the file to locations like the windows directory Then the user will need to get the help of someone with an admin account i.e. their IT department (they probably have an admin account themself if it's a home computer). If this happened regularly it would be a problem, but how often do virus scanners false positive on system files and users quarantine them? I would bet not very often.
    - giancarlostoro 8y ago
      Problem might be that whoever is clicking restore is likely running that software as an admin thereby the user clicking restore is the admin user. I'm not 100% sure though, but I think that's the behavior. Edit: Found this[0] to clarify what happens when you run software as UAC. I can imagine an A/V program needs admin privileges to run altogether. [0]: https://msdn.microsoft.com/en-us/library/bb625963.aspx https://msdn.microsoft.com/en-us/library/bb625963.aspx
    - zaat 8y ago
      That will not solve the problem of writing to places an administrator can't write to: 1. Places where only SYSTEM have write access to (e.g. system32) 2. Places where only a specific user have access to (private folder in a file server share). An administrator won't be able to restore user's file without taking ownership on the folder.
- AnIdiotOnTheNet 8y ago
  Ok, let me ask: why? What is the absolute worst case scenario here? That a user in your organization gains admin privileges on their workstation? Nearly every org I've ever worked at already gave their users admin privileges because trying to do their job without it caused far more friction than any imaginary gains from locking them down. So they might screw up their OS, big deal, that's what imaging is for. It's not like ransomware needs admin privileges to ruin your day anyway. In fact, local admin does absolutely nothing for it since it will still only have permissions to the same network resources that the user does, and of course their local documents. There are some kiosk-style single-application appliance use cases out there where it makes sense to lock things down just to make sure the user isn't browsing reddit all day or something, but by their nature those are at low risk of being infected and you care even less about them than a workstation if they are. I honestly can't think of a realistic scenario in which this isn't a complete non-issue.
  - grkvlt 8y ago
    > Nearly every org I've ever worked at already gave their users admin privileges I assume you've never worked at a large retail or investment bank, or similar organisation, then? Admin privileges are never granted to ordinary users; to install new programs or perform administrative tasks requires a call to the helpdesk, and there is usually some form of remote management service running to handle updates and so on.
    - AnIdiotOnTheNet 8y ago
      Ok, but why? What does that actually accomplish?
      - KAMSPioneer 8y ago
        Just a few ideas off the top of my head: An attacker that gains SYSTEM permissions on a machine can dump the SAM database, which may contain credentials for domain or enterprise administrators. This is very bad. A user with administrator permissions can modify their DNS settings to avoid DNS-level filtering to block known malware domains. This can be bad. A malicious or ignorant user can disable or remove antivirus protection. This can be bad. A user can accidentally make a computer nonfunctional by, for example, deleting system files, perhaps because it was suggested (sarcastically) on a help forum ("LOL delete system32"). This is bad. I'm far from a security expert, but from a sysadmin perspective, every user having local admin privs is an absolute nightmare.
cryptonector 8y ago
Why would you make such assumptions? On Unix systems there is one and only one byte value that cannot appear in a directory or file name: ASCII '/'. Note that I say "byte value": the kernel and the filesystem driver have NO idea what local you're using in user-land, and they don't care. On Windows both '/' and '\' cannot appear, though as we can see here, ':' and others are problematic... In shell scripts you really have to quote every damned string. I really wish that instead of by default splitting words on $IFS and interpreting glob and other shell special characters, the default was that $varname has no such handling performed, and instead if you wish for this you'd have to write ${varname*} or something like that.
- mehrdadn 8y ago
  Because I'm talking about Windows and not Unix systems, and on for Windows systems, literally every piece of documentation I've seen has said that * < > : / etc. are invalid name characters.
  - cryptonector 8y ago
    Still, quote everything. Whitespace and other special characters are still a problem if you don't.
  - JdeBP 8y ago
    NTFS and the Native API had to support operating system personalities where these were perfectly legitimate characters to have in filenames, right from the start. It is the personalities like Win32 and 16-bit OS/2 that introduce the extra limitations.

quietbritishjim 8y ago

For that second one: That sounds like a vulnerability in virus scanners even without junctions, although junctions make it enormously easier to exploit: * Create a directory in a location you have permission to, but you think a higher-privilege user will create it later. * Create and quarantine a file in it. * Delete the directory. * When the higher privilege user creates the directory, you can restore your file into it. The fix is for virus scanners to operate at user permission level when restoring the file.

zaat 8y ago
> The fix is for virus scanners to operate at user permission level when restoring the file. "user permission" as such doesn't exist, it is always a specific user. Which user should the restore function run as? There is no easy solution to this, as the restore must be able to restore the file to locations like the windows directory as well as directories that only specific user have access to, like a home folder on a file server.
- quietbritishjim 8y ago
  > Which user should the restore function run as? The one that clicks the "restore" button. > the restore must be able to restore the file to locations like the windows directory Then the user will need to get the help of someone with an admin account i.e. their IT department (they probably have an admin account themself if it's a home computer). If this happened regularly it would be a problem, but how often do virus scanners false positive on system files and users quarantine them? I would bet not very often.
  - giancarlostoro 8y ago
    Problem might be that whoever is clicking restore is likely running that software as an admin thereby the user clicking restore is the admin user. I'm not 100% sure though, but I think that's the behavior. Edit: Found this[0] to clarify what happens when you run software as UAC. I can imagine an A/V program needs admin privileges to run altogether. [0]: https://msdn.microsoft.com/en-us/library/bb625963.aspx https://msdn.microsoft.com/en-us/library/bb625963.aspx
  - zaat 8y ago
    That will not solve the problem of writing to places an administrator can't write to: 1. Places where only SYSTEM have write access to (e.g. system32) 2. Places where only a specific user have access to (private folder in a file server share). An administrator won't be able to restore user's file without taking ownership on the folder.
AnIdiotOnTheNet 8y ago
Ok, let me ask: why? What is the absolute worst case scenario here? That a user in your organization gains admin privileges on their workstation? Nearly every org I've ever worked at already gave their users admin privileges because trying to do their job without it caused far more friction than any imaginary gains from locking them down. So they might screw up their OS, big deal, that's what imaging is for. It's not like ransomware needs admin privileges to ruin your day anyway. In fact, local admin does absolutely nothing for it since it will still only have permissions to the same network resources that the user does, and of course their local documents. There are some kiosk-style single-application appliance use cases out there where it makes sense to lock things down just to make sure the user isn't browsing reddit all day or something, but by their nature those are at low risk of being infected and you care even less about them than a workstation if they are. I honestly can't think of a realistic scenario in which this isn't a complete non-issue.
- grkvlt 8y ago
  > Nearly every org I've ever worked at already gave their users admin privileges I assume you've never worked at a large retail or investment bank, or similar organisation, then? Admin privileges are never granted to ordinary users; to install new programs or perform administrative tasks requires a call to the helpdesk, and there is usually some form of remote management service running to handle updates and so on.
  - AnIdiotOnTheNet 8y ago
    Ok, but why? What does that actually accomplish?
    - KAMSPioneer 8y ago
      Just a few ideas off the top of my head: An attacker that gains SYSTEM permissions on a machine can dump the SAM database, which may contain credentials for domain or enterprise administrators. This is very bad. A user with administrator permissions can modify their DNS settings to avoid DNS-level filtering to block known malware domains. This can be bad. A malicious or ignorant user can disable or remove antivirus protection. This can be bad. A user can accidentally make a computer nonfunctional by, for example, deleting system files, perhaps because it was suggested (sarcastically) on a help forum ("LOL delete system32"). This is bad. I'm far from a security expert, but from a sysadmin perspective, every user having local admin privs is an absolute nightmare.

cryptonector 8y ago

Why would you make such assumptions? On Unix systems there is one and only one byte value that cannot appear in a directory or file name: ASCII '/'. Note that I say "byte value": the kernel and the filesystem driver have NO idea what local you're using in user-land, and they don't care. On Windows both '/' and '\' cannot appear, though as we can see here, ':' and others are problematic... In shell scripts you really have to quote every damned string. I really wish that instead of by default splitting words on $IFS and interpreting glob and other shell special characters, the default was that $varname has no such handling performed, and instead if you wish for this you'd have to write ${varname*} or something like that.

mehrdadn 8y ago
Because I'm talking about Windows and not Unix systems, and on for Windows systems, literally every piece of documentation I've seen has said that * < > : / etc. are invalid name characters.
- cryptonector 8y ago
  Still, quote everything. Whitespace and other special characters are still a problem if you don't.
- JdeBP 8y ago
  NTFS and the Native API had to support operating system personalities where these were perfectly legitimate characters to have in filenames, right from the start. It is the personalities like Win32 and 16-bit OS/2 that introduce the extra limitations.