New answers tagged apache
So after a simple test of 127.0.0.1 | whoami It came up with the output "root" So essentially i could do anything if i piped it in after the IP address. For example i had a user name jason who is a normal user with no special privileges. i was able to add him to the sudoers file with echo "jason ALL=(ALL) ALL" >> /etc/sudoers After this i was ...
If the command shell is running as root and User supplied input is not properly validated then it will execute whatever command you will pass to the shell. I think there will be proper validation of the inputs passed by the users. Like when a user will enter the IPv4 address then it will be combination of integers and dots and for IPv6 it will be integer ...
please correct me if i'm wrong. ok. I have logged into a web server as admin through the Login page in browser. no, you havent. you have logged into a web-application onto this webserver. it essentially will ping any ip address that you input. (tested with local and external URL's) IPs. you tested IPs, not URLs with "ping" I know for ...
The site at http://cipherli.st has config snippets for setting up Qualys-rated A-Grade TLS for Apache, nginx and lighttpd. It also includes statements for HSTS, OCSP-Stapling and X-Frame-Options.
Use the following SSL options in apache. SSLProtocol -all +TLSv1.2 +TLSv1.1 +TLSv1 -SSLv3 -SSLv2 SSLHonorCipherOrder on SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
In your case I would recomend a VPN server. This appears to be a very secure site, and you hardened the server side very well. Using a VPN infrastructure will put another barrier between the server and the attacks. If you already have the users receiving and entering the authorization code, they will be able to connect to a VPN without much trouble. In my ...
You must first look at all configuration files if SSLv3 is enabled on some vhost: grep -i -r "SSLProtocol" /etc/apache Take the list of files grep found, and edit the configuration as bellow: SSLEngine on SSLProtocol TLSv1 SSLHonorCipherOrder On SSLCipherSuite RC4-SHA:HIGH:!ADH Restart Apache afterwards and it must work.
Except for the log cleaning the other answers mentioned, there shouldn't be any danger from having a writable log file. A readable log file on the other hand can lead to log poisoning, which can turn a local file inclusion into a code execution vulnerability. The attack might look like this: An attacker visits example.com/<?php // code you want to ...
Servers need to save their activities and performance on specific files. ErrorLog is the file where Apache saves its errors defined by their name and location. So by understadning the role of this file you can guess that only the server itself must be allowed to write on this file otherwise miscreants will write anything else to mislead you to take actions ...
Log files are often used to detect suspicious activities, like attacks. But, if the log file can be modified by the attacker itself, (s)he can clean up the logs after the attack or plant false information which confuse the after-attack analysis.
My first order of business would be to block traffic arriving from the external/untrusted interface at the firewall with a destination address/port matching your web server. This is the whole point of having a firewall. When it comes to your web server I would avoid using a .htaccess file unless you do not control the server and have to rely on user level ...
They may only have access to the Apache user account, but there may be another exploit or misconfiguration on your particular system that would enable an attacker to elevate their privileges to those of root. Local privilege escalation happens when one user acquires the system rights of another user. Network intruders have many techniques for increasing ...
Stick the following script in your webserver's /cgi-bin/ directory and chmod it a+x: #!/bin/bash echo "Content-Type: text/plain" echo "" echo "Bash is here" Note that this explicitly invokes bash, so systems with an unpatched bash will show as vulnerable even if the system shell is something else.
You are right that you gain access to the UID of the process/script you exploited. In the case of the Apache identity with no mandatory access control and no proper separation of developer and apache roles, you can: destroy or deface the websites run by your Apache change websites' code to leak all the user database at a fixed URL that you can then consult ...
There are still some RC4 ciphers in your list. To check which ciphers are offered by the server enter your list into 'openssl ciphers -V', i.e. $ openssl ciphers -V 'ALL:!ADH:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT' | grep RC4 0xC0,0x11 - ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 0xC0,0x07 - ...
Do you use the hybridauth lib in any of your php applications? There is a vulnerability in this library, if you do not follow the installation instructions and remove the install.php file, then you will have left your system open to attack. more details on this: https://github.com/hybridauth/hybridauth/issues/241 ...
In /etc/apache2/sites-available/default, make sure you have AllowOverride All instead of AllowOverride None. With None, .htaccess files are not parsed/evaluated.
The HTTP request is for / (the index page of your webserver) with a query string of "search=<chunk of VBscript>" If you've got a vulnerable webserver (I don't know what makes a webserver vulnerable, but the "%00" in the URL makes me think it's related to inconsistent handling of null bytes), the script attempts to download and run "getsetup.exe", which ...
Aside from CGI, one overlooked use of sh is in exec() calls, or through the use of system() and popen(), on most Linux systems this means bash. The exec() family of calls are often used with "/bin/sh -c" to provide various features like shell redirection, pipelines or even just argument expansion when invoking processes. Apache uses exactly this (via APR, ...
If you are not sure you can disable the cgi module sudo a2dismod mod_cgi or remove LoadModule in httpd.conf. As shaomoon mentioned mod_php, mod_perl and mod_python are not effected. Anyway you should simply install the patch. If your bash is not vulnerable your apache will also be protected from this attack.
According to Redhat advisory: mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected. Read more about it from : https://access.redhat.com/node/1200223
Secure bash and you have secured the box. There are patches available in most distributions or you could compile and patch it yourself if you run a distribution that is not yet patched.
This isn't a new attack so to speak. It is simply an injection attack that is hoping that you have bad parsing on your code. If you did certain types of processing, this could result in code execution, but it is a fairly elementary attack from the looks of it and isn't a concern as long as you validate user input before putting it through anything that ...
Top 50 recent answers are included