Error 1719. The Windows Installer Service could not be accessed... and Windows Vista

In February this year I received new HP NW9440 notebook. I decided to install 64 bit version of Microsoft Windows Vista Ultimate on it. After installing all the usual applications like Microsoft Office 2007 I wanted to install some more "exotic" ones, like Microsoft Virtual PC 2007 (64 bit of course). Here I run into a problem. Virtual PC did not want to install on my computer and if was failing with error:

I searched through usual KB articles and solutions, but none of them applied or helped my Vista. Because of other engagements and in need of quick solution I gave up on Virtual PC for the time being.

I almost forgot about the problem for couple of months, until I needed to install Microsoft Network Monitor 3 (again of course 64 bit), but this installation too failed with same error as Virtual PC.

In event logs I was receiving these two errors:

Log Name: Application
Source: MsiInstaller
Date: 4.7.2007 9:59:57
Event ID: 11719
Task Category: None
Level: Error
Keywords: Classic
User: PC\mike
Computer: PC
Description: Product: Microsoft Network Monitor 3.0 -- Error 1719. The Windows Installer Service could not be accessed. This can occur if you are running Windows in safe mode, or if the Windows Installer is not correctly installed. Contact your support personnel for assistance.

Log Name: Application
Source: MsiInstaller
Date: 8.6.2007 14:51:41
Event ID: 11719
Task Category: None
Level: Error
Keywords: Classic
User: PC\mike
Computer: PC
Description: Product: MSXML 6.0 Parser (KB927977) -- Error 1719. The Windows Installer Service could not be accessed. This can occur if you are running Windows in safe mode, or if the Windows Installer is not correctly installed. Contact your support personnel for assistance.

In June I was away for a week, teaching at one of the Boot Camps, when I final had some spare time to play and explore the problem. I also had another 64 bit Windows Vista computer in the classroom that I could abuse.

In the end I solved this problem by exporting HKLM\SYSTEM\CurrentControlSet\Services\msiserver registry key on the other 64 bit Vista in the classroom and imported it on my laptop.

Click image to enlarge.

After that I had no problem installing Virtual PC or any other piece of software.

Social Engineering: Getting to the network… (Part 2)

When I am doing a penetration testing, using social engineering, everyone is expecting that I will attack the company at their headquarters. I don't really understand why everyone assumes that. It looks to me that everyone thinks that location that usually holds most servers and all the data and is most populated would be the most likely target.

From perspective of hired attacker, headquarters are usually last location where I would try to break in. Companies usually spend a lot of money securing the headquarters (e.g. technical security, guards or receptionists in the lobby etc.)

On the other hand, remote locations are usually not so heavily guarded if at all. I often find servers (including domain controllers) unprotected and easily accessible to just about anyone. Employees at remote locations are usually also less security aware.

But once inside remote location it is in general pretty easy to get access to corporate data just as if I would be sitting at the headquarters. These days I find that most of the networks are flat with no firewalls or access rules that would prevent access even to resources that are not needed from remote locations.

When thinking about security of your network, don’t forget about remote locations! If remote locations have access to data and services at the headquarters, security of any such remote location is just as important as security of headquarters. Remember, "hackers" are in general not really known for "playing by the rules". They will not attack you only at your headquarters either...

To DMZ or not to DMZ... (Part 1)

One of the most frequent questions that I receive is about placing Exchange Front End server in DMZ. Personally I believe that placing any domain member (not just Exchange Server) in DMZ does not protect your internal network or your domain/forest.

Let’s take a look at how an attack to domain member placed in DMZ could look like. This is not limited to Exchange servers in DMZ, but applies to any domain member server that you might want to put in DMZ and open access to it from the internet. Such attack can be performed to any server in DMZ and again is not limited to domain members.

We have few possible targets. E.g. Windows Server, IIS or applications installed on the server. We will assume that operating system has latest updates applied. For this attack, we will focus on the third option -- 3rd party applications. I often (too often) see 3rd party applications running on dedicated servers (e.g. Exchange Front End Server in DMZ). These 3rd party applications are most often not patched and are running under some very privileged account on the system.

For this attack we will assume that 3rd party application has at least one vulnerability. Very common these days are SQL or other type of injection attacks due to lack of input validation. In our attack, hacker finds a bug (all he needs is one) in the application and since application is running under System account (still common these days) anything that is executed through the bug in the application, also runs as System.

Attacker, using bug in the application, uploads a key-logger to the server and installs it. He will now wait till the system administrator logs on to the server using his domain credentials to perform common administrative tasks. Since our attacker is all excited about this attack and can’t wait too long for system admin to log on, he can speed things up by e.g. stopping IIS service on the server. First user that will notice that web application is not working will very likely notify system administrator about it.

I sometimes see (unfortunately in too few occasions) that system administrators only have full permissions on servers that they need to take care of and not all of them. Attacker in our case can protect himself just in case and removes all users from local administrators group, leaving only “Domain Administrators” group as the member. This way attacker made sure that account that will logon to the server next, will be member of Domain Administrators.

Once the attacker has credentials of domain administrator, he can logon to the server. Now he stops and thinks about what would be the coolest thing to do. My guess is that he would run “dcpromo” on the server and make it a domain controller. The attacker now actually owns a domain controller in DMZ. In other words, he owns the domain and anything that is part of domain.

Main problem that I see too often when placing server in DMZ is false sense of security that DMZ provides. As we can see, placing domain member server in DMZ does not protect domain or internal network.

So, to DMZ or not to DMZ? You will have to decide for your own network. :-)

In the second party of “To DMZ or not to DMZ” I will write about protecting member servers that are accessible from the internet.