6

One of our web servers that is managed by a service provider (completely in their control, we have no login access) just failed PCI-DSS vuln. scan by TrustKeeper. The vuln scan detected the box as a Windows Server 2003 SP1 OS (extremely out of date).

I submitted the report to our service provider (along with an angry email). They responded with a simple cropped screenshot of sysinfo screen showing SOME windows 2k3 sp2 box. I have no way of knowing if that screenshot is from our box or not, and based on history with the provider, I'm inclined to think they just grabbed it from another one of their boxes to cover their butts.

With no AD or login access, it's impossible for me to know for sure the SP level of this box.

Question:

  1. Is a simple sysinfo page screenshot enough for PCI-DSS compliance evidence? I can't imagine it being since as stated, it could be from any system. But then how to get evidence from this box that shows it really is our box and really is SP2?

  2. How to remotely verify the SP level of a box. I've had no luck with nmap.. is there another way to prove it's not updated?

See this Server Fault question for my OP.

Community
  • 1
SnakeDoc
  • 357
  • 1
  • 9
  • 1
    I don't know the details of your web-server, but if it has access to something like PHP/ASP functionality, why don't you upload a remote access web-shell and running: > systeminfo | findstr /B /C:"OS Name" /C:"OS Version" – NULLZ May 09 '13 at 02:00
  • does the user/service that runs IIS actually have access to the cmd prompt and able to run systeminfo (or arbitrary command with whatever level access that user has)? (i'm asking because i'm a linux guy and this would sound like a security problem if so!) – SnakeDoc May 09 '13 at 06:10
  • 1
    Depends on the restrictions placed on the user account that's executing these permissions. In theory though, yeah it should be possible. I've never had to personally call systeminfo via a web-shell though, so your results may vary\ – NULLZ May 09 '13 at 06:40
  • I may give this a shot tomorrow then. Although I'm a little apprehensive of it being logged and them finding out. I'm not clear on this box's agreement over what we're allow to do other than normal port scan/pci scan... – SnakeDoc May 09 '13 at 06:49
  • 1
    Yeah, be careful about that, review the TOS. most 'off the shelf' backdoors are (obviously) flagged by AV. You could also try running NMap or something against your host to see what OS *it* fingerprints it as... – NULLZ May 09 '13 at 06:54
  • I"ve done the nmap thing: `Aggressive OS guesses: Microsoft Windows Server 2003 SP1 or SP2 (99%)` .. it's a tossup. I saw this and it looked perhaps... helpful? http://sourceforge.net/projects/aspshell/ – SnakeDoc May 09 '13 at 08:12
  • @D3C4FF just tried the web-shell idea. unfortunately I got an "Access Denied" response, although the shell does load! Short of attacking our own box with something like metasploit in an attempt to get more specific patch-level info out of it's probes... however I'm almost certain that would violate any sort of TOS we have (would probably trip all kinds of alerts in their NOC). – SnakeDoc May 09 '13 at 14:47
  • 2
    Okay. Well it sounds like they're locking down permissions somewhat which is good. But Honestly the best thing you can do in this case is switch to a more helpful hosting provider. If you dont trust them to tell you basic facts, why are you trusting them with PCI data?? – NULLZ May 09 '13 at 22:21
  • So this is somewhat resolved now. I responded to their screenshot this morning and basically said it was not valid proof since it could be from any system. I said I wanted an uncropped and unedited screenshot of 1) IP Address of the server 2) Configured Hostname 3) Configured Virtual Hostname (Our [website] URL configuration in IIS) 4) Installation dates of recent patches including SP2 (Taken from Control Panel --> Add Remove Programs --> Checkmark "Show Updates") 5) System Info page showing what they sent over before. 6) Today's Calendar Date / Time (Task Bar Clock / Calendar is sufficient) – SnakeDoc May 09 '13 at 22:52
  • 1
    they responded by saying they are now going to move our stuff to a brand new server. I think I caught them in a cover-up for sure. – SnakeDoc May 09 '13 at 22:52
  • If it has PHP installed try using phpinfo() – Rod MacPherson May 10 '13 at 15:22
  • Time to fire that hosting provider. If you have the expertise, move it in-house. – Michael Hampton May 12 '13 at 17:28

3 Answers3

4

In order for such evidence to be accepted, it needs to be possible to tie the information in the image showing the Service Pack level to the system (IP address/URL) being scanned by Trustkeeper. A screenshot that has different windows open that shows you're providing appropriate evidence for the correct system should do the trick.

Do you know if the Service Provider is performing internal vulnerability scans on those systems? Perhaps you could get access to those results.

You could try running an online tool such as http://www.yellowpipe.com/yis/tools/craftnet/ though you're unlikely to get a different result to nmap.

As you'll have been running external vulnerability scans every 3 months, has this system ever failed before?

AndyMac
  • 3,149
  • 12
  • 21
  • 1) that's a good idea on the ip address/hostname in the same screenshot as the sysinfo page. 2) Probably not. They get "certified" once a year by two different companies. I doubt there's much more than that, other than their normal IDS stuff on perimeter, standard stuff. 3) You're probably right, likely won't be much different than nmap, and they're probably based on nmap or similar. 4) We run our scans every month, and it has failed several times before. Although, not all for this box, and not recently. I think they have moved one of our boxes to a new setup and installed from old media... – SnakeDoc May 09 '13 at 06:43
2

Honestly, based on whats been discussed in the comments, this doesn't sound like a hosting provider you trust at all. If that's really the case, the PCI auditor was right to fail you on this count. Why are you trusting them with PCI data?

You need to either move these assets in house or move them to a different provider that you trust.

In addition, rather than running on a shared environment that you don't have control over, get a dedicated box, or at least a VPS with root access. You can still pay someone to manage it (managed services or whatever) but YOU can also check that the managed service provider is doing their job from time to time and not pulling something dodgy.

Yes, based on your comments it sounds like they've tried to cover their asses and in the process have created a headache for you. The best long term solution is to move, because if they are indeed doing this, they are reducing YOUR and your CUSTOMERS data security.

NULLZ
  • 11,426
  • 17
  • 77
  • 111
-1

If you have to have this type of interaction with the Service Provider, you have a bigger security risk than Windows Server 2003 SP1... that bigger security risk IS the security provider.

Fire them as quickly as you can, and find another.

Tek Tengu
  • 1,699
  • 11
  • 13
  • Oh if it were only that simple lol. We are pretty heavily integrated with this provider with all sorts of custom middleware and integration software our team has written over the past few years. Switching now is really not much of an option, unfortunately. – SnakeDoc May 09 '13 at 14:40