Monday, December 19, 2011

Fast and Full-Featured SSL Configuration Scanner - SSLYZE

Transport Layer Security (TLS), commonly called SSL, is one of the most widely used protocols to secure network communications. As costs fall and user security and privacy expectations rise companies are deploying it more widely every year. Attacks against the CA system, SSL implementation flaws and aging protocol versions have grabbed news headlines, bringing attention to weak configurations, and the need to avoid them. Additionally, server misconfiguration has always greatly increased the overhead caused by SSL, slowing the transition to improved communications security.
To help improve system configurations, iSEC is releasing the free software “SSLyze” tool. They have found this tool helpful for analyzing the configuration of SSL servers and for identifying misconfiguration such as the use of outdated protocol versions, weak hash algorithms in trust chains, insecure renegotiation, and session resumption settings.
SSLyze is a stand-alone python application that looks for classic SSL misconfiguration, while providing the advanced user with the opportunity to customize the application via a simple plugin interface.
Features
  • Insecure renegotiation testing
  • Scanning for weak strength ciphers
  • Checking for SSLv2, SSLv3 and TLSv1 versions
  • Server certificate information dump and basic validation
  • Session resumption capabilities and actual resumption rate measurement
  • Support for client certificate authentication
  • Simultaneous scanning of multiple servers, versions and ciphers
For example, SSLyze can help user’s identify server configurations vulnerable to THC’s recently released SSL DOS attack by checking the server’s support for client-initiated renegotiations. For more information on testing for client-initiated renegotiations, you can read here.
You can download sslyze here:
sslyze-0.3_src.zip


from Darknet

for more detail click here : SSLYZE

Sunday, December 4, 2011

Hiding messages in VoIP packets

A group of researchers from the Institute of Telecommunications of the Warsaw University of Technology have devised a relatively simple way of hiding information within VoIP packets exchanged during a phone conversation.


They called the method TranSteg, and they have proved its effectiveness by creating a proof-of-concept implementation that allowed them to send 2.2MB (in each direction) during a 9-minute call. IP telephony allows users to make phone calls through data networks that use an IP protocol. The actual conversation consists of two audio streams, and the Real-Time Transport Protocol (RTP) is used to transport the voice data required for the communication to succeed.But, RTP can transport different kinds of data, and the TranSteg method takes advantage of this fact."Typically, in steganographic communication it is advised for covert data to be compressed in order to limit its size. In TranSteg it is the overt data that is compressed to make space for the steganogram," explain the researchers. "The main innovation of TranSteg is to, for a chosen voice stream, find a codec that will result in a similar voice quality but smaller voice payload size than the originally selected."


In fact, this same approach can - in theory - be successfully used with video streaming and other services where is possible to compress the overt data without making its quality suffer much.To effect the undetected sending of the data through VoIP communication, both the machine that sends it and the one that receives it must be previously configured to know that data packets marked as carrying payload encoded with one codec are actually carrying data encoded with another one that compresses the voice data more efficiently and leaves space for the steganographic message (click on the screenshot to enlarge it):






The method is efficient in sending and receiving the data, but in order to be considered good enough to use, it must be undetectable by outside observers.


According to the paper, the first thing can be accomplished whether VoIP phones or intermediate network nodes are used by one or both participant in the conversation, but the second one only if two VoIP phones are the sending and receiving nodes, since there is no change of format of voice payloads during the traversing of the network.

Researcher: DEP Would Have Stopped Exploit Used In RSA Breach

New research dissecting the initial exploit and malware used in the attack against RSA concludes that Windows' Data Execution Prevention (DEP) would have halted the attack if the victims were on Windows 7 machines.
DEP, which is built into Windows 7 and is available for Vista and XP SP2, would have stopped the exploit in its tracks, says Rodrigo Rubira Branco, director of Qualys' Vulnerability & Malware Research Labs, who tested the exploit and published his results today. He says it appears that the EMC RSA victims were running XP and did not have DEP enabled on their systems.

"The victims were using Windows XP, which is DEP-capable since SP2. I know that for sure because the exploit won't work against Windows 7 due to limitations in the exploit code itself," Branco says. "In this specific case, it was possible to change the exploit to work against DEP, but the exploit has been likely reused from another target. Having DEP on would prevent the exploitation.

"We can't say that the attacker would not change the exploit and try again, but it clearly was going to give more time to the defense to detect the attack and mitigate its effects."

Researchers have demonstrated bypassing DEP in older versions of Windows. Branco says the exploit demonstrates how even using patched, older technologies can leave an organization vulnerable. "If you use old technologies, even when they are patched, they are more exposed since the prevention mechanisms are not there, and when they are, they are easily bypassed," he says.

Branco, who published his new research today in a blog post, says digging into the original phishing email and rigged Excel attachment helped confirm the theory that the attackers wanted access to U.S. military contractors, not RSA itself.


RSA has said publicly that its breach was a means to an end for the attackers. "We were a path to try to attack other organizations," says Eddie Schwartz, CSO for EMC RSA. "That was very clear just based on other things we've subsequently learned from the attack."

And F-Secure, which was the first to find the RSA email on VirusTotal, believes the attackers needed RSA SecurID tokens to get into Lockheed-Martin and Northrop Grumman.

EMC RSA's Schwartz says Branco's in-depth analysis of a targeted attack can help organizations in their own environments. "The way it describes the different stages of an exploit and how these types of attacks work and the risks associated with them" is helpful, Schwartz says.

"If you start to look and say, 'Here's how an attack like this begins,' you can start mapping it to other attacks you've seen and understand how it fits into the different portions of the 'kill chain' of the attack," he says. "After you experience this kind of attack, you become more sensitive to certain types … of indicators of compromise" and can begin to piece together potential targeted attacks as they emerge.

The spreadsheet used to infect EMC RSA users contained an embedded Flash object with an Adobe Flash Player zero-day exploit. When triggered, the exploit installed the Poison Ivy remote administrative tool, which is known for keylogging, scanning, and data exfiltration, among other things.

Still unclear is how the attackers chose their targets for the emails, and just how much intelligence they had about RSA's systems, if at all. "Did the attacker have all the information previously -- so, he knew RSA was using Windows XP, without DEP -- or did he just try to see if it works? This actually tells a lot about the sophistication of the attack," Qualys' Branco says.

Mikko Hypponen, chief research officer at F-Secure, said in his April post that the email used in the attack was simple, but the exploit was not. "And the ultimate target of the attacker was advanced. If somebody hacks a security vendor just to gain access to their customers systems, we'd say the attack is advanced, even if some of the interim steps weren't very complicated," he wrote.


Even so, the key steps to protecting against this attack would be patching, which Branco says RSA likely did, and running the latest data protection mechanisms, like DEP. Another key would be understanding the weakest points in the chain of access to the most valuable data, he says. "I mean, the target will always be the easiest one to target, like HR people, in this case. How the attack spread horizontally in the organization until it compromised really critical customer data is not really clear," he says.

And just how the attackers got to the SecurID servers remains a mystery, he says.

While some security experts have criticized RSA for keeping mum on many details surrounding the attack, Branco lauded RSA's openness. "RSA was very open regarding the attack, and this demonstrates a great level of maturity from their side. I wish we had more and more companies openly discussing the issues so everybody in the community could benefit and learn the hard lessons," he says.

from DarkReading