Exploiting E2 MFG

by Vince
in Blog
Hits: 741

The terms vulnerability assessment and penetration test are often used synonymously but they are not the same thing.  This post is a perfect example of something that would not get identified during a vulnerability assessment and showcases the difference between it and a penetration test.  

During a recent penetration test, I discovered a Microsoft SQL Server.  

I'd already compromised a few users and one of the accounts allowed me to enumerate the file shares on said SQL Server.

I mounted the visible share and started searching through the file system.

To my surprise, I found a DB_Scripts folder which contained some juicy files.

And that's when I struck gold:

That's a fantastic password, it's a shame it was left in the open for anyone to find. 

Using a SQL Server client, I connected to the server.

I enabled XP_Cmdshell and executed the whoami command.

Checking the privileges of the current user.

SeImpersonatePrivilege stands out because of Print Spoofer.  I didn't attempt this exploit but only pointed it out in my report.  This being a production server, I felt like that would be risky.

I did attempt to upload a reverse shell and the endpoint protection stopped me. 

Attempting to capture the hash, I called a fictitious share on my attacking system.

Capturing the hash with Responder. 

SMB Signing was enabled which prevented any sort of relay attack.

Using a different SQL Server client, I connected to the database.

Enumerating databases.

Querying the users table.

Already proving that I could modify the database, I wanted to show the potential damage from an insider threat.  In this environment, users are restricted and everyone uses the least privilege model.  That being said, HeidiSQL has a portable version which a regular user can run. 

I asked the client to create a low privileged user in E2 MFG.  From HeidiSQL, using the discovered credentials, I accessed the User_Code database.

I modified my account, matching that of an Admin.

I also discovered that I needed to modify the User_Group_Code as well.

The login prior to upgrading my rights.

And after.  Note the additions on the top row.

Not leaving anything to the imagination in my report, I show the Users section of the E2 MFG console.

I reached out to ECI Systems three separate times and I've yet to hear back.  I don't think this technically falls into the vulnerability category which would warrant a CVE write-up.  But it does make one wonder if leaving credentials in a public share is standard practice for their installers.