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

Moar typos

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

18
README.md
View File

@ -1,7 +1,7 @@
# Alcatel-Lucent Omnivista 4760/8770 RCE 0day
### Tldr
* *4760* suffers an unauthenticated remote code execution as SYSTEM. No special configuration is required
* *8770* and *4760* both suffer a remote administrative password dislclosure. No special configuration required
* *8770* and *4760* both suffer a remote administrative password disclosure. No special configuration required
* *8770* suffer an authenticated remote code execution vulnerability. When chained with the disclosure vulnerability, it becomes an unauth RCE. In this case access to the port 389 and a directory license are required
## Previous work
@ -9,7 +9,7 @@
* https://github.com/malerisch/omnivista-8770-unauth-rce
## Intro
I did noticed this software a while ago while doing a penetration test. It captured my attention because it had a php interface which seemed very old a not greatly designed (not only graphically). As shown in the previous section, there wasn't any known vulnerability in this component. I wasn't unable to find any useful vulnerability without the source code, but only a few hints:
I did notice this software a while ago while doing a penetration test. It captured my attention because it had a php interface which seemed very old and not greatly designed (not only graphically). As shown in the previous section, there wasn't any known vulnerability in this component. I wasn't unable to find any useful vulnerability without the source code, but only a few hints:
* Exposed error log in `/log/error.log/`
* Error log showed LDAP errors when trying special characters in login and search forms
@ -29,8 +29,8 @@ I had a bit of experience in looking for not easily available softwares:
3. Look on 4shared.com :) https://www.4shared.com/rar/HsteugXy/A4760_R500702b.html (while the search function is not much powerful, sorting by size helps a lot)
## Unpacking it
Since the 4760 is an ancient product I fired up a Windows XP virtual machine and tried installing it. Like it happens most of the time with enterprise software, the installation failed and neither the main services were set up properly nor any PHP files was extracted. Part of the files were packed with the ancient ACE file format, probbly with some custom modifications, and even binwalk couldn't do much.
When i started getting frustrated with all this ancient enteprisise crap, i finally found the PHP files inside a CAB archive.
Since the 4760 is an ancient product I fired up a Windows XP virtual machine and tried installing it. Like it happens most of the time with enterprise software, the installation failed and neither the main services were set up properly nor any PHP files was extracted. Part of the files were packed with the ancient ACE file format, probably with some custom modifications, and even binwalk couldn't do much.
When I started getting frustrated with all this old enterprise crap, i finally found the PHP files inside a CAB archive.
## Vulnerabilities
@ -50,7 +50,7 @@ if ($MyG["void"] == "phDPhd") {
?>
```
The following two functions are used to get POST and GET variables as well as to to manage SESSION.
The following two functions are used to get POST and GET variables as well as to manage SESSION.
_utils.php_
```
@ -143,7 +143,7 @@ class EditThemeAction
```
The default themes are numbered from 1 to 4 and each one has its files stored in `/theme/<id>`. Each theme folder contains a `params.st` file which contains a serialized PHP Object containing the theme configuration.
However, as seen below, the authentication and permission check is not performed when actually saving an edit. The only condition that might be a problem is the `CompareThemeDate()`, which compares the last edit time of the `params.st` file with the value saved in session in the code above (`$MyG["themeDate"] = $skin->GetLastMDate()`). This check, intended or not, prevent an unauthenticated user to perfor the save, unless in the destination folder a `params.st` file is not yet present.
However, as seen below, the authentication and permission check is not performed when actually saving an edit. The only condition that might be a problem is the `CompareThemeDate()`, which compares the last edit time of the `params.st` file with the value saved in session in the code above (`$MyG["themeDate"] = $skin->GetLastMDate()`). This check, intended or not, prevents an unauthenticated user to do the save, unless in the destination folder a `params.st` file is not yet present.
_SaveThemeAction.php_
```
@ -269,8 +269,8 @@ abstract class Action
?>
```
So the code use the `COM` native PHP module to run some shell commands in order to get the LDAP bind credentials, which in this case are of "cn=directory manager" that is the administrator user fo the instance. The password is encoded with a simple reversible algorithm we'll see below. Then the data is secured in the user session, which is stored server side.
While this code is bad, and the whola idea of putting the cleartext credentials in the registry doesn't make sense to me, the real problem is a webserver configuration: all user session files are stored in a public directory! So by just starting a session and getting the respective session file it is possible to get the credentials.
So the code use the `COM` native PHP module to run some shell commands in order to get the LDAP bind credentials, which in this case are of "cn=directory manager" that is the administrator user of the instance. The password is encoded with a simple reversible algorithm we'll see below. Then the data is secured in the user session, which is stored server side.
While this code is bad, and the whole idea of putting the cleartext credentials in the registry doesn't make sense to me, the real problem is a webserver configuration: all user session files are stored in a public directory! So by just starting a session and getting the respective session file it is possible to get the credentials.
Sessions are stored in `/sessions/sess_<sessionid>`, simple as that.
The decode function:
@ -315,7 +315,7 @@ Since I do not have access to the 8770 files and i can't test the upload code fo
## Other issues
* Multipele calls to unserialize on untrusted data:
* Multiple calls to unserialize on untrusted data:
```
unserialize(gzuncompress($MyG["themes"]));