Otto's First investigation
#1
I'm starting a new short project to get me going and dust off the rust on my
computer skills.

I thought a good habit to take would be to check recent vulnerabilities
and look into them, understand how they work and what impact they might have.
Aaaand maybe a little bit of snooping around, historically it's not a major
crime, but definitely a gateway one.

First, I boot up a new VM with a new tor circuit, and let's get started. I head
to packetstormsecurity.com, because they're pretty cool people trying to keep
the internet working. Cheers to them!

First hit: multiple XSS\Directory Traversal\FileUpload vulnerabilites in a CMS.

Christmas gift warning, also appreciate the use of the word 'Business' as a
form of polite burn:

```
Business recommendation:
------------------------
The vendor did not respond to our communication attempts, hence no patch is
available.

An in-depth security analysis performed by security professionals is highly
advised, as the software may be affected from further security issues.
```

Okay, I just wanted to have some fun on the internet, and this should be just
perfect.

Credits to Calvin Phang (Singapore Office) of SEC Consult Vulnerability Lab for
publishing his work, thanks!


Link: https://packetstormsecurity.com/files/15...pload.html
Sauce: https://github.com/robiso/wondercms/rele...-3.1.0.zip


Future plans:
=============

- Get the software and run it (update: got the zip)
- Break it
- Look over the internet if some instances are still accessible
(NFTW: this can't possibly be the case!)

Skills to improve
=================

- Learn more PHP
- Learn to break a new CMS
- Understand why it breaks
- Write and publish interesting posts

I'll update you as I progress on this project. But contributions are welcome!

Can't wait to get shodan running...

Take care,

Otto962
Reply
#2
Sounds like a good project to brush up skills! Yeah just read the security advisory. Since there's no PoC for this we'll have to figure it our on our own.

Set it up on localhost and start fuzzing!

Tried looking for some WonderCMS instances. Kind of broad results on google, I think we need to craft a google dork to narrow it down.

Not much results on:
- https://www.shodan.io
- https://censys.io
- http://thingful.net

But found some results on Zoomeye:
- https://www.zoomeye.org/searchResult?q=WonderCMS
Reply
#3
(07-21-2020, 02:04 AM)Insider Wrote: Sounds like a good project to brush up skills! Yeah just read the security advisory. Since there's no PoC for this we'll have to figure it our on our own.

Set it up on localhost and start fuzzing!

Tried looking for some WonderCMS instances. Kind of broad results on google, I think we need to craft a google dork to narrow it down.

Not much results on:
- https://www.shodan.io
- https://censys.io
- http://thingful.net

But found some results on Zoomeye:
- https://www.zoomeye.org/searchResult?q=WonderCMS

We could plug WonderCMS into AutoSploit see what comes up. I'm thinking out loud here because i haven't looked into this myself, but if we have unique names of functions or pages related to or in the source code of the CMS we can build a dork pretty easily. Also, are there any special services that make use of certain ports when you run this CMS? If so we can launch a Masscan looking for all hosts with that port accesible or rather in use. Refine the scans and enumeration parameters by scanning batches with Nmap and certain NSE scripts active.

Anyway, i took a look at some of the Zoomeye results and checked the hosts with the Shodan CLI. To see if there are any commonalities among the hosts. Now admittedly checking three hosts isn't statistically significant. But here's what i found.

Code:
shodan host 209.140.195.26

209.140.195.26
Hostnames:              chemlabs.hope.edu
City:                    Holland
Country:                United States
Organization:            Hope College
Updated:                2020-07-08T09:41:13.340629
Number of open ports:    1
Vulnerabilities:        CVE-2014-0117 CVE-2014-0118 CVE-2016-0736 CVE-2015-3185 CVE-2015-3184 CVE-2018-1312 CVE-2016-4975 CVE-2016-8612 CVE-2014-0226 CVE-2014-3523 CVE-2017-15710 CVE-2017-15715 CVE-2013-6438 CVE-2017-7679 CVE-2018-17199 CVE-2017-9788 CVE-2014-8109 CVE-2017-9798 CVE-2016-2161 CVE-2014-0231 CVE-2019-0220 CVE-2014-0098CVE-2018-1283 CVE-2016-8743

Ports:
    80/tcp Apache httpd (2.4.7)


shodan host 77.2.83.106

77.2.83.106
Hostnames:              x4d02536a.dyn.telefonica.de
City:                    Fürth
Country:                Germany
Organization:            O2 Deutschland
Updated:                2020-07-16T21:22:21.968905
Number of open ports:    1

Ports:
  8089/tcp 


shodan host 79.113.69.102

79.113.69.102
Hostnames:              79-113-69-102.rdsnet.ro
City:                    Timișoara
Country:                Romania
Organization:            Digi Romania
Updated:                2020-07-18T17:06:05.581207
Number of open ports:    1

Ports:
  1723/tcp

Always reassuring to see a host by such a name as chemlabs.hope.edu with a big old list of potential vulns.

In any case, i'd suggest gathering a more substantial data pool and doing our own portscanning and enumeration with Nmap. And collect data through some OSINT investigative work as well.

Interesting stuff, and i am looking forward to reading your report on the matter Otto.
Reply
#4
You don't need any third-party tools to figure this one out. Really.

Open index.php in a text editor since it's basically the entire code.

Now, you already have descriptions of what vulns have been found:
Code:
1. An XSS in the admin panel, i.e. when an admin tries to access a page and its 'filename' contains HTML/script data, causing an XSS.
--> I put filename in quotes because, well, you'll see why once you start poking around.
--> My hint for this one is look at page() (line 1370), slugify() (line 1834), and any relevant render() functions when called as an admin.

2. Files can be arbitrarily uploaded even through the extension filtering function that only typically allows media assets like images or videos.
--> Hint: It has to do with MIME types and not as much the extensive list of 'whitelisted' extensions (function @ 1893)

3. Directory traversal with admin privileges
--> Hint: Does the filtering for strings like '../' or '/' happen before or after the server decodes the data in the relevant $_REQUEST variables?

Because quite frankly you're not going to learn much about PHP if you're just trying to throw whatever you can at servers you find on Shodan that have Wonder installed. You know, especially since every single one of those vulnerabilities listed above are only actually accessible from the admin panel, and random sites aren't just going to give you the admin password (unless they only copied the files into their web server and never actually accessed them for the generated password, meaning it does actually give it to you in plaintext.)

I have faith you can figure it out. Seems you have a decent sense of initiative to tackle something like this for the learning experience.

But to all of you, please, for the love of God, at least read the code first and figure it out by hand before throwing your scanners and fuzzers at it. It's really not difficult to spot the problems, especially when the advisory literally tells you what to look for, essentially cutting 90% of the work out for you.
Reply
#5
(07-23-2020, 04:46 PM)poppopret Wrote: But to all of you, please, for the love of God, at least read the code first and figure it out by hand before throwing your scanners and fuzzers at it. It's really not difficult to spot the problems, especially when the advisory literally tells you what to look for, essentially cutting 90% of the work out for you.

I wrote AutoSploit, the neat thing about it is, among other things, that you can input search terms and it will return any host that fits the description. I was coming at it from a target acquisition standpoint. Now granted i wasn't familiar with this vulnerability before this thread. But having the advisory spell it out in a way and having a couple of vuln hosts to try would make developing a PoC a lot more convenient.
Reply
#6
(07-28-2020, 07:16 PM)Vector Wrote: I wrote AutoSploit, the neat thing about it is, among other things, that you can input search terms and it will return any host that fits the description. I was coming at it from a target acquisition standpoint. Now granted i wasn't familiar with this vulnerability before this thread. But having the advisory spell it out in a way and having a couple of vuln hosts to try would make developing a PoC a lot more convenient.

Except it doesn't, like, literally. The only way to make a 'vuln host' in this situation is by running your own instance. Each one of the vulns requires admin permissions to even access, and you don't get admin permissions just by going to a vulnerable website.

You need to know what the vuln is before making a dork or other parameters to find the vuln, let alone before writing the PoC and writing a script that you can plug into autosploit to actually perform the exploitation half.

Albeit a neat project you have going on, target acquisition should be the least of the worries when the thread only states learning about finding vulns/writingPoCs with learning PHP/whitebox testing in mind. (And of course the Shodan buzzword throwing at the very end, which really doesn't do anything.)
Reply
#7
(07-28-2020, 09:17 PM)poppopret Wrote: Except it doesn't, like, literally. The only way to make a 'vuln host' in this situation is by running your own instance. Each one of the vulns requires admin permissions to even access, and you don't get admin permissions just by going to a vulnerable website.

You need to know what the vuln is before making a dork or other parameters to find the vuln, let alone before writing the PoC and writing a script that you can plug into autosploit to actually perform the exploitation half.

Like i said earlier i wasn't acquainted with the nature of the vulnerability when i made my first post in this thread. And yes i am aware of the fact that finding hosts that run this CMS aren't vulnerable right off the bat. Since this is an authenticated vuln. Now, in my mind it is infinitely more interesting to acquire a number of remote hosts, that run the CMS, exploit to get admin privs and go from there than to do any sort of whitebox testing.

Granted i wasn't the one that started the thread or asked the question, however i find that doing 'live fire' exercises tend to be far more educational when it comes to any real world application of the skills you'll learn. After you succeed you submit a report to the organization or entity in question and that is that.


(07-28-2020, 09:17 PM)poppopret Wrote: Albeit a neat project you have going on, target acquisition should be the least of the worries when the thread only states learning about finding vulns/writingPoCs with learning PHP/whitebox testing in mind.

Perhaps you're right, however that doesn't take away from the fact that i have the freedom to express my own thoughts regarding this. Especially if it has the positive benefit of sparking an interesting discussion related to the subject matter. If you don't find the discussion surrounding this interesting, then feel free to not participate.
Reply