• 
  

• Archives

  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • January 2012
  • December 2011
  • October 2011
  • May 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • August 2010
  • July 2010
  • May 2010
  • February 2010
  • December 2009
  • November 2009
  • October 2009
  • August 2009
  • July 2009
  • May 2009
  • April 2009
  • March 2009
  • January 2009
  • September 2008
  • August 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • April 2007
  • February 2007
  • January 2007
  • December 2006
  • September 2006
  • June 2006

• Categories

  • Authentication (2)
  • Code Review (8)
  • Debugging (5)
  • Development (24)
  • Malware (6)
  • Nebulous (2)
  • News (33)
  • Privacy (3)
  • Reverse Engineering (4)
  • SDL (9)
  • Security Testing (39)
  • Tools (20)
  • Unicode (12)

Subscribe

• RSS Feed

A common scenario:  You have tens of thousands of hosts deployed across your datacenters and use Nessus to scan them regularly for patch compliance or other vulns. But you want to look at more stuff, after all you’re running a scanner on each and every host, why can’t you audit for policy or configuration-related data? Well you can - Nessus has this compliance auditing functionality built in, which makes customized checks easier than writing NASL files. Instead, you can write these “.audit” files and simply certain tasks such as looking for files, content, users and groups, registry keys, and more. In the case of Windows machines, the compliance checking gives you an extra edge – access to Powershell. Powershell comes with certain restrictions though, namely that you can’t simply call your own scripts, rather you have to pass cmdlets in as args. However, read on…  You can run checks that either PASS or FAIL, or you can dump output back into Nessus for later retrieval and post-processing. Take a look at what a custom Nessus compliance check called “find-private-certs.audit” might look like.

<check_type: "Windows" version:"2">
<group_policy: "Windows file system audits">

 type             : AUDIT_POWERSHELL
 description      : "Search the file system for private certificate files."
 value_type	  : POLICY_TEXT
 value_data       : "" 
 powershell_args  : 'Get-WmiObject -query \\"Select Name From CIM_DataFile Where Extension = \'pfx\' or Extension = \'p12\' or Extension = \'p7b\'\\" | select -ExpandProperty Name'
 check_type       : CHECK_EQUAL
 severity         : LOW
</group_policy> 
</check_type>

Pretty simple, you just pass a Powershell cmdlet with arguments in like “Get-WmiObject” and get your data back. Now, I wouldn’t actually run this in production because searching the file system can be really slow and delay scan completion. But that’s besides the point. Once you realize you have access to Powershell you might be motivated to do more, and get more data. That’s what happened to me, and I simply had to find a way to run Powershell scripts.

So I did… Consider this technet script Get-SharePermissions.ps1 by Bigteddy at Technet. It basically dumps all the shares along with permissions on a Windows host. Now the Nessus interface with Powershell wasn’t designed to load scripts as I mentioned, and the documentation won’t help you figure out how to do it. But there is a way. A slightly modified version of Bigteddy’s script appears below, hacked into a Nessus .audit file. I’m leaving out the other components of the script, and just showing the “powershell_args” field:

powershell_args   : 'get-variable null | invoke-command -scriptblock { $shares = Get-WmiObject -Class win32_share | select -ExpandProperty Name ; foreach ($share in $shares) { $acl = $null; Write-Host $share; Write-Host \\"==============================\\"; $objShareSec = Get-WMIObject -Class Win32_LogicalShareSecuritySetting -Filter \\"name=\\"\\"$share\\"\\"\\" ; try { $SD = $objShareSec.GetSecurityDescriptor().Descriptor; foreach($ace in $SD.DACL){$UserName=$ace.Trustee.Name;If($ace.Trustee.Domain -ne $Null){$UserName = \\"$UserName\\"}; If ($ace.Trustee.Name -eq $Null) {$UserName = $ace.Trustee.SIDString } ; [Array]$ACL += New-Object Security.AccessControl.FileSystemAccessRule($UserName, $ace.AccessMask, $ace.AceType) } }  catch { Write-Host \\"Unable to obtain permissions for $share\\" } $ACL; Write-Host \\"=====================\\"  } } '

And there you have it. Sure, it’s not the prettiest thing, given the escaping required, but it works. Basically, the trick is to start the powershell_args off with a get-variable cmdlet, since Nessus only allows get-* cmdlets to start. Pass in null as the arg, and pipe your way to the invoke-command cmdlet, since the pipeline at least is allowed. Using the scriptblock argument there, you can shove your script in and escape special characters as needed until you get the output desired.

Until next time, happy scanning!

Tags: Nessus, Network, Powershell, Scanning

This entry was posted on Wednesday, December 5th, 2012 at 1:22 pm and is filed under Development, Tools. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.