The idea behind this PCI Card is once it is plugged into a computer the whole traffic can be inspected, analyzed and, of course, modified when required in a transparent way to the user.

All the above should be achieved producing a network pci card so that a regular IT guy wouldn't be able to notice a diference between M-ETH and other NICs.

Another required feature for M-ETH is it must be platform-independant, I don't want it to be tied to any Operating System.

After some days of research and advice from hardware guys, the final design of M-ETH came up and featured the following main components:

• National's DP83816
• Microchip's ENC28J60
• AVR32UC3A
• An RJ-45 port

Some with some basic hardware skills will notice that building such a card would require several Magnetics and that could easly spot something "wrong" in the card. To avoid this, "Transformerless connection" between ethernet chips was included.

A simplified architectural view of the schematics for M-ETH can be found below.

The firmware running on the AVR32 reads packets coming out from victim's computer via the SPI Driver controlling the ENC28J60, so for the victims' Operating system the whole networking stack ends in the PCI Ethernet Chip, so they are not able to detect anything going wrong outside it.

The PoC presented at LaCon'09 showed how a TCP Stream originated in the victim's computer is succesfully modified without the victim being able to notice it.

And finally this is one of the prototypes developed as a PoC, this card does not have the AVR32 soldered as it was easier to develop the whole firmware running it dettached with an wired SPI connection going to the ENC28J60.

The next video (Spanish, but subtitles coming soon) shows the first version of M-ETH, it just reads packets from the "Victim's computer", an Mini-ITX in the video, and send them to the outside LAN. As soon as I have enough free time I want to record a new one showing a TCP stream modification, for now watch this video

You may also want to have a look at the slides I used at LaCon'09, I have translated them to English

If you have any further question or interested in a sample do not hesitate to drop an email, gabriel at wintercore dot com

Let's start defining two well-known metrics MTTR and MTBF but within our context:

• MTTR (Mean Time To Repear): Specify the average time a company takes to fix a vulnerability.
• MTBF (Mean Time Between Failures): We are going to use this metric as the average time between to reported vulnerabilities.

Software Reliability can be calculated by the next formula:

to give prospective to the article we are named this value VFP (Vulnerability Free Probability) which shows how likely is NOT an application to have a bug during its lifetime.

The complementary probablity VEP (Vulnerabilty Exposed Probablity). Application's probability of having a vulnerability during its lifetime.

Now it is time to apply these metrics and get some real measurements. Thanks to Hispasec and its paper about Vendor's vulnerabilities this task is going to be easier for us, since they have already compiled all the bugs information.

We are going to apply this metrics to 5 applications Microsoft Explorer, SUN Java JRE, HP NodeManager, Apple Quicktime and Adobe Reader.

First we calculate the MTTR and MTBF for the above applications, as you can see in the spreadsheet.

The following figure shows the VFP or Software Reliability for the above applications.

As can be seen in the figure the reability of these products is far from good, in fact they are worst than I expected. Even a vulnerability free probability of 40% is too large for me.

Only Adobe Reader is above the 50% and QuickTime is only 1% of its lifetime free of vulnerabilities!

Apple's QuickTime users are exposed to at least one vulnerability the 99% of the time they use it.

These metrics should be taken more seriosly when choosing certain software for politicians and people which high risk of being attacked.

Part II:

Besides these metrics, we can retrieve some patterns from the data we first had. The next step is to see which is the trend in the response-time when fixing vulnerabilities.

Let's calculate the MTTR for each bug reported so we can plot a scattered bunch of points. Afterwards, we try to linearly fit this points so we can see the trend.

As can be seen in the figures shown above, Microsoft's Explorer and Sun's Java JRE have reduced their time to fix vulnerabilties since the first report date we have.

On the other side, Quicktime seems to keep in its average time. While Adobe Reader looks like its response time is getting worst, the linear approximation is strongly biased by the first measurement, so if we remove this outlier the linear fit is similar to QuickTime's

Do not hesitate to contact us if you need further information

I have decided to put for sell, to trusted sources only, a novel technique that takes advantage of a weakness in Microsoft technology that allows remote attackers to gain knowledge of sensitive information like applications, hotfixes,service packs installed on PCs running Windows 2000 or later . The only scenario you need is to trick the victim into visiting a webpage under your control.

Note that...

FAQ

Who can buy the happy pack #1?

If you cannot demonstrate you are working for a company or institution, better you don't waste your time trying it.

How much does it cost?

$800 dollars - €600 euros.

What does the happy pack #1 include ?

Fully comprehensive technical report and exploit code. Obviously, you can request further info if, once purchased, you have doubts on any matter...

Mmm, it seems interesting...Whom should I talk to?

contact [at] wintercore (dot) com

More than five months ago we notified Netopia's customer support (http://blog.wintercore.com/2008/04/26/things-that-shouldnt-be-there/), after discovering a hardcoded user/password pair within SALT.dll.

---------------
v 8.6.5.1373
Dll: SALT.dll
Address: 0x604b83D4
PE section: .rdata
user: xa7z8
pass: e74sa9
url: findme.netopia.com/_REMOVE_THIS_findme/
---------------

By using this information it was possible to access, in real-time, to hundreds of users' records containing their IP, email, software version and information related to the license.

We have received no reply since then. 5 months after, we have found out what we would say an "obvious" patch: "if the problem was the user/password, well, let's remove it!. Fixed.".
Really hilarious.

Now, everyone can access those records without having valid credentials.

Taking into account that there are remote exploits available for that software, that everyone can grab your IP and software version, and that there are emails from government, military and high-profile corporate staff, better you disable that feature.

I was planning to write about audio captchas may pose a future attack vector for spammers, but after googling a couple of minutes I stumbled upon the following offer: http://www.getafreelancer.com/projects/C-C-Audio-Services/Recognize-Voice-Captcha-Google.html

Unfortunately the future is right now.

Audio captchas are the alternative to image captchas for visual impaired persons. Anyway, both captchas must share an unconditional point:

• A captcha should be easily solved by humans by taking into account the human nature only, not the level of culture. We have to demonstrate we are humans, not our IC.

Despite of this fact, 99% of the captchas are still today presenting alphanumeric challenges which, although by using this approach we make sure that 99% of people having access to a computer will know how to solve those challenges, are more related with culture rather than with the human being background.

Microsoft Research thought about that fact, I guess, and then came up with the Asirra captcha. Have you heard of someone who has not seen a cat or a dog? Probably not, but have you heard of someone who is illiterate? Probably, yes. That's the difference, as human beings we may learn a lot of things from other humans but what is inherent to our human being condition is the capability to "automatically" interact with our enviroment. It may be difficult to understand how to solve a differential equation but if you see a cat, you see cat, you know that is a cat. You have been seeing cats since you were a kid, in your friend's house, in the park, in the TV, in the petshop... Your brain is not working too much to bring you that information.

So the question is, how to apply this concept to audio Captchas? Well, the same concept. Do you remember when you saw cats? you also heard them, right? so could you distinguish a cat from a dog just hearing their characteristical "sounds"? Obviously, you do.

99.9% of peope can likely distinguish a dog barking from a cat meowing. Now, think for a while as you were a computer( make that effort please ): how to distinguish a cat from a dog ? really difficult. If you let me make the comparison, this sort of captchas should be something similar to metamorphic viruses.

To make the issue harder to solve, now put that dog barking in the middle of a crowded and noisy street, even then, you likely know there is a dog messing around. However, let's imagine a computer filtering n previously unknown features looking for a barely predictable vector holding the set of features that represent a dog barking or whatever, since the automated agent cannot predict what will be the challenge proposed by the captcha, whilst nowadays a bot knows beforehand it faces an alphanumeric question. Computationally this is a really complex problem...First off, the automated agent should syntactically analyze the question and then proceed to mine the audio captcha relying on its own "world's sounds" database. Totally unreliable for automated agents, at least for non-government-supported ones

• A baby crying.
• A thunderstorm
• A baby crying in the middle of a thunderstorm
• A dog barking while a baby is crying in the middle of a thunderstorm.
• ...

But, what about the question? I mean, for an audio captcha playing a baby crying what should be the question... Whatever you want. If you insert into a database all the sounds of babies crying along their proper tags, you can make up any question you want, either generic or more specific

i.e : baby_crying_3.wav -> "baby", "crying".

Question 1: What does represent this sound?

Answer: Mmm, eerrr I think it's a baby crying !!

Question 2: What does the baby ( dog, cat, airplane...) do?

Answer: Mmm, eerrr I think the baby is crying !!

Or even

girl_alphanumeric_sequence_5_5_2_4_5.wav -> "girl", "five","five","two","four","five","numbers".

Question 3: What does represent this sound?

Answer: Mmm, eerrr I think it's a girl saying numbers !!

Note the second question exposes too much information to the "attacker", being suitable for a purely syntantic attack since a baby (dog, cat...) cannot do a lot of things...

You should use syntatic recognition for parsing the answers. If you don't have the means, regexps, a dictionary and the levenshtein distance, for dealing with spelling errors, should work like a charm.

You can distort, speed up, slow down, cut, expand... these captchas, making the issue harder to solve.

Without any doubt, the "natural captchas" are an interesting field for researchers.

Ruben Santamarta,

R&D/Reverse Engineer.

Anyway the fact is that sometimes either by error or having obscure intentions, there are "things" that should not be there. Nowadays, these issues pose a real threat.

Not long time ago, I was reversing a well-known software widely extended within the enterprise enviroment when I came across one of those "things": a hardcoded user/password pair that grants access in real-time to thousands of high profile emails, their associated IPs and software version, among other things.

Definitely, it's not a good idea to share the kingdom's secrets with any guy with a disassembler.

This is a valuable information that can be used in targeted attacks, phishing or even to exploit a flaw in the software. Anyway, we immediately contacted to the vendor so this information leak should be fixed soon.

Have a nice weekend!

Ruben Santamarta.

R&D/Reverse Engineer

First off, it is worth noting the “cat&dog” Asirra captcha from Microsoft Research, that’s a really good captcha, has kept the success rate of those who tried to break it (computer vision gurus) below of 60%. Why? I think the problem with most of the captchas is that are using a complex solution to show so simple challenges: obfuscated, deformed and distorted image to represent short alphanumeric sequences. On the other hand we have the “cat&dog” style Captchas that implement a simple solution to show a really complex challenge for automated agents: Are you seeing cat or dogs in this perfectly clean picture? A question too hard to answer if you are not human.

The Gmail's Audio Captcha suffers a similar error. It is a wav file embedded within the webpage, once loaded it plays limited series of numbers . Twice. Btw, I don’t understand why that alphanumeric obsession...Anyway, let's begin. In this post I am going to show how that captcha can be broken just by using fourier analysis.

You should play the captcha before continuing Look for this image within the signup page.

The first obvious error is the use of fixed patterns that clearly identify where the sequence begins and where it ends.

We can listen to the numbers, in background there are distorted voices.Taking into account that human beings are visual entities ( this is the reason because everybody can spot Wally in a crowded place but only trained individuals could distinguish a distorted tone while an orchestra is playing) my question was: “If you are still capable of distinguishing easily the numbers played in the captcha, why an automated agent couldn’t do so?”

So let’s try to find out the answer by taking a look at the waveform of a random Gmail's audio captcha

You can immediately recognize the first “beeps” that announce the initial sequence and at the half of image, which is also the half of the captcha more or less, the voice of the girl saying “once again”. Moreoever,you see the signal of every number played has its particular “shape”.

Well, that’s all. You have already broken the Gmail audio captcha. Now, having the concept in your mind, all you need to do is write down that idea into something more tangible and less volatile.

Jean Baptiste Fourier discovered, more than a hundred years before iPhone, that every waveform could be generated by adding up sine waves. But wait, he also found that every waveform could be broken down into those sine waves as well. So all we have is a bunch of sine waves that make up our signal. Let’s imagine a signal along the following axis

Viewing the graph along the time axis we would be in the time domain, on the other hand, if we get as reference the frequency axis we are talking about the frequency domain, what’s the difference? A lot, but the most obvious is that in the time domain you are choosing a “local” reference at every moment, on the other hand viewing the signal from the frequency domain, we get a “global” perspective of the signal. We represent every sine wave that makes up the signal as a vertical line as follows:

Those lines (components) uniquely identify our signal. In pattern recognition if you manage to extract good features from whatever you are mining, you’ll get the 50% of the work already done. In this case what we are mining is a wav file which is merely a vector of N samples representing a signal at t time. The higher sample rate, the more accuracy.

Ok, so the next step is to project that vector into the frequency domain by using the Discrete Fourier Transformation through the Fast Fourier Transformation algorithm.

However, there is something we have to note before proceeding, we are calculating the FFT on N samples that represent a sine wave over a certain time, this wave is not strictly required to be periodic in that interval so we need a method to “readjust” our samples in order to minimize the impact that a non-periodic sampled wave may produce, this is a well-known problem called “leakage”. In order to solve this issue we have to apply a Window function on the samples. Therefore, allowing the FFT to operate only on a certain selected interval we'll achieve more realistic results. The window function applied is one of the most common: Hanning (watch out, not hamming) .

Well, once the signal is in the frequency domain the next goal is to calculate its power spectral density since that is a good standpoint for identifying the signal as we’ll see later. The last step in this block is to adjust the scale. The human ear is ruled by the logarithmic scale so we wouldn’t be less than those “humans” or whatever…jokes aside we are modifying the amplitude scale since this is the best way to get a proper view of the small signals whilst the large ones are still represented as deserve

Spectrum sample of a random captcha.

Another view of signal’s Power differences in the time domain. The spectrogram.

As you can see in the Spectrum image, there are a a bunch of peaks and valleys. These peaks are what we are going to use as features for characterizing our sampled signals. Therefore the next step is to find out those peaks. In order to discover the local maximums we calculate the second derivative of a cubic equation specially chosen to represent the spectrum. Et voilá, those peaks can be used as features for any classification algorithm you desire. The method proposed is simple, throwing away HMMs, SVMs, ANNs et cetera… what we do is a “peak matching” algorithm along the entire input signal,firstly windowing the input captcha, at every iteration, to the FFT size of the signal of the number we are checking. Then calculating both spectrums and finally comparing the peaks obtained. By using this technique the percentage of success easily raises to 90% so imagine what would you do by implementing the proper classification algorithm.

Download a video showing a live demo of the tool developed to break the audio captcha. This tool is not going to be released for obvious reasons.

Under my point of view the main problems present in this audio captcha are the following:

• Slightly distorted signal over the frequency domain.
• Signals have an invariant duration along the time axis.
• Same voice.
• Fixed patterns at the init, middle and end of the captcha.
• Numeric sequence as proposed challenge. (maybe the most important one)

These weak features make the Gmail's Audio Catpcha highly suitable for automated attacks. Moreover there are several audio captchas out there, i.e facebook, that suffer the same inherited design errors as well.

Please note that some important steps have been deliberately omitted in order to avoid this post becomes an step-by-step tutorial for spammers.

Rubén Santamarta,

R&D/Reverse Engineer

]]> http://blog.wintercore.com/2008/03/05/breaking-gmails-audio-captcha/feed/ 0