This is really just for my memory's sake. I'm writing this up as I've just recently had to perform these steps a couple of times. For 99% of the readers, this is old hat. Here's the situation:
You have a port that's open and you want it closed, or, you have a process running that you can not kill. Here are the steps I've followed:
netstat -naob (use on XP Pro or newer...I don't think the 'b' switch is available in the home edition.)
Find the port that's open or the offending process.
wmic process list brief
This will list the process and their processid.
wmid process [processid] delete.
Poof....it's gone.
WMIC...hugely powerful. I've mentioned it in posts here and here.
Tuesday, June 23, 2009
Gold Disk and password policies
The other day, a bunch of us were talking about the Gold Disk and how we mitigate for any false positives that are returned. One area that produced some discussion were password policies. Currently, I believe that the Gold Disk looks for 10-character passwords, as per policy. Army policy enforces 14 characters, at a minimum. So, while testing an Army system, Gold Disk could find a 12-character password, and pass the control. Without further review, the auditor would never know that the finding is actually a failure (with regards to the Army.)
That said, I created a little script that I'll try on my next engagement. The script idea came from a posting on the phenomenal Command Line Kung Fu blog. At a prompt:
net accounts > %computername%-AcctSecPolicy.txt
Or, if you want domain-level policy:
net accounts /domain > %computername%-DomAcctSecPolicy.txt
A quick breakdown: net accounts returns the overall general security settings for all accounts. the /domain switch will grab the same information on the domain level. Then, I shoot the output to a file that starts with the name of the computer (that's the %computername% environment variable.) This way, I can grab the results from the computer, along with the Gold Disk data. Later, I'll have the data to analyze along with the Gold Disk data, and I'll know which system it came from.
That said, I created a little script that I'll try on my next engagement. The script idea came from a posting on the phenomenal Command Line Kung Fu blog. At a prompt:
net accounts > %computername%-AcctSecPolicy.txt
Or, if you want domain-level policy:
net accounts /domain > %computername%-DomAcctSecPolicy.txt
A quick breakdown: net accounts returns the overall general security settings for all accounts. the /domain switch will grab the same information on the domain level. Then, I shoot the output to a file that starts with the name of the computer (that's the %computername% environment variable.) This way, I can grab the results from the computer, along with the Gold Disk data. Later, I'll have the data to analyze along with the Gold Disk data, and I'll know which system it came from.
Sunday, June 21, 2009
Auditing Exchange Server for vulnerabilities?
I have an engagement coming up where we'll have to audit some Exchange servers. Currently, the DISA Exchange checklist is in draft. Yes, we'll be running Gold Disk on the servers, and we'll be running Oval to check the patches. However, is there any other guidance for auditing Exchange?
As I find other options, I'll post them here. And of course, I'll write up our methodology after the trip.
Edit: NSA Exchange guide
Unfortunately, CIS doesn't have a tool for Exchange.
As I find other options, I'll post them here. And of course, I'll write up our methodology after the trip.
Edit: NSA Exchange guide
Unfortunately, CIS doesn't have a tool for Exchange.
Wednesday, June 10, 2009
Symantec Endpoint Protection shutting down network scans - FIXED
One of my co-workers fixed our issue with Symantec Endpoint Protection shutting down our network vulnerability scanning. To do so, we uninstalled the "Network Threat Protection" feature on the test laptops; leaving the anti virus. Also, the "Application and Device Control" option was removed from the installation as it relies on the "Network Threat Protection" feature.
Here's a write-up from Symantec.
Here's a write-up from Symantec.
Tuesday, June 9, 2009
U.S. Army servers breached
ZDNet has an article on U.S. Army servers being breached by hackers. I've written before about the project I last worked on; acquiring data in order to certify applications that are moving off an army base. The problem discussed in the article is pervasive, and I think we did a good job of helping the developers and admins find some of these potent vulnerabilities and get them on their road to recovery.
I hope to get up a post on our methodology for completing the task. Hopefully, I can get some positive and negative feedback.
I hope to get up a post on our methodology for completing the task. Hopefully, I can get some positive and negative feedback.
Thursday, June 4, 2009
Symantec Endpoint Protection and network scanning
Two of my co-workers returned from a small engagement this week. We had just upgraded our test laptops with Symantec Endpoint Protection. (Minor back-story: We had been using Symantec Anti-virus. When we updated the Retina definitions, a vulnerability was found in the Symantec reporting agent. We couldn't upgrade the AV because we didn't have licenses. Grrrr. Corporate had to grab SEP licences.)
Ok, so my co-workers were at a client site; having to scan a small number of workstations. They couldn't get Retina to reach ANY client machine. It seems, SEP was monitoring the NIC and assumed that the test laptops were under attack due to the high volume of packets leaving the machine and the type of traffic that was coming in and out of the laptop. It appears that the IDS shut down the NIC. NMAP was having trouble. Simple pings had problems after the IDS shut the NIC down. The ultimate solution was to uninstall SEP after getting network accreditation to test.
Is this a known issue? Has anyone else experienced this? Fortunately, they did not have to use the web application vulnerability scanner, as I'm sure it would not have worked either.
Ok, so my co-workers were at a client site; having to scan a small number of workstations. They couldn't get Retina to reach ANY client machine. It seems, SEP was monitoring the NIC and assumed that the test laptops were under attack due to the high volume of packets leaving the machine and the type of traffic that was coming in and out of the laptop. It appears that the IDS shut down the NIC. NMAP was having trouble. Simple pings had problems after the IDS shut the NIC down. The ultimate solution was to uninstall SEP after getting network accreditation to test.
Is this a known issue? Has anyone else experienced this? Fortunately, they did not have to use the web application vulnerability scanner, as I'm sure it would not have worked either.
Emergency Testing Engagement - not so much
Well, I haven't been testing. What was supposedly an emergency is turning into a farce. It turns out that I have no idea when I'll actually test this system, if ever. Our project lead (that we contract for) seems to think the customer is trying to get out of testing. My manager thinks the customer is in denial. I think he's somewhat ignorant, and maybe a little arrogant. Consider:
In going through the Application Security and Development Checklist with him, he proceeded to tell me that they do not have any code, just HTML. "They don't have any code, like c++ or the like." I tried to explain that html contains code, but he wouldn't hear of it. I was also told that they do not have incidents, and therefore do not have or need an Incident Response Plan. Some other quotes I received were: they "don't get security flaws" and they've "never seen patches pushed out" for their code hosting tool.
I've been directed to write up a DIACAP based on the interviews we've had, and the results of some of the SRR scripts that they are running. I've asked them to Gold Disk their servers in order to grab the IIS information; and run the MS SQL Server scripts against their database in order to grab database configs. Yeah, I know it's not the most complete, but I don't have much choice. As it is, the answers I've been getting are not that great, so I can't see too favorable an outcome from this.
In going through the Application Security and Development Checklist with him, he proceeded to tell me that they do not have any code, just HTML. "They don't have any code, like c++ or the like." I tried to explain that html contains code, but he wouldn't hear of it. I was also told that they do not have incidents, and therefore do not have or need an Incident Response Plan. Some other quotes I received were: they "don't get security flaws" and they've "never seen patches pushed out" for their code hosting tool.
I've been directed to write up a DIACAP based on the interviews we've had, and the results of some of the SRR scripts that they are running. I've asked them to Gold Disk their servers in order to grab the IIS information; and run the MS SQL Server scripts against their database in order to grab database configs. Yeah, I know it's not the most complete, but I don't have much choice. As it is, the answers I've been getting are not that great, so I can't see too favorable an outcome from this.
Subscribe to:
Posts (Atom)