Saturday, February 18, 2017

Using PowerShell to Work w/ Tenable Restful Web APIs (IRM FTW)

This one feels like it’s been a long time coming, and since the Mrs. was out of town last week, I ended up not being able to keep up with regular duties and put together a new post.  It doesn’t help that I’m still somewhat new to forcing new topics every week, but enough of the excuses.  I present the latest entry, working with Tenable’s API using PowerShell.


A little bit of a backstory in how this came to happen.  Having implemented a new vulnerability program, I wanted to find a good metric to pull actual counts on vulnerabilities based upon their severity.  Nessus does a nice job in rolling up their reports, but the counts are summarized in the reporting rollup.  I needed something that would give total without being summarized by system.  Initially, I was going to write some long winded functions that would require:
  1. Detailed Csv manually saved.
  2. Parse the columns in the CSV to get summary
  3. Count each one by host
  4. Repeat


With that process, there would have been a lot of things running, but being done as a manual process.  That was not a good reason to be scripting something out.  Enter the Nessus API documentation.  The mapping should be found at the https://[nessus_server]:[portNo]/api.  If working with the cloud API, it can be found at https://cloud.tenable.com/api. I updated this script, shared fully at the end, to test for this if no port is specified.


I before I could work with the scans, I needed to authenticate to the application. After browsing to session -> create I was able to find if I post to /session with username and password in I would get the API key back.  Initially this was giving me fits, but at the bottom of the API documentation there is a form to test the method.  











I was having some issues keeping the session open and @maendarb recommended I take a look at Posh Nessus.  I reviewed the session handling, and was able to get the credential passed in the same manner.  I was receiving my access token with the following command:





I was receiving errors whenever I would test without passing it through as a PSCredential though, although in later modified runs, it was converting the JSON with no issues.


Next I needed to see how the session was passed, so I watched a scan retrieval flow through using the same test technique as with the authentication credential through Owasp ZAP.  When the token was passed through, it was passed using the x-cookie header.  Adding this to the Invoke-RestMethod -header parameter as a part of the command below was able to get me a JSON object returned of all my scans.  





The only thing left to do was to create a loop through the last active scan by scan ID, and obtain the vulnerability count by host based upon critical score.  Still had to pull the scan details, which was outlined in the API documentation.  It was as simple as looping through the scans and passing the scan id through one last Invoke-RestMethod.  






Lastly the script needed to just add the counts up by host to give me the real total on the number of vulnerabilities found based upon vulnerability classification.  The full script can be found here.


A few things learned within this process…

  1. Working with API’s in PowerShell can be amazingly simplistic with the Invoke-RestMethod.
  2. Once the initial session creation was completed within Tenable’s API, it has become easy to use PowerShell to automate a lot of my old manual reporting functions.
  3. Getting comfortable with a good web proxy will make things a lot easier for formatting commands to pass.

Friday, February 3, 2017

Getting Started (An Introduction to PowerShell)

This is my first run through in making sure I’m writing at least one entry per week.  Before I could really talk about how I go about doing things, I thought I’d share how I started using PowerShell…

When first starting out with PowerShell, I had a feeling it was going to be an incredibly useful tool.  My first script wasn’t very good, but it was a way for me to uninstall an application from all the remote systems on my work network within a matter of a couple minutes.  It was meant to save time, which it did do that, but was horrible in its execution.  Not even clear on everything from memory, but it was calling VBScript, and Cmd.exe remotely through PSexec.  Looking back there’s so many different ways I could have made that work (and probably taken out too).  That’s for a different time though.

I determined after working on that little project, a different way of doing things was available, and I saw the writing on the wall that made me realize Microsoft was going to be doing a lot more to integrate PowerShell into its systems management.  Now, I’ve known myself long enough to know that unless I force myself to do something, I’m going to continue doing things in my own way, and knew I would need a push in the right direction.  This is where I decided to replace my startup environment to no longer utilize explorer.  From there, if I needed to do something, I figured, I’d better learn how to do it quickly, because no one was around to ask for help when I’m working by myself on a night shift, and a system is down.  In Windows 7 there’s a way to replace the default login environment, under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon, and change the entry Shell to “powershell.exe”.

Once done, I rebooted.  Luckily, I knew some of the command line utilities w/ DOS as a backup and there were still applications the business relied on that worked were thick client apps, but my rules were simple:
  1. Anything I did within the operating system to interact had to be with PowerShell.
  2. I could not use the Internet to determine how to do anything.
  3. Everything I did had to use the corresponding cmdlet.  That meant I couldn’t just type explorer.exe, I actually had to run “Start-Process -FilePath c:\windows\explorer.exe”

While this probably wasn’t the best way to go about doing things, I learned the help structure was incredibly simple to work with, and just typing Get-Help would tell me everything I needed know. I ended up using PowerShell as my sole way of navigating my system, and after about 3 weeks was beginning to feel really comfortable with getting around.  I did end up giving up on the experiment because I liked having my desktop around.  I started doing as much reading on the topic as I could, and slowly began learning more about how to interact within .NET from PowerShell without needing to compile.  Once that little nugget of knowledge was dumped on me, and I could put my .NET development training to use without working in Visual Studio, things took off from there.  It would end up being a couple more years before I was able to start putting that knowledge to use, and start writing some more in depth scripts.  Beginning next week I’ll start looking more in depth at different commands and getting more into the nitty gritty (as they say).