Kaseya Community

Intel AMT vulnerability detection

  • Procedure Intel AMT Vulnerability Check.xml

    I put together a little procedure to find and mark systems vulnerable to the recently disclosed privilege escalation issue in Intel vPro/AMT. (Details here: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr )

    You'll need to create a Custom Field called AMT Status, and you'll need the discovery tool installer MSI from the above link plus a little utility called Xidel to parse the XML output. http://www.videlibri.de/xidel.html#downloads

    Obviously you probably store your deployment files different from how we do it, so adjust the procedure as needed. I have commented what's going on at each stage, and the procedure is configured to clean up the result output files from a previous run as well as "IF" check to see if the discovery tool is already in place. Also note that this procedure is 64-bit specific. (We have very few 32-bit systems out in the field at this point.)

    Right now this is just a "get it out there for folks to take advantage of" situation, your mileage may vary, etc, etc. Since this procedure doesn't email anybody, you don't have to worry about changing that, at least...

  • Nice!  Thanks for the contribution.  I'm going to check this out today.

  • Just set this up and ran it on two optiplex 7010's. The results say "Unknown"

  • James, you'll want to read the documentation from Intel on the various results strings and maybe pull in the full XML file so you can see what's been detected. There's a chance that vPro isn't an option on that model.

  • I use the vPro module in Kaseya so I now what machines have vPro and which are enabled, but I cannot see a deactive vPro command. Do you know how this can be done as this is the recommendation from intel until a fix is made.

  • Nice work and much appreciated. Running into one issue - the AMTVulnerability.txt file is coming back empty.  The XML file is populated with data and the PCs I am testing with do show a risk status.  I then ran the xidel.exe command on the file manually and the AMTVulnerability.txt file populated.  Can't quite sort out why the executeshellcommand is not working as expected.  Any thoughts?

  • Adrian, I haven't even dug in on that side of it yet; I was tasked with "detection," while "remediation" is in someone else's court. Our current plan (as I understand it) is to start running a lot of HP firmware updates (we're a mostly-HP shop).

  • LR,  I'm not sure how you get the XML output from the procedure okay but not the AMTVulnerability.txt file content. That's a head-scratcher! I'd think the proc would fail earlier or not at all. The two steps are essentially back-to-back (with just the "write xidel.exe to the working directory" step in between).

    Maybe throw a pause in? I wonder if the Tool isn't done writing the XML when Xidel is called.

  • @GrayDuck, appreciate the response and feedback.  Will do some additional testing and try what you suggested.  And, thanks again for sharing with the community!!

  • I am also a HP house, but the problem is the firmware updates to fix the issue are not available and there is no ETA at this time. Intel are working on the fix they will then give it to HP who will then add in the softpaq's I hope it is soon.  

  • We found updates for all our affected HP systems here - www8.hp.com/.../intelmanageabilityissue.html  We were also able to create a script to install them on the affected machines.  Ran that last night and they are all up to date.......except one Dell PC that won't have an update until June 7

  • karoded, thanks for the link. Are the "sp_____.exe" installers scriptable directly or did you have to unpack them and jump through deployment hoops?

  • Haroded, that is fabulous. They are self installing executable files with no prompts, so. should be able to script them

  • Okay some are zipped then they run the procedure.

  • I was able to install all the ones I needed using the Application Deploy wizard with "/S /v"/qn /norestart""  ...I wanted our normal patch cycle to manage the reboot