During security assessments (internal penetration tests or Windows client hardening) at our customers, we often find configuration files with a content resembling:

UserName = COMPANY\service_user
Password = S0mE+b4sE/64==

Against security best practices, service accounts often have more privileges than what they really need or have different policies applied to them than a user account. This makes them interesting targets for attackers.

Several antivirus rely on obfuscation to store passwords:

Case study: Sophos AutoUpdate

Sophos AutoUpdate is part of the Sophos Endpoint Security and Control solution. It is responsible for connecting to a network share or web server and downloading the latest virus signatures.

According to Sophos, the so-called Sophos Update Manager account should not be and administrative account and should only have read and execute rights on the target resource.

However, in real-life situations, Compass analysts find that such accounts have often too many rights. Hence, it might be interesting to reverse the obfuscated string and recover the password in order impersonate this user.

Is the password secure?

The configuration of the Sophos AutoUpdate tool is located under C:\ProgramData\Sophos\AutoUpdate\Config\iconn.cfg:

[PPI.WebConfig_Primary]
AllowLocalConfig = 0
AutoDialTimeout =
LocalPath =
DownloadGranularity =
ConnectionAddress =\\someserver\somepath\
UserName = COMPANY\sophos_admin
UserPassword = GKGYqkTO3VAntZ9L6kR/FWN51GfpvImvPA== 
ConnectionType = UNC
UseSophos = 0
AutoDial = 0
BandwidthLimit = 0
PortNumber =

A clever hacker could use search engines in order to find such files online…

A Sophos Moderator mention on the Sophos Community forums:

iconn.cfg contains the credentials for accessing the update share. By default this is the so-called Sophos Update Manager account that has limited rights.

[…]
the term for the method used is obfuscation, it is of course reversible and just for hiding the credentials from prying eyes.

[…]


there is no secure method of storing data (password, key, whatever) needed to authenticate against a service/server.

QC

Deobfuscating the password

First solution: debug the program

By looking for the string “UserPassword” in our favorite debugger, we find many occurences and add debug points:

x64dbg: find references

After a few steps in the debugger, the deobfuscated password appears:

x64dbg: debugging

Time needed: minutes to hours

Second solution: decompile and reverse the algorithm

Using the knowledge acquired through our debugging, we know where to look for the decryption code. We use NSA’s decompiler Ghidra and identify the portion of the machine code responsible for deobfuscation:

Ghidra: disassembler window

The decompiler’s view of Ghidra provides us with a nice code:

Ghidra: decompiler window

We just need to extract some constants from the program and in some 80 lines of python code, we can reproduce the behaviour of the deobfuscation successfully:

Our deobfuscation script in action

Time needed: hours to days

Bottomline

  • Apply the least privilege password to service accounts
  • Security through obscurity is not a good solution, obfuscation is no exception