Some of these credentials, such as SNMP v1/v2c community strings, are stored in clear-text, while most are encrypted using a RSA key located in the Orion server local certificate store. SolarWinds Orion stores network credentials within the SQL Server database tables. Harvesting stored network credentials from the database This hashing function has been implemented in the Ruby script hash-password.rb. It doesn't appear that any existing tools support cracking passwords in this format, but Hashcat comes close with PBKDF2-HMAC-SHA1(sha1:1000) support, and is only missing the final call to SHA512(). Finally, a SHA512 hash of the PBKDF2 output is taken and encoded using Base64. Once the salt has been calculated, a RFC2898 PBKFD2 is generated using the default iteration count of 1000 and the SHA1 hash algorithm. For example, the salt for username "ADMIN" would become "admin124", while the salt for "Bo" would become "bo124435". If the salt is less than 8 bytes long, it is appended with bytes from the string "1244352345234" until it is 8 bytes. The hash is computed by first generating a salt that consists of the lowercase username.
#SOLARWINDS NCM PASSWORD#
Orion password hashing is a variant of a salted SHA512 hash. SolarWinds Orion "Accounts" table password hashing Once the PasswordHash has been replaced (or temporarily intercepted), the attacker can login with an empty password for the associated user account. The screenshot below shows the SQL query to reset the "admin" account to the empty password, using the SolarWinds Database Manager GUI (via local administrator access over Remote Desktop). Note that this password hash is only valid for the "admin" user (see notes below on salting). An empty PasswordHash for the "admin" user account corresponds to the following string:" /+PA4Zck3arkLA7iwWIugnAEoq4ocRsYjF7lzgQWvJc+pepPz2a5z/L1Pz3c366Y/CasJIa7enKFDPJCWNiKRg= Regardless of how an attacker gains access to the Accounts table, the easiest approach to gaining access is to backup the existing hash, then replace the PasswordHash column for an enabled administrative user. If the attacker has local administrator access to the Orion server, they can modify the Accounts table using the Orion Database Manager GUI application. If direct access to the SQL Server database for Orion is possible, a modification to the Accounts table will allow for easy access to the console. An attacker that can man-in-the-middle the SQL Server communication can use this to login to the Orion web console with an arbitrary password by replacing the password hash when the web server queries the Accounts table during login. An attacker can then monitor network traffic between the Orion server and a separate SQL Server instance, extracting hashed user passwords and encrypted network device credentials. The Orion product is typically managed from the web console this can use a local account database or an existing Active Directory service. Gaining access to the web console without a login Since the Orion server houses credentials and can often be used to push and pull network device configurations, it can be a gold mine for expanding access during a penetration test. An Orion system used to manage a large network will typically use a standalone SQL Server installation, while smaller networks will use a local SQL Server Express instance. The Orion product uses a Microsoft SQL Server backend to store information about user accounts, network devices, and the credentials used to manage these devices. We found some fun ways to abuse this product during security tests and wanted to share our notes with the community. The Orion platform includes modules such as the Network Engineers Toolkit, Web Performance Monitor, and Network Configuration Management, among many others. The SolarWinds Orion product suite in particular is popular with network administrators and IT teams of all sizes. We run into a wide variety of network management solutions during our security assessments and penetration tests.
0 kommentar(er)
