I have a command line tool that can download any URLs likewget (only for vcs systems) but not it’s source code, how can I test if it is vulnerable to POODLE?

There are lot of online automated tools for testing if a web server or a web browser is vulnerable to POODLE.

But as my program is command line only, how to check if it supports SSLv3 over http?

  • check out my answer here: security.stackexchange.com/a/128009/6253 – schroeder Jun 23 '16 at 22:05
  • @schroeder : as the tool fails to get an http response, the answer is the same whether it support sslv3 or the server isn’t an http server (it says failed to clone the repository, try an another url). If the http server doesn’t contains any resources, it would replythere isn’t any repositories host thereon the screen. – user2284570 Jun 23 '16 at 22:28

Command line tools shouldn't be vulnerable to POODLE.

The reason is that POODLE is a cross-domain attack where the attacker can send cross-origin requests to the vulnerable endpoint and then use their Man-in-the-Middle/eavesdropper position to read cookie data sent with the request.

An attacker can run Javascript in any origin in a browser and cause the browser to make requests (with cookies) to any other origin. If the attacker does this block duplication trick they have a 1-in-256 chance that the receiver won't reject the record and close the connection. If the receiver accepts the record then the attacker knows that the decryption of the cookie block that they duplicated, XORed with the ciphertext of the previous block, equals seven. Thus they've found the last byte of the cookie using (on average) 256 requests.

That said, there are other vulnerabilities present in SSLv3 that mean an upgrade is recommended.

Running an SSLv3 server is the best way to test it, as Ángel points out.

| improve this answer | |
  • So if I understand, if a server support both tls and sslv3, then there are no problems in my case, isn’t it ? – user2284570 Jun 24 '16 at 15:43
  • I would say yes, as long as weak ciphers are also disabled, and as long as renegotiation is disabled, or secure renegotiation is enabled. However, since there are always advancements within the SSL/TLS protocol, it would be wise to always work towards disablement of legacy versions - You never know when the next vulnerability will be found. – SilverlightFox Jun 26 '16 at 13:58

I would start by finding out which SSL library it is using. I wouldn't be surprised if it used (maybe embedded) an old openssl version, in which case there would be a number of vulnerabilities to take into account that could be easily extracted, not just poodle.

As pointed out by schroeder, you could launch a webserver that doesn't speak anything newer with:

openssl s_server -no_tls1 -no_tls1_1 -no_tls1_2

But it is much easier to attempt retrieving https://sslv3.dshield.org/vulnpoodle.png which is part of the https://www.poodletest.com/ test

sslv3.dshield.org is a server which only speaks ssl3. Thus, if your tool is able to retrieve it, it supports SSL3 in the configuration you are using.

| improve this answer | |
  • I forgot about the png grab. That would make for a good POODLE test. – schroeder Jun 23 '16 at 22:14
  • @schroeder I knew there were purposefully misconfigured test servers out there for SSL3. Was lucky finding this quickly :) – Ángel Jun 23 '16 at 22:16
  • heemmmm looks like I would need a web server. – user2284570 Jun 23 '16 at 22:24
  • @user2284570 sslv3.dshield.org is a public web server you can use. – Ángel Jun 23 '16 at 22:26
  • sslv3.dshield.org is a server which only speaks ssl3and that use starcom as a ca. which is not trusted by the tool (yes I can’t modify the tool’s ca store). – user2284570 Jun 23 '16 at 23:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.