g/omnivista-rce
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Minor readme changes

Browse Source
This commit is contained in:
Giulio 2019-11-29 11:03:36 +01:00
parent a49df9bab0
commit 9d8a4eb5e9
1 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -33,7 +33,7 @@ Since the 4760 is an ancient product I fired up a Windows XP virtual machine and
When i started getting frustrated with all this ancient enteprisise crap, i finally found the PHP files inside a CAB archive. When i started getting frustrated with all this ancient enteprisise crap, i finally found the PHP files inside a CAB archive.
## Vulnerbilities ## Vulnerabilities
### 4760 pre auth RCE ### 4760 pre auth RCE
@ -306,11 +306,12 @@ function DecodePwd($data)
``` ```
### 8770 post auth RCE (to be verified) ### 8770 post auth RCE (to be verified)
Unfortunately I do not have access to the 8770 files and i can't write (yet) reliable code for this one, so a contribution would be welcome.
By default, the installation also listens on port 389. By connecting to port 389 with the leaked credentials, one can edit the whole ldap tree including seeing and modifying the hashed password `AdminNmc` user which is the administrator of the PHP web interface. By using the newly obtained credentials it should not be a problem to upload a PHP file as an asset of an existing template. By default, the installation also listens on port 389. By connecting to port 389 with the leaked credentials, one can edit the whole ldap tree including seeing and modifying the hashed password `AdminNmc` user which is the administrator of the PHP web interface. By using the newly obtained credentials it should not be a problem to upload a PHP file as an asset of an existing template.
Unfortunately, while all the previous vulnerabilities do work even when a "Directory License" (ndr the license specific for the PHP interface) is not present because the license check isn't done as the first thing, this last one do not. It is possible to login and obtain a valid session with the leaked credentials, but it doesn't seem possible to get a valid `themeDate` in session. Unfortunately, while all the previous vulnerabilities do work even when a "Directory License" (ndr the license specific for the PHP interface) is not present because the license check isn't done as the first thing, this last one do not. It is possible to login and obtain a valid session with the leaked credentials, but it doesn't seem possible to get a valid `themeDate` in session.
Since I do not have access to the 8770 files and i can't test the upload code for the 8770.
## Other issues ## Other issues
@ -325,3 +326,4 @@ Unfortunately, while all the previous vulnerabilities do work even when a "Direc
I did not find an exploitable chain but: all the PHP version shipped with this product have multiple unserialize CVE and I did not find a way but it is possible to play with the COM class. I did not find an exploitable chain but: all the PHP version shipped with this product have multiple unserialize CVE and I did not find a way but it is possible to play with the COM class.
* LDAP injections? * LDAP injections?