Enlarge / AMD's Ryzen die. Threadripper has two of these in a multi-chip module. Epyc has four of them. (credit: AMD)

AMD has responded to the reports last week of a range of security flaws affecting its Platform Security Processor (PSP) and chipset. The company acknowledges the bugs and says that, in coming weeks, it will have new firmware available to resolve the PSP bugs. These firmware fixes will also mitigate the chipset bugs.

Israeli firm CTS identified four separate flaw families, naming them Masterkey (affecting Ryzen and Epyc processors), Ryzenfall (affecting Ryzen, Ryzen Pro, and Ryzen Mobile), Fallout (hitting only Epyc), and Chimera (applying to Ryzen and Ryzen Pro systems using the Promonotory chipset).

Masterkey, Ryzenfall, and Fallout are all problems affecting the Platform Security Processor (PSP), a small ARM core that's integrated into the chips to provide certain additional features such as a firmware-based TPM security module. The PSP has its own firmware and operating system that runs independently of the main x86 CPU. Software running on the x86 CPU can access PSP functionality using a device driver, though this access is restricted to administrator/root-level accounts. The PSP is also typically not exposed to guest virtual machines, so virtualized environments will typically be protected.

Read 8 remaining paragraphs | Comments

CSNC-2017-026 Microsoft Intune - Preserved Keychain Entries
ES2018-05 Kamailio heap overflow
Bouncy Castle BKS-V1 CVE-2018-5382 Security Weakness

Just a quick reminder about some bad practices while handling Windows Administrator credentials. I'm constantly changing my hunting filters on VT. A few days ago, I started to search for files/scripts that use the Microsoft SysInternals tool psexec[1]. For system administrators, this a great tool to execute programs on remote systems but it is also used by attackers to pivot internally. This morning, my filter returned an interesting file with a VT score of 11/66. The file is a compiled AutoIT script. This kind of malicious files is coming back via regular waves[2]. AutoIT executable can be easily decompiled. To achieve this, I'm using Exe2Aut.exe[3]. This tool has not been updated for a while but is still doing a good job.

I decompiled the malicious file which was not malicious at all. It was a script created by a Windows administrator to automate the creation of users' directories. This seems a legit script, however, there were two security issues in this very little script:

The first one was the hardcoded domain admin credentials in the script:

$adusername = "Administrator"
$adpassword = "*C0rnHu******"

The password was a strong one but once the file is published on VT, you can consider the password as lost. Other interesting information are also hardcoded:

$server = "Pithos"
$folderpath = "E:\Users\"
$server = "RMT-SLIA-FILE01" 

Note: the Microsoft domain was also present in the file and a simple Google search helped to guess the company. Could we call this a "virtual compromisation"?

The second issue is nastier. The developer is using PsExec to execute a script on a remote server:

RunWait("C:\pstools\psexec.exe \\" & $server & " -u " & @LogonDomain & "\" & $adusername & " -p " & $adpassword & " C:\createudir.bat")

Used in this way (with '-u' and '-p' options), PsExec sends the credentials in clear text across the network. Hopefully, it has been fixed by Microsoft starting with PsExec version 2.1. An alternative to this to protect the credentials is to open a NULL session to the remote host prior to calling PsExec. This way, NTLM or Kerberos will be used. According to a post written by Mike Pilkington on the Digital Forensics SANS Blog[4], the $IPC NULL session will also prevent the domain administrator's hash to be captured by dumping tools on the remote system!

Some tips to protect your credentials:

  • Do not use an outdated version of system tools
  • Do not store credentials into scripts/source code (binaries can be decompiled/reversed!)
  • Do not publish internal tools on VT (or any other cloud services)
  • Use strong authentication mechanism to prevent credentials to cross networks and be stored in memory

Stay safe!

[1] https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
[2] https://isc.sans.edu/forums/diary/AutoIT+based+malware+back+in+the+wild/22778
[3] http://domoticx.com/autoit3-decompiler-exe2aut/
[4] https://digital-forensics.sans.org/blog/2014/11/13/protecting-privileged-domain-accounts-restricted-admin-and-protected-users

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Internet Storm Center Infocon Status