8 Replies Latest reply on Jun 22, 2017 2:18 PM by ph0t0g02

    Intel AMT Firmware Vulnerability - Don't Wait


      In case anyone has not heard about it by now, on May 1st, Intel announced a vulnerability in it's Active Management Technology, Small Business Technology, and Standard Manageability systems.


      Intel® Product Security Center


      Since LANDesk integrates with AMT, I thought I would start a discussion on it.


      This vulnerability can give an attacker complete control of your machine, theoretically even if the machine is powered off!! Yes, you read that right. If a machine is powered off and connected to a powered Ethernet connection, a hacker could power up the machine and take full control. Windows Firewall, Anti-Malware programs, and even disk encryption can all be bypasses. The vulnerable  vPro/AMT/ME hardware has been built into laptops and desktops for years, silently waiting for a hacker develop an exploit.


      Ivanti released a Vulnerability Definition "INTELAMT_Mitigation" that will mitigate the problem by limiting the attack vectors. However, this does not fix the problem, which is only repairable by updating the AMT Management Engine (ME) Firmware.


      The difficulty developing a fix is that the Firmware updates are specific for Makes and Models of computers and are supplied by each computer manufacturer. So don't wait for Ivanti to publish a fix, because they would have to have a package for just about every make and model out there older that a couple years.  I have taken the next step and created a Custom Definition that will update the firmware in the makes and models that exist in the environment that I manage. If you would like more information, tell me so and I can explain how to do it and even supply some sample scripts.



        • 1. Re: Intel AMT Firmware Vulnerability - What Ivanti Won't Tell You
          phoffmann SupportEmployee

          There's a bit of a difference between providing the content we have provided and "intentionally keeping quiet about something", which seems to be what your title is alluding to (intentionally or not). As correctly identified, the biggest headache around that AMT issue is the "yep - every hardware model for its own fix"-factor (and all the "fun" that THAT situation is...).


          Since the content we provided is named a "mitigation" and not "resolution" - that does kind of indicate that it's not a fix for a situation - just an improvement (for more information, people should read this - Download INTEL-SA-00075 Mitigation Guide  ).


          There's no problem with you posting your custom detection script "as is" here, if that's your concern?


          If it'll help / benefit other people, may as well do it as a copy & paste-able QUOTE section and/or an attached (compressed) file to look at (can - after all - simply be exported from your Core & then anonnymised)? (tends to make life easier than you having to handle a bunch of separate contact requests & so on), unless you rather keep it that way of course.


          Just in case someone doesn't know at all what this is all about, please read & be aware of the following security advisory from Intel (linked to by the above author already, and included purely for completeness in a single post):

          - Intel® Product Security Center


          ... is there anything else that you feel should be addressed or is otherwise missing here?


          Hope this helps.

          1 of 1 people found this helpful
          • 2. Re: Intel AMT Firmware Vulnerability - What Ivanti Won't Tell You

            Sorry Paul if this title upset anyone at Ivanti. I have no bone to pick with the content team. In fact I did provide the Custom Definition to Shad Stranger an asked him to forward it to them.


            I titled it that way to get peoples attention, because this issue deserves a lot of attention, and I didn't feel like it has, either on the community boards or in the information Ivanti has posted. Hopefully, Ivanti will provide at least some guidance on how to go about creating a fix. Or perhaps I should post a document on how I did it, but really it is still evolving, so that is why I did not want to post and get a lot of criticism for being incomplete. I would rather give some guidance and provide some sample scripts, as I stated above.


            I will change the title if I can, or, it I can't,  I give permission to the sysop to do it if so desired.



            • 3. Re: Intel AMT Firmware Vulnerability - Don't Wait
              ldms_4mfe Apprentice

              Hi peter,


              thank your for starting this discussion and pointing to that Problem.


              I did read the guide



              As far as I understand I have to install the NTEL-SA-00075 Discovery Tool on all devices ot get a vulnerability status.


              After the first run, with the GUI i saw my admin system is not vulnerable. But after running the console.exe I miss the registry key for that.


              How do you detect the vulnerable machines?


              Betst Regards, Marco

              • 4. Re: Intel AMT Firmware Vulnerability - Don't Wait

                Hi Marco, Welcome to the discussion.


                For detecting vulnerable machines, I used the detection logic in a Custom Definition.  I wrote a custom script that downloads and runs the Intel Discovery Tool. I used a different discovery tool that the one Ivanti uses, but if I had it to do over again, I would use the other one. Both of them write out a bunch of stuff about AMT to the registry, which you can then read back into the script and determine if it is vulnerable or not.


                Do you know how to write/modify custom scripts in LANDesk? If you don't you can just use the Ivanti Vulnerability "INTELAMT_Mitigation" to determine which machines are vulnerable in your environment. After it scans a machine, it writes the current ME Firmware version out to the registry here:


                HKLM\SOFTWARE\Intel\Setup and Configuration Software\SystemDiscovery\ManageabilityInfo\FWVersion.


                You can then pull the contents of that registry value into custom inventory and query against it. The FWVersion number will be something like "". If the last part of the number doesn't start with a "3" (like "nn.nn.nn.3nnn) then the machine is vulnerable.


                If you are good with scripting, then I will try to attach my script here, although like I said, I would recommend changing it to use to other discovery tool (fewer files to download). I've never used the "Quote" feature, or attached a file, so it may take me a minute to figure it out.


                Hope this helps.



                1 of 1 people found this helpful
                • 5. Re: Intel AMT Firmware Vulnerability - Don't Wait
                  ldms_4mfe Apprentice

                  Hi Peter,


                  usually I have a good understanding of Powershell and AutoIT. VB confuses me always. But your script is clean and very good commented. Thank you for sharing it!

                  I will test it in my environment.


                  It is a bit lame that the discovery tool checks if it is vulnerable or not but does not add a registry key for it. So you have to to do this checking in your script again.


                  I will keep the discussion updated.

                  • 6. Re: Intel AMT Firmware Vulnerability - Don't Wait

                    Hi Marco,


                    Give the script a try. If you have difficulty modifying it for your environment, I will be glad to work with you.



                    • 7. Re: Intel AMT Firmware Vulnerability - Don't Wait
                      phoffmann SupportEmployee

                      Heyas Peter .


                      For the record - I don't think anyone at Ivanti got actually upset over the title (we've got thicker skin) - but thanks a lot for changing the title. That is a lot less dubious that way for sure now!


                      Much appreciated.


                      As for the vulnerability side of things -- a little something that may help here (which is a bit of "duh..." moment in retrospect) is the conversation I had about how to SQL up a query to help find the "nn.nn.nn.3xxx" pattern in the DB ...




                      Here's the thread -- Query help -- (this also then helps to signify why CLEAR titles are important, had to find that one the painful way ...) .


                      And here's the SQL:

                      select COMP.DeviceName, AMT.FWVersion, REVERSE(LEFT(REVERSE(FWVersion),CHARINDEX('.', REVERSE(FWVersion),0)-1)) as 'Last4 of FWVer'  
                      from AMT_SCS_Info AMT  
                      LEFT OUTER JOIN COMPUTER COMP (nolock) on AMT.Computer_Idn = COMP.Computer_Idn  
                      WHERE FWVersion <> '3000'  


                      Note that this doesn't dig the data from Custom Data, but from the AMT-tables (I'm assuming we're grabbing the FW version for your hardware from there). So this isn't "custom data" but "regular data" - so you shouldn't need to query the UNMODELLEDDATA table.


                      Hope this helps?

                      • 8. Re: Intel AMT Firmware Vulnerability - Don't Wait

                        Interesting query. The AMT ME version can also be found in inventory under BIOS -> BIOS Settings -> ME Firmware Version -> Current Setting.


                        However, I have found both to be unreliable, and so have used the Intel AMT Discovery tool instead. I download and run this tool in the detection logic part of the Custom Definition. The tool writes the ME Firmware version to a registry value, which can then be read back into the script and used for comparison (and/or pulled into LD Custom Inventory).


                        I will attach my latest custom definition here.