'SSL'에 해당되는 글 9건

  1. 2011/10/27 DoS Attack Tool Targeting SSL Servers
  2. 2011/07/27 sslsniff v0.8 with iOS Fingerprinting Support!
  3. 2011/04/25 SSL 인증서 릴레이 네트워크 중계 sslsniff
2011/10/27 13:26

DoS Attack Tool Targeting SSL Servers


A hacker group has released a proof-of-concept tool that exploits how encryption keys can be renegotiated to launch a distributed denial of service attack against Secure Sockets Layer servers.

A tool designed to launch denial of service attacks can bring down Secure Sockets Layer servers using just a laptop computer and a standard DSL connection.

Developed by a German group called The Hacker's Choice, THC-SSL-DOS tool is intended to be a proof-of-concept to disclose "fishy security" in the SSL protocol, the group wrote on The Hacker's Choice blog Oct. 24.

The tool implements the attack by establishing a large number of SSL connections with a given server to eventually consume all of the system resources and making the server unavailable. THC officially released the tool because a version had been leaked accidentally a few months earlier.

The tool exploits a widely known issue with how SSL connections work. A lot of server resources are required to successfully handle SSL "handshakes" at the beginning of a session to establish a secure connection. A client sending enough sessions requests can cause the server to fail. The issue is worsened if the server has the SSL renegotiation feature enabled to handle scenarios that involve processing the client-side certificate.

"It works great if the server supports SSL Renegotiation. It still works if SSL Renegotiation is not supported, but requires some modifications and more bots," the group wrote.

The feature "renegotiates" the key material of an SSL connection, such as in cases where client certificates are used. The Tor Project, which offers users anonymous proxies to hide Web activity, uses renegotiation, as does many smart cards used for Web authentication, Marsh Ray, a developer at PhoneFactor, wrote on the Full Disclosure mailing list.

"A security feature that was supposed to make SSL more secure makes it indeed more vulnerable to this attack," according to THC.

The attack can be mitigated by servers that have SSL acceleration hardware installed, which speeds up the processing of SSL operations.

The tool exists for both Windows and Unix and can be executed with one client on a typical home link. Experts have said in the past that a traditional distributed denial of service attack cannot be launched by home users because servers generally have superior bandwidth than the pipe available to DSL users. THC-SSL-DOS exploits the SSL handshakes to overcome the narrow bandwidth pipe and launch a successful attack without needing a large number of participants.

Attackers can still use the tool successfully on servers where SSL Renegotiation has been disabled. But this approach requires more than a single laptop. Taking on a large server farms that use SSL load balancers required 20 "average size" laptops and a connection with 120kbit/sec of traffic capacity, according to THC.

With threats growing and evolving, companies are trying to protect their environments by deploying Secure-Socket-Layer (SSL) to encrypt connections, Carl Herberger, vice president of security solutions at Radware, told eWEEK. However, a number of vulnerabilities have been exposed in the protocol recently and "most security tools" are not well-equipped to handle the rise of attacks against SSL, Herberger said.

Many hacktivist organizations who are having "less desired" effects with their current attack tools are migrating towards SSL-based attacks as they can "achieve dramatic results" in this space, according to Herberger. "Most companies are sitting ducks as vulnerabilities rise and security defenses are inadequate," he said.

For example, the Low-Orbit Ion Cannon tool favored by hacker groups like Anonymous made it possible for a large number of users on residential network connections to band together to launch an attack successfully and overcome the DSL limitations. However, the group recently released #RefRef, a new tool that was more powerful than LOIC to launch attacks.

"We are hoping that the fishy security in SSL does not go unnoticed. The industry should step in to fix the problem so that citizens are safe and secure again," THC said.

출처 : www.eweek.com

국내 변조 기사 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=20111026101742 

저작자 표시
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 0
2011/07/27 19:47

sslsniff v0.8 with iOS Fingerprinting Support!


Some History:

This tool was originally written to demonstrate and exploit IE'svulnerability to a specific "basicConstraints" man-in-the-middle attack. While Microsoft has since fixed the vulnerability that allowed leaf certificates to act as signing certificates, this tool is still occasionally useful for other purposes.

It is designed to MITM all SSL connections on a LAN and dynamically generates certs for the domains that are being accessed on the fly. The new certificates are constructed in a certificate chain that is signed by any certificate that you provide.

The New Scoop:

Version 0.6 has been significantly updated to additionally support the null-prefix attacks that I demonstrated at BlackHat 09 and Defcon 17. These allow for completely silent MITM attacks against SSL/TLS in the NSS, Microsoft CryptoAPI, and GnuTLS stacks — ultimately allowing for SSL communication in Firefox, Internet Explorer, Chrome, Thunderbird, Outlook, Evolution, Pidgin, AIM, irssi, and every other client that uses the Microsoft CryptoAPI to be intercepted.

sslsniff has also been updated to support the OCSP attacks that I published at Blackhat 09 and Defcon 17, thus making the revocation of null-prefix certificates very difficult. Additionally, sslsniff now supports modes for hijacking auto-updates from Mozilla products, as well as for Firefox/Thunderbird addons. Attackers can specify payloads of their choice, which will be delivered to the targets being man-in-the-middled.

sslsniff is useful for deploying other vulnerabilities as well. This is the tool that the people who pulled the recent MD5 hash collision publicity stunt used to demonstrate MITM attacks with their rogue CA-certificate. Also, anyone who is capable of obtaining a forged certificate by any means can easily deploy it through sslsniff with the targeted mode designed for null-prefix attacks.

For more information on these attacks, see the video from Defcon 17.

The three steps to get this running are:

Installing sslsniff

  • Install the sslsniff dependencies (openssl, libboost1.35-dev, libboost-filesystem1.35-dev, libboost-thread1.35-dev, liblog4cpp5-dev)
  • Unpack sslsniff-0.8.tar.gz, run './configure', run 'make'

sslsniff requires Linux 2.4/2.6, although it can easily be ported to other platforms.

Running sslsniff

  • sslsniff can now be run in the old "authority" mode or the new "targeted" mode. You can specify a single cert to sign new certificates with, or you can specify a directory full of certificates to use for targeted attacks (these can be null-prefix or universal wildcard certificates).
  • sslsniff can now also defeat OCSP, fingerprint clients to attack, and hijack auto-updates.
  • See the README for more information on how to run sslsniff

Setting up iptables

  • Flip your machine into ip_forward mode (echo 1 > /proc/sys/net/ipv4/ip_forward)
  • Add a rule to intercept SSL traffic (iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-ports <$listenPort>)
  • If you wish to fingerprint clients and only intercept some traffic based on client type, add a rule to intercept HTTP traffic (iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports <$httpListenPort>)

Running arpspoof

Assuming we want to intercept SSL traffic from 172.17.10.36, we need to trick that host into thinking that we're the router. Using arpspoof, we can convince the target that the router's MAC address is our MAC address.

  • arpspoof -i eth0 -t 172.17.10.36 172.17.8.1

At this point, any SSL traffic should get proxied by sslsniff and logged to the file you specify.

Development

The current sslsniff development branch can be found on github.

Changes in 0.8 (07/25/11)

  • Added an iOS fingerprinting mode.
  • Added support for intermediary certificates in authority mode.

Changes in 0.7 (04/23/11)

  • Fixed some networking shuffling bugs (thanks Daniel Roethlisberger)
  • Added basic compatibility with BSD pf (thanks Daniel Roethlisberger)

Changes in 0.6 (07/03/09)

  • Added support for null-prefix attacks
  • Added better logging support
  • Added OCSP denial.
  • Added support for hijacking auto-updates

Changes in 0.5 (02/16/09)

  • Switched default signing algorithm from MD5 to SHA1
  • Randomize generated certificate serial numbers
  • Added option for logging directory

Changes in 0.4 (08/22/02)

  • Included anonymously posted CA-signed certificate and key.

Changes in 0.3 (08/22/02)

  • Added mode to only log HTTP POSTs

Changes in 0.2 (08/21/02)

  • Use constant RSA key pair.
  • Cache SSL session ids.
  • Eliminate source port hack.


출처 : http://www.thoughtcrime.org/
저작자 표시
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 0
2011/04/25 18:37

SSL 인증서 릴레이 네트워크 중계 sslsniff


Some History:

This tool was originally written to demonstrate and exploit IE's vulnerability to a specific "basicConstraints" man-in-the-middle attack. While Microsoft has since fixed the vulnerability that allowed leaf certificates to act as signing certificates, this tool is still occasionally useful for other purposes.

It is designed to MITM all SSL connections on a LAN and dynamically generates certs for the domains that are being accessed on the fly. The new certificates are constructed in a certificate chain that is signed by any certificate that you provide.

The New Scoop:

Version 0.6 has been significantly updated to additionally support the null-prefix attacks that I demonstrated at BlackHat 09 and Defcon 17. These allow for completely silent MITM attacks against SSL/TLS in the NSS, Microsoft CryptoAPI, and GnuTLS stacks — ultimately allowing for SSL communication in Firefox, Internet Explorer, Chrome, Thunderbird, Outlook, Evolution, Pidgin, AIM, irssi, and every other client that uses the Microsoft CryptoAPI to be intercepted.

sslsniff has also been updated to support the OCSP attacks that I published at Blackhat 09 and Defcon 17, thus making the revocation of null-prefix certificates very difficult. Additionally, sslsniff now supports modes for hijacking auto-updates from Mozilla products, as well as for Firefox/Thunderbird addons. Attackers can specify payloads of their choice, which will be delivered to the targets being man-in-the-middled.

sslsniff is useful for deploying other vulnerabilities as well. This is the tool that the people who pulled the recent MD5 hash collision publicity stunt used to demonstrate MITM attacks with their rogue CA-certificate. Also, anyone who is capable of obtaining a forged certificate by any means can easily deploy it through sslsniff with the targeted mode designed for null-prefix attacks.

For more information on these attacks, see the video from Defcon 17.

The three steps to get this running are:
  • Download and run sslsniff-0.7.tar.gz
  • Setup iptables
  • Run arp-spoof

Installing sslsniff

  • Install the sslsniff dependencies (openssl, libboost1.35-dev, libboost-filesystem1.35-dev, libboost-thread1.35-dev, liblog4cpp5-dev)
  • Unpack sslsniff-0.7.tar.gz, run './configure', run 'make'

sslsniff requires Linux 2.4/2.6, although it can easily be ported to other platforms.

Running sslsniff

  • sslsniff can now be run in the old "authority" mode or the new "targeted" mode. You can specify a single cert to sign new certificates with, or you can specify a directory full of certificates to use for targeted attacks (these can be null-prefix or universal wildcard certificates).
  • sslsniff can now also defeat OCSP, fingerprint clients to attack, and hijack auto-updates.
  • See the README for more information on how to run sslsniff

Setting up iptables

  • Flip your machine into ip_forward mode (echo 1 > /proc/sys/net/ipv4/ip_forward)
  • Add a rule to intercept SSL traffic (iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-ports <$listenPort>)
  • If you wish to fingerprint clients and only intercept some traffic based on client type, add a rule to intercept HTTP traffic (iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports <$httpListenPort>)

Running arpspoof

Assuming we want to intercept SSL traffic from 172.17.10.36, we need to trick that host into thinking that we're the router. Using arpspoof, we can convince the target that the router's MAC address is our MAC address.

  • arpspoof -i eth0 -t 172.17.10.36 172.17.8.1

At this point, any SSL traffic should get proxied by sslsniff and logged to the file you specify.



출처 : http://www.thoughtcrime.org/software/sslsniff/
저작자 표시
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 0