To protect the guilty I will avoid names...

I know of a site that last night went down. Sort of. For about 5 hours all requests to this asp.net site were producing a YSOD. The details that were spit out included the impersonation tag showing that the site was running under the Administrator account and included the password. This particular site takes personal details and credit card information for 10K+ people per year.

Lots of obvious problems here, this biggest of which that the credentials were exposed for 5 hours. The second of which, they have been running this web site with Admin credentials for who knows how long. Third they are spitting out YSOD screens to the public in an error situation.

If you were tasked to work with this client to help solve this problem, mitigate risk and determine the scope of the potential compromise what would you suggest doing? I am thinking of telling them they need to...

  • hire an outside security consulting firm to perform a thorough audit of the server, request history and other elements to determine what level if any compromise occured.
  • They should actually move to a different server
  • Rebuild the code from the original source, not a copy of what was on the server
  • consider notifying customers whose credit cards are at risk if evidence of tampering comes to light

The host has stated that they do not store credit card numbers but I contend if this many basic mistakes were made, you cannot really trust what they say. They may think they are not storing the card numbers but that doesn't mean they aren't doing so inadvertently.

  • how did this site make it past a pci review? – tony roth Aug 24 '10 at 14:40
  • I wondered the same thing. – keithwarren7 Aug 24 '10 at 14:58
  • absolutely frickin scary is all I have to say, anything you do or say will cost them lots money. Then you get into the ethical\legal issues, oh what a nightmare this is going to be... – tony roth Aug 24 '10 at 17:03

You're tasked to "work with this client"...but you don't say for what. Fix their application? Install new computers? Sweep the floors?

If you're tasked with fixing this particular problem you've presented, first and foremost the server should be taken offline immediately and rebuilt from the ground up on a different server. This server can no longer be trusted. And you can forensically determine if it's been breached or not by leaving everything on the old server intact, but offline.

They may actually be required by law to notify users that they've suffered a breach if indeed a breach happened. If you lack the resources yourself to determine if a breach happened, hire an outside consultant to determine that.

It sounds, at the very least, that they've got some settings in their web.config that are incorrect. It should only throw those detailed error messages locally and not remotely. They may also have debug="true" ON which is NOT CORRECT in production. Their application can no longer be trusted either.

What the hell is a YSOD?

  • YSOD = Yellow screen of death, the error screen in asp.net – keithwarren7 Aug 24 '10 at 13:19
  • 1
    DO NOT WIPE THE SERVER. If you do not trust it, the very most you should do is disconnect the network. I even advise shutting it down in order to preserve it forensically in order to run an investigation. – gWaldo Aug 24 '10 at 13:28
  • I didn't recommend he wipe the server. – GregD Aug 24 '10 at 13:31
  • Not implying that you did, Greg. – gWaldo Aug 24 '10 at 16:52

Let me preface my answer by saying that this is based on my interpretation that a breach has occurred and that a crime was likely committed. With that said...

All of the above are appropriate, however you should move the 'outside security company' item to an after-action item, and replace it with "contact law enforcement (FBI?) to initiate an investigation." I'm not a lawyer, but that seems prudent if not mandatory given that they deal in commerce.

The statement that they process but do not store credit card numbers is irrelevant public relations talk. If they process something, it is placed in memory. (Never mind the fact that it could be written to the pagefile...) Anything in memory can be retrieved, especially on a compromised system. Especially if you don't trust the quality of their code.

There will likely be tremendous pushback, but it sounds to me that it would be the right thing to do.

Given that user's credentials are involved, prompting a recommended password reset may be prudent also.


  • FBI doesn't care unless a crime had taken place. There wasn't evidence in the description that there was a crime, just that it could very well have been committed as it was spitting out admin account details for a program running as an admin user. An outside firm needs to be consulted that specializes in forensic research to determine if there's been an actual breach, then law enforcement would care. – Bart Silverstrim Aug 24 '10 at 15:48
  • Were I in this situation, I think that I would contact them, and if they weren't interested without evidence (which I'm pretty sure that law enforcement does), I would ask them to refer me to a company or agency to conduct an investigation. In my mind, the most important thing is to get it in motion. Using a company that the Feds don't trust (or have blacklisted) could hamper actually getting something accomplished (or destroy evidence if the forensics are done improperly), where I'd think that using an approved company could speed up (or at least not hamper) the process. – gWaldo Aug 24 '10 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.