I’d imagine the problem would only really be a big issue inside networks as who exposes SMB ports to the outside world anyway (TCP ports 139 and 445).

But as we all know, the biggest threat to corporate network security ALWAYS comes from the inside.

Microsoft late on Friday confirmed that an unpatched vulnerability exists in Windows 7, but downplayed the problem, saying most users would be protected from attack by blocking two ports at the firewall.

In a security advisory , Microsoft acknowledged that a bug in SMB (Server Message Block), a Microsoft-made network file- and print-sharing protocol, could be used by attackers to cripple Windows 7 and Windows

The zero-day vulnerability was first reported by Canadian researcher Laurent Gaffie last Wednesday, when he revealed the bug and posted proof-of-concept attack code to the Full Disclosure security mailing list and his blog. According to Gaffie, exploiting the flaw crashes Windows 7 and Server 2008 R2 systems so thoroughly that the only recourse is to manually power off the computers.

At the time, Microsoft only said it was investigating Gaffie’s reports.

And well let’s face is, this is not the first time that a serious flaw that can be remotely exploited has been discovered in SMB.

It doesn’t seem like the most secure of protocols, I really doubt Microsoft developed it using SDL (Security Development Lifecycle).

It seems in this case though it’s limited to a DoS attack, perhaps due to all the fancy security controls Microsoft has implemented in the Windows 7 kernel.

Then on Friday, it took the next step and issued the advisory. “Microsoft is aware of public, detailed exploit code that would cause a system to stop functioning or become unreliable,” Dave Forstrom, a spokesman for Microsoft security group, said in an e-mail. “The company is not aware of attacks to exploit the reported vulnerability at this time.”

Forstrom echoed Gaffie’s comments earlier in the week that while an exploit could incapacitate a PC, the vulnerability could not be used by hackers to install malicious code on a Windows 7 system.

Both SMBv1 and its successor, SMBv2, contain the bug. “Windows Vista, Windows Server 2008, Windows XP, Windows Server 2003 and Windows 2000 are not affected,” assured Forstrom.

Attacks could be aimed at any browser, not just Internet Explorer (IE), Microsoft warned. After tricking users into visiting a malicious site or a previously-compromised domain, hackers could feed them specially-crafted URIs (uniform resource identifier), and then crash their PCs with malformed SMB packets.

Even so, I’m sure a skilled attacker could probably work out a way to drop some malicious code into the OS using this PoC and well if I know the underground they probably already are.

This vulnerability is the first official zero-day reported and confirmed by Microsoft in Windows 7 since the new operating system went on sale October 22nd.

I’m sure there will be many more.

Source: Network World

But then people tend to say that about most things don’t they until they get pwned up the face.

It turns out the rather obscure SSL flaw can be used to take over user accounts from websites that use API’s and especially those utilizing 3rd party clients (Twitter being the biggest but a lot of people are accessing Facebook now using clients too).

A Turkish grad student has devised a serious, real-world attack on Twitter that targeted a recently discovered vulnerability in the secure sockets layer protocol.

The exploit by Anil Kurmus is significant because it successfully targeted the so-called SSL renegotiation bug to steal Twitter login credentials that passed through encrypted data streams. When the flaw surfaced last week, many researchers dismissed it as an esoteric curiosity with little practical effect.

For one thing, the critics said, the protocol bug was hard to exploit. And for another, they said, even when it could be targeted, it achieved extremely limited results. The skepticism was understandable: While attackers could inject a small amount of text at the beginning of an authenticated SSL session, they were unable to read encrypted data that flowed between the two parties

So even though the fella couldn’t decrypt or read the data in the session, he could manipulate it in such a way that it spat out the goodies using the Twitter API.

It’s a very neat attack if you ask me, especially if you executed it via DM (Direct Message) it’s pretty unlikely anyone would notice their account had been ‘hacked’.

Perhaps this is how the bad guys have been doing it for a while because I do see an awful lot of hijacked accounts on Twitter and the owners have no idea why (they hadn’t logged in to any dodgy sites with OAuth or their Twitter credentials).

Despite those limitations, Kurmus was able to exploit the bug to steal Twitter usernames and passwords as they passed between client applications and Twitter’s servers, even though they were encrypted. He did it by injecting text that instructed Twitter’s application protocol interface to dump the contents of the web request into a Twitter message after they had been decrypted.

“My point is I think that it’s not so hard to make it work,” said Kurmus, who lives in Zurich and recently completed his masters thesis at the Eurecom Institute. “Maybe some other people did the same thing and did not make it public, so this is why I think it’s important that people would take this bug more seriously.”

Twitter proved an ideal platform to carry out the attack for several reasons. First, every request sent over the microblogging site includes the account holder’s username and password. Second, the site’s API made it easy to post the contents of the intercepted data stream into a message that an attacker could then retrieve.

Twitter has apparently plugged the hole from their side, but as the flaw in SSL itself it seems only one vendor is near to issuing a patch (OpenSSL).

If you extrapolate a little though, this attack could work on anything with a POST/GET interface on the web running on SSL – like Gmail for example.

I hope companies get to patching and plug this hole as it can be carried out all too quietly and wreak a whole lot of havoc!

Source: The Register

It only effects iPhone users that have jailbroken their phone and have the SSH software installed with a default password of alpine.

Thankfully it’s not particularly malicious unless you are allergic to Rick Astley.

iPhone owners in Australia awoke this weekend to find their devices targeted by self-replicating attacks that display an image of 1980s heart throb Rick Astley that’s not easily removed. The attacks, which researchers say are the world’s first iPhone worm in the wild, target jailbroken iPhones that have SSH software installed and keep Apple’s default root password of “alpine.” In addition to showing a well-coiffed picture of Astley, the new wallpaper displays the message “ikee is never going to give you up,” a play on Astley’s saccharine addled 1987 hit “Never Gonna Give You Up.”

Tricking victims in to inadvertently playing the song has become a popular prank known as Rickrolling. A review of some of the source code, shows that the malware, once installed, searches the mobile phone network for other vulnerable iPhones and when it finds one, copies itself to them using the the default password and SSH, a Unix application also known as secure shell. People posting to this thread on Australian discussion forum Whirlpool first reported being hit on Friday.

A new twist on the rickrolling phenomena at least, and of course the good thing for the rest of the World is that the infection seems to be fairly localized.

To me it’s more of a PoC (Proof of Concept) than anything else, but it is a neat piece of programming and shows what some malicious minds could put together if they wanted to target iPhones.

From the authors perspective he just wants to let people know that if they are gonna mess with their iPhone they better secure their shit.

The attack is a wakeup call for anyone who takes the time to jailbreak an iPhone. While the hack greatly expands the capabilities of the Apple smartphone, it can also make it more vulnerable. Programs such as OpenSSH, which can only be installed after iPhones have undergone the procedure, can be extremely useful, but if owners haven’t bothered to change their root password, the programs also represent a gaping hole waiting to be exploited.

Indeed, a hacker going by the moniker ikee and claiming to be responsible for the worm said here that he wrote the program to bring awareness to the widely followed practice of failing to change the iPhone’s password.

“I was quite amazed by the number of people who didn’t RTFM and change their default passwords,” the unidentified worm writer said. “I admit I probably pissed of [sic] a few people, but it was all in good fun (well ok for me anyway).”

Ikee said the worm disables the SSH daemon so it can’t be targeted further.

And in the true hacker spirit, the worm disables SSH so it can’t get infected again or hacked by anyone else.

It doesn’t takes skills to own the box, it takes skills to stay on the box

Source: The Register

RATS scanning tool provides a security analyst with a list of potential trouble spots on which to focus, along with describing the problem, and potentially suggest remedies. It also provides a relative assessment of the potential severity of each problem, to better help an auditor prioritize. This tool also performs some basic analysis to try to rule out conditions that are obviously not problems.

As its name implies, the tool performs only a rough analysis of source code. It will not find every error and will also find things that are not errors. Manual inspection of your code is still necessary, but greatly aided with this tool.

Requirements

RATS requires expat to be installed in order to build and run. Expat is often installed in /usr/local/lib and /usr/local/include. On some systems, you will need to specify –with-expat-lib and –with-expat-include options to configure so that it can find your installation of the library and header. Expat can be found here.

You can download RATS here:

Source Code: rats-2.3.tar.gz
Windows Binary: rats-2.3-win32.zip

Or read more here.

Goals

1. Identify the prevalence and probability of different vulnerability classes.
2. Compare testing methodologies against what types of vulnerabilities they are likely to identify.

The statistics was compiled from web application security assessment projects which were made by the following companies in 2008 (in alphabetic order):

• Blueinfy
• Cenzic with Hailstorm
• DNS with WebInspect
• Encription Limited
• HP Application Security Center with WebInspect
• Positive Technologies with MaxPatrol
• Veracode with Veracode Security Review
• WhiteHat Security with WhiteHat Sentinel

The statistics includes data about 12186 sites with 97554 detected vulnerabilities. The report contains Web application vulnerability statistics which was collected during penetration testing, security audits and other activities made by companies which were members of WASC in 2008. The statistics includes data about 12186 sites with 97554 detected vulnerabilities.

You can find the full study here:

Web Application Security Statistics

It’s a fair move by Mozilla though as the add-on can cause security vulnerabilities in Firefox outside of their control. They can’t fix the software, so the best thing they can do to ensure user safety is to block it.

Compounded with the fact it’s extremely hard for users to remove the add-on themselves the block is a good idea.

Mozilla late Friday blocked the Microsoft-made software that had put Firefox users at risk from attack.

The two-part Microsoft component — an add-on dubbed “.NET Framework Assistant” and a plug-in named “Windows Presentation Foundation” — have been blocked by Mozilla as a precautionary measure, said Mike Shaver, the company’s head of engineering.

“Because of the difficulties some users have had entirely removing the add-on, and because of the severity of the risk it represents if not disabled, we contacted Microsoft today to indicate that we were looking to disable the extension and plug-in for all users via our blocklisting mechanism,” Shaver said in an announcement posted Friday night to the company’s security blog .

The annoying thing is these add-ons are installed in Firefox without any kind of prompt or permission given by the user.

Microsoft pushed them out with the .NET Framework 3.5 Service Pack 1 (SP1) update in February this year, so our browsers have been vulnerable since then.

The software was almost impossible to remove without some registry hacking, Microsoft did remedy this later – but still how many people would know?

Mozilla maintains an add-on/plug-in blocking list that automatically bars risky software from being used by Firefox. The open-source company first used the blocker in 2007. Mozilla has used the tool only nine times, including Friday’s blocking of the Microsoft add-on and plug-in. In May 2008, for example, Mozilla added a Vietnamese language pack for Firefox to the blocking list when the pack was found to contain a worm.

According to Shaver, Microsoft gave Mozilla the go-ahead to block the .Net Framework Assistant and the Windows Presentation Foundation.

Last week, Microsoft’s security team acknowledged that its software — which had been silently installed in Firefox as far back as February 2009 — contained a critical vulnerability that could be used by hackers to hijack Windows PCs. The same vulnerability also affected all versions of Internet Explorer (IE), including the newest version, IE8.

Thankfully Firefox has the blocklist functionality and they have been aggressively moving towards ensuring 3rd party additions are also secure and don’t comprise the integrity of the platform.

Last month they warned users with out of date Flash plugins to update.

Firefox 3.6 will be even more aggressive in this aspect warning users when they visit a site that relies on one or more outdated add-ons.

Source: Network World

The following links provide more information about the Naptha denial-of-service vulnerabilities:

• The original BindView advisory is archived here.
• The advisory that CERT/CC published for the Naptha vulnerabilities is here.

The Tool

To study and show the Naptha vulnerabilities, Bob Keyes wrote the Naptha tool. The tool was written in C and used libpcap to read packets from the network and libdnet to craft packets.

The Naptha tool actually consists of two programs: a program called synsend whose only function is to send TCP SYN packets to the target system, and a program called srvr whose function is to respond to specific traffic received from the target system with TCP packets with specific TCP flags set. Both what traffic to respond to and how to respond to it are specified by the user via command-line arguments.

You can download Naptha here:

naptha-1.1.tgz

Or read more here.

The exploit isn’t 100% reliable but it’s still fairly significant in my eyes as it is a critical vulnerability and can be used for code execution.

Vista isn’t the most popular OS still so perhaps Microsoft don’t the threat being that wide as the protocol this exploit focuses on (SMB 2) was only introducted in Vista.

A security researcher has downplayed the significance of publicly released attack code exploiting a critical vulnerability in newer versions of Windows, saying it isn’t reliable enough to force Microsoft to issue an emergency patch.

The exploit, which on Monday was folded into the open-source Metasploit penetration testing kit, is at best successful only 50 percent of the time, said Dave Aitel, CTO of security firm Immunity. Given the burden of releasing out-of-schedule patches, Microsoft is unlikely to do so in this case.

“To move something like Microsoft you’ve got to have something major and this isn’t quite it,” Aitel, whose company released its own attack code two weeks ago. “It’s going to be a lot of work to take the exploit where it is to something that works enough that they will do that.”

It seems like the exploit is more reliable with Windows on VMware, but honestly how commonly do you see that? With a real native Windows installation they are only seeing a 10% success rate.

Which really isn’t that serious is it?

Apparently Immunity have made it much more reliable, but they have poured a ton of resources into it.

The vulnerability, which surfaced three weeks ago, resides in file-sharing technology called SMB2, short for server message block version 2, which was first added to Windows Vista and later made its way into newer versions of the operating system. While the Metasploit exploit is sophisticated, it is frequently thwarted by a security measure known as ASLR. Short for address space layout randomization, it picks a different memory location to load system components each time the OS is started.

Without being able to predict where required code will be located, the Metasploit attack isn’t reliable enough to prompt Microsoft to take the drastic step of releasing a patch outside of the regularly scheduled update cycle. The software giant adopted the patch routine to make life easier on system administrators by allowing them to plan and test updates before installing them on huge numbers of business critical machines.

The Metasploit exploit in many cases is able to get around ASLR by targeting memory locations that are predictable when Windows is running on VMware. But when the exploit targets the OS running directly on a computer, the success rate can be as low as 10 percent.

Microsoft will patch this eventually, but I doubt it’ll be soon and they definitely won’t be rushing an out-of-schedule patch out just for this vulnerability.

The question is can the bad guys fashion this into a reliable exploit and get some major ownage going on?

Source: The Register

It’s a pretty serious flaw this time with root escalation, thankfully it’s only a local exploit though and not remotely exploitable.

Although a user could get user access on the system through an exploit in a web facing application, and use some kind of PHP/Python web shell to exploit and get root.

A security researcher has uncovered a security bug in the FreeBSD operating system that allows users with limited privileges to take full control of underlying systems.

The bug in FreeBSD’s kqueue notification interface makes it trivial for those with local access to a vulnerable system to gain full root privileges, Przemyslaw Frasunek, an independent security consultant in Poland, told The Register. It affects versions 6.0 through 6.4 of the operating system, the last two versions of which enjoy wide use and continue to be supported by the FreeBSD Foundation.

Versions 7.1 and and beyond are not vulnerable.

With a lot of people still using FreeBSD 6.3 and 6.4, amongst the FreeBSD community I’d say this could be quite a widespread problem.

A lot of BSD boxes are used for web hosting too, so I’d imagine a lot have SSH access enabled giving people local access and the capability of executing this exploit.

Those exploiting the bug must first have local access to a vulnerable system, either as a legitimate user or by exploiting some other flaw (say, a vulnerable PHP script) that gives an attacker a toe-hold in to the targeted system. Frasunek said the vulnerability is trivial to exploit, as a video he posted here suggests.

The bug is the result of a race condition in the FreeBSD kqueue that leads to a NULL pointer dereference in kernel mode. Attackers can cause vulnerable systems to run malware by putting the code in a memory page mapped to address 0×0.

Frasunek said he notified FreeBSD officials on August 29 and has yet to get a response. Robert Watson, a FreeBSD Core Team member, told El Reg that it appeared the email had gotten “lost in the slew” and he expected an advisory to be issued soon.

If you’re using the latest production release (at this time 7.2) you aren’t vulnerable to this problem, I hope to see them backport the patch to the previous versions as they still have a sizable following.

You should see an advisory hitting the mailing lists soon, and I’d expect it to be fixed pretty quickly too.

Beware if you are using FreeBSD and have users with local access you don’t trust.

Source: The Register

4f’s purpose is to find vulnerabilities in code that parses file formats including configuration files.

4f uses specialized modules for fuzzing code that interprets file formats. Several modules are included and more can be written to follow other file formats.

A module system is in place for fuzzing any file format you like as long as you know its specification

Custom debugger gathers crucial debugging information on crash, logs it, then continues fuzzing.

Usage

USAGE DETAILS

USAGE:   ./4f <-T /usr/bin/target> <-M #> [-N fuzz.conf]
         [-A ARGS] [-R /output] [-L log.txt] [-C] [-D]

INFO:    [-O Fuzzing Oracle] [-S Modules Available]

You can download 4f here:

4f.tar.gz

Or read more here.