[kwlug-disc] Identify this exploit?

[John Van Ostrand]

There is more than one way a user agent can get the /etc/passwd file from a
web server. One way is to exploit a bug in the web server software. Another
way is for the administrator of the server to allow access in its
configuration. If you change the <Directory /> directive to allow access
and you have no system-wide security to prevent it, a user agent can access
that file.

So, yes, a horribly configured web server can allow access to that file.

On Sat, Dec 28, 2019 at 12:05 PM Mikalai Birukou via kwlug-disc <
kwlug-disc at kwlug.org> wrote:

> ## further rumbling :(
>
> I'll question the use of words "if you horribly misconfigure your web
> server" as in "should we put the blame there"?
>
> Let's zoom out from this particular GET request to /etc/passwd
>
> This is a directory traversal attack. In my case, hacked confluence
> server, an attacker probably tried to read /etc/passwd as well, why not
> try? In *standard* confluence configuration confluence user is added to the
> system, under which app is run. Hacked process placed into cron for
> confluence user a regularly running script that was pulling some binary via
> two hoops. That binary was taking all of CPU, i.e. it was crypto mining,
> not the protein folding! Even properly configured by admin server is
> vulnerable.
>
> As an admin, what am I supposed to do, when a standard setting with this
> bug in code let's anyone from the web. There was no horrible
> misconfiguration on my confluence server. I was spared by isolating the
> server with LXC, and not having important stuff on that server.
>
> You may ask, why the server was allowed to egress to get bad code. This
> atlassian shit refuses to work cleanly without egress -- updates, etc. May
> be I should've blackholed DNS egress? Exit hoops used ips.
>
> Attackers found my confluence server, cause it was on the domain
> confluence.3nsoft.net. Third section in domain, named after the product
> -- this is a give away, exploited by these automated web trawling
> operations. Should I call this domain a "horrible misconfiguration"?
>
> If you happen to have a web app with touchy data, do the following. Set it
> up in LXC. Setup tor proxy in LXC. Use your stuff from Tor browser. At
> least you are not enumerated in DNS for blanked targeting. Yey for Tor! The
> kicker is that it may take you less time to setup Tor then to make a
> separate domain and setup TLS, ... we configure TLS proxy to be on a
> separate system, right? :)
>
>
> On 2019-12-28 11:14 a.m., John Van Ostrand wrote:
>
> I think you can also be exposed if you horribly misconfigure your web
> server to allow access to those directories and files.
>
> On Sat, Dec 28, 2019 at 10:06 AM Mikalai Birukou via kwlug-disc <
> kwlug-disc at kwlug.org> wrote:
>
>> Yes, this dot operator is not sanitizing paths.
>>
>> Is this a "let's try" automated trawling of web? I wonder, what region is
>> request IP from.
>> On 2019-12-28 10:00 a.m., Mikalai Birukou via kwlug-disc wrote:
>>
>> I've duckduckgo-ed GET /download.php?file=../.
>>
>> This shows up
>> https://www.tutorialrepublic.com/php-tutorial/php-file-download.php
>>
>> There is download.php example file in it with
>>
>> ```
>>
>>     $file = urldecode($_REQUEST["file"]); // Decode URL-encoded string
>>     $filepath = "images/" . $file;
>>
>> ```
>>
>> PHP isn't my language, but nothing here jumps out, saying sanitize path.
>>
>> How many people can use this example to add a download functionality to
>> whatever app/site. StackOverflow style programming?
>>
>> May be its a good idea to search system for download.php?
>>
>>
>> On 2019-12-28 1:49 a.m., Paul Nijjar via kwlug-disc wrote:
>>
>> In my Apache logs I saw something like this, and my search-engine
>> skills are weak:
>>
>> 133.18.209.124 - - [27/Dec/2019:04:09:39 -0500] "GET /download.php?file=../../../../../../../../../../../../etc/passwd HTTP/1.1" 404 209 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
>>
>> It's pretty obvious what they are trying to do, but I am having
>> trouble figuring out what the target is, exactly. Is this an exploit
>> in a popular web package I should know about?
>>
>> - Paul
>>
>>
>> _______________________________________________
>> kwlug-disc mailing listkwlug-disc at kwlug.orghttp://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>
>
> --
> John Van Ostrand
> At large on sabbatical
>
>
> _______________________________________________
> kwlug-disc mailing listkwlug-disc at kwlug.orghttp://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>


-- 
John Van Ostrand
At large on sabbatical
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20191228/f2ea7fad/attachment.htm>