Slashdot Mirror

You've got the wrong impression of BadUSB as impersonating a HID certainly isn't required. USB is fundamentally insecure in a number of ways...

https://www.blackhat.com/prese...

http://media.blackhat.com/bh-d...

https://srlabs.de/blog/wp-cont...

When the USB drivers themselves can be attacked with malformed protocol data there is a fairly direct channel to gaining access to the whole system. Also a USB drive controller can make itself look like an internal drive, meaning that DMA (yes, USB supports DMA) restrictions get lifted and then you have a hole in security similar to Firewire.

As for filesystem attacks being 'rare', that's only because other attacks (esp. remote) have offered so much opportunity to attackers. If an attacker wants an offline mode of exploitation then filesystems -- being complex data formats themselves -- then filesystems are a wide-open field of opportunity.

Is there actually a push for contactless EMV as the article surmises? I assumed a lot of people had reservations about the security of these implementations.

I'm sure this presentation next month won't help that perception:
https://www.blackhat.com/asia-15/briefings.html#relaying-emv-contactless-transactions-using-off-the-shelf-android-devices

Presumably Jay Radcliffe's research is old news to you, correct? If not, I'd take a quick look-see...

This will simply open up new attack surfaces on unsuspecting vehicles.

The news isn't about the availability of a JB; it's about the presentation at Black Hat. The JB wasn't "just now" discovered or created. Further, in the presentation, the Georgia Tech (GT) team claimed that Pangu stole their methodology (and added malware, FWIW). It's unclear whether the GT researchers will release an implementation of their methodology at all.

I can't get the linked PDF to load
This probably isn't the same thing, but it explains what they're trying to do and why
https://media.blackhat.com/bh-us-11/Kennedy/BH_US_11_KennedyMuttik_IEEE_Slides.pdf

Hi, I'm a Bluetooth Security researcher. My primary focus is on BLE for which I built a highly robust sniffer on the Ubertooth platform. I have experience in other aspects of Bluetooth.

TL;DR: Classic Bluetooth is very secure, BLE is secure under some circumstances. Even if you leave your Bluetooth on in discoverable mode, there isn't much an attacker can do to harm you barring bugs in your Bluetooth stack.

Bluetooth is a well-designed protocol stack that takes security seriously in its design. Implementation quality (and bugs therein) varies from stack to stack. It's always a good idea to disable Bluetooth if you aren't using it, as is the case with any other remotely accessible feature.

Classic Bluetooth has used Secure Simple Pairing (SSP) since 2.1 in 2007. This pairing mechanism is based on ECDH to provide perfect forward secrecy and is highly secure. There was one weakness discovered in the numeric entry pin mode in 2008 by Andrew Lindell. This mode is not commonly used in older devices and more recent devices do not implement it. It's effectively impossible for an attacker to sniff any data sent over Bluetooth with SSP.

BLE has major weaknesses in its pairing protocol that I spoke about at BlackHat USA 2013 and other venues. For the most recent video see my presentation at USENIX WOOT 13.

In BLE, a passive eavesdropper who is present during pairing can recover the secret key used to encrypt all communications. This effectively makes the security worthless. However, if the attacker is not present during pairing then the encryption is very effective. It uses AES-CCM and doesn't have any major flaws in the design. AES-CCM is used in WPA2-AES; it's well-established and has no major shortcomings.

Finally, some Bluetooth stack implementations have bugs. I've found remote bugs in one major vendor's stack.

Hi, I'm a Bluetooth Security researcher. My primary focus is on BLE for which I built a highly robust sniffer on the Ubertooth platform. I have experience in other aspects of Bluetooth.

TL;DR: Classic Bluetooth is very secure, BLE is secure under some circumstances. Even if you leave your Bluetooth on in discoverable mode, there isn't much an attacker can do to harm you barring bugs in your Bluetooth stack.

Bluetooth is a well-designed protocol stack that takes security seriously in its design. Implementation quality (and bugs therein) varies from stack to stack. It's always a good idea to disable Bluetooth if you aren't using it, as is the case with any other remotely accessible feature.

Classic Bluetooth has used Secure Simple Pairing (SSP) since 2.1 in 2007. This pairing mechanism is based on ECDH to provide perfect forward secrecy and is highly secure. There was one weakness discovered in the numeric entry pin mode in 2008 by Andrew Lindell. This mode is not commonly used in older devices and more recent devices do not implement it. It's effectively impossible for an attacker to sniff any data sent over Bluetooth with SSP.

BLE has major weaknesses in its pairing protocol that I spoke about at BlackHat USA 2013 and other venues. For the most recent video see my presentation at USENIX WOOT 13.

In BLE, a passive eavesdropper who is present during pairing can recover the secret key used to encrypt all communications. This effectively makes the security worthless. However, if the attacker is not present during pairing then the encryption is very effective. It uses AES-CCM and doesn't have any major flaws in the design. AES-CCM is used in WPA2-AES; it's well-established and has no major shortcomings.

Finally, some Bluetooth stack implementations have bugs. I've found remote bugs in one major vendor's stack.

Firmware attacks can be sophisticated indeed

You said it. https://www.blackhat.com/html/bh-us-12/bh-us-12-archives.html#Brossard

https://www.blackhat.com/html/bh-us-12/bh-us-12-archives.html#Brossard

He thought the idea that he debuted at BlackHat was somehow new or revolutionary. I think the only thing he may have done differently than this advertising agency is to have each node connect to the other nodes using Tor.

I've studied the entire TPM technical specification. I understand it in minute detail.

I don't doubt you've looked at it. But clearly you've looked at it from the perspective of how you think it impinges on your liberty rather than from the perspective of a security engineer trying to achieve simple properties such as executing code that isn't manipulated by an attacker. That's fine, that's the perspective I expect most slashdotters to be coming at it from. But I'm pretty encouraged by how many people in this thread have pushed back against the normal FUD I expect to see here.

The TPM technical specification is quite explicit that the owner of the computer is FORBIDDEN to ever get his keys

Forbidden from getting them out of the TPM, not forbidden from using them in ways that allow for guaranteeing security properties.If you can just export the key from the TPM onto your normal OS, how would you ever know you were talking to a TPM instead of malware pretending to be a TPM? If you could just ask the TPM to sign something for you with the protected keys, why could the attacker not arbitrarily ask for forged data to be signed?

The owner is forbidden to have his Private Endorsement Key because this key is used to secure the Remote Attestation process against the owner. Remote Attestation is where the chip securely (secure against the owner) securely tracks your hardware and the software you run, and sends that spy-report out to other computers over the internet. If the owner had his Private Endorsement key, these Attestation spy-reports wouldn't be secure against the owner.

An amazingly hyperbolic statement for someone who claims to have read the specs.
1) "The chip" tracks your hardware does it? You understand that the TPM is a completely passive chip waiting for people to come along and send it data, don't you?
2) Same point, again. If you export the EK into the OS, any malware anywhere can forge the attestation state, saying that the system is in a state it is not in. That could mean it's infected when it's not, so it gets reimaged by corporate IT, it can say it's not infected when it is, so the attacker has the run of the network.
3) Only a few large companies are actually using TPMs and remote attestation for things like trusted network connect (just NAC with a TPM-signed configuration), but in reality your FUD-drenched picture of the "spy-reports" (really? wow) being sent out gives the trusted computing folks too much credit. Since no one's using it at the OS level, most all attestation report data is just the BIOS collecting data about itself. And as people showed at BlackHat recently, vendors like Dell don't actually do a very good job of collecting relevant information, collecting just the bare minimum to make bitlocker work - https://media.blackhat.com/us-13/US-13-Butterworth-BIOS-Security-Slides.pdf

TPM is just a secure hardware keystore.

It's more than that, but an important part of it is that it's a "secure hardware keystore". Specifically, it is designed to be SECURE AGAINST THE OWNER. The Trusted Platform Module Technical Specification explicitly refers to the owner of the chip as an attack-threat which the chip MUST be secure against.

Citation needed ;) I'm sure you're misinterpreting some physical tamper-resistence line. I agree with that person, it's really just a keystore (and a really really slow RC4/SHA1 implementation).

The "Master Keys" are held by the Trusted Computing Group. The crucial individual keys are locked inside the Trusted Computing chips, secured against the owners.

.

It's great that you've read the specs and all, and somehow latched on to the imaginary phrase "secure against the own

There was some interesting research presented at Blackhat that pointed out the problems of using the TPM as a root of trust in your platform: https://media.blackhat.com/us-13/US-13-Butterworth-BIOS-Security-Slides.pdf The essence of the research is that the TPM is not adequate as a root of trust in the platform because the code that drives the TPM/does the system measurements resides on a mutable EEPROM (the bios flash chip). Therefore any attacker that can gain access to the bios flash chip via an exploit (the researchers presented one) or via an unlocked flash chip (see Yuriy Bulygin's related work) can forge the TPM measurements that serve as the root of trust in your system. This is important because software like Bitlocker uses these TPM measurement values to determine whether or not to decrypt your harddrive...

The whole thing is unsubstantiated FUD. I base my judgment on the slides at
https://media.blackhat.com/us-13/us-13-Stamos-The-Factoring-Dead.pdf

The whole argument boils down to:
a) there has recently been huge progress [*] in solving the Discrete Log Problem over fields of small characteristic;
b) progress in solving the DLP have historically implied progress in factorization, and vice versa;
c) factorization breaks RSA, and solving the DLP breaks DSA;
d) thus RSA and DSA are dead, move to ECDSA.

The fallacy of it is that in b) and c), the DLP is exclusively over fields of huge characteristics (thousands of bits), making the algorithms in a) powerless. The slides do not hint at the faintest research lead towards moving to huge characteristics. Best argument is that "renewed interest could result in further improvements".

One the positive side, the author is honest: "I’m not a mathematician, I just play one on stage".

    François Grieu

[*] See e.g. this recent paper and its references
Razvan Barbulescu, Pierrick Gaudry, Antoine Joux, Emmanuel Thomé: A quasi-polynomial algorithm for discrete logarithm in finite fields of small characteristic
http://hal.inria.fr/docs/00/83/54/46/PDF/quasi.pdf

Take a look at this year's Black Hat presentations. These are just the ones on vulnerabilities in embedded systems.

• Compromising Industrial Facilities From 40 Miles Away
• Energy Fraud and Orchestrated Blackouts: Issues with Wireless Metering Protocols (wM-Bus)
• Exploiting Network Surveillance Cameras Like a Hollywood Hacker
• Fact and Fiction: Defending your Medical Devices
• Hacking, Surveilling, and Deceiving victims on Smart TV
• Home Invasion v2.0 - Attacking Network-Controlled Hardware
• Honey, I'm home!! - Hacking Z-Wave Home Automation Systems
• Implantable Medical Devices: Hacking Humans
• Let's get physical: Breaking home security systems and bypassing buildings controls
• Out of Control: Demonstrating SCADA device exploitation
• The SCADA That Didn't Cry Wolf- Who's Really Attacking Your ICS Devices- Part Deux!

You'd be surprised. I once caught someone embezzling from the company we worked over discussing it via IM with their accomplice, full confession via IM, ON THEIR WORK COMPUTER. Pawned.

After a few years in corporate security it would not shock me in the slightest. People get sloppy.

Even professionals. See the Opsec talk summary here: https://www.blackhat.com/us-13/briefings.html#Cole

Min

Are there still security issues with having JS enabled?

Fresh from the summary of the upcoming BlackHat talk by Jeremiah Grossman, A Million Browser Botnet:

With a few lines of HTML5 and javascript code we’ll demonstrate just how you can easily commandeer browsers to perform DDoS attacks, participate in email spam campaigns, crack hashes and even help brute-force passwords. [...] no zero-days or malware is required. Oh, and there is no patch. The Web is supposed to work this way.

This article covers some of the technical issues and attack vectors still present in AutoPlay (of which autorun functionality is now a subset).
https://media.blackhat.com/bh-dc-11/Larimer/BlackHat_DC_2011_Larimer_Vulnerabiliters%20w-removeable%20storage-Slides.pdf

This was the subject of a talk given at Black Hat (or was it DEFCON?) in August out in 'Vegas. Why it's news now suddenly is a mystery to me. The guy did thoroughly hack the product to include reversing it's signature encryption (homebrew crypto?!) and figuring out that some features simply didn't work. However at the time of the talk he also told the audience that he had been working with the company and that they had changed some things and would be switching to standard crypto. I'd still agree the company comes across as slimy since some of their claims were pure crap (some signatures apparently obviously machine generated despite claims they didn't do that etc.) but now months later to post this like it's news? Really? Maybe he should have had this paper ready to roll right after the talk?

http://www.blackhat.com/html/bh-us-11/bh-us-11-briefings.html#Ormandy

You can you watch a video of the talk on YouTube - or read the slides at BlackHat.

Fairly interesting to see how buffer-overflows can occur in the most unlikely places.

Citation needed.

Here are a couple of places to look to get you started. This practice is generally disguised as "Lawful Intercept". The net effect is that any government agency can trap any data that they want to. If you look at the Google search, you will see Cisco configuration guides on how to set this feature up.

https://www.google.com/search?q=cisco+lawful+intercept
http://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-wp.pdf

Keep in mind, this is just the published part that we know. What other capabilities exist that aren't published? It would probably scare all of us.

The reason that the government (and everyone else) is so concerned about Huawei is because vendors here in the US already have the capabilities to capture whatever the government wants. Why would China be any different? The only difference is that Huawei isn't publishing configuration guides for their implementation...

(AC because I'm posting at work)

I wish I could use some of my mod points to mod parent up. "Using (or having insiders create) multiple 0-days for Stuxnet" vs. "Metasploit and proclaiming victory by playing a .mp3" show two completely different models of operating. There isn't anything like Defcon or Black Hat going on this week, is there? ;)

(DC because I'm posting from my C64 on battery power from Afghanistan)

no

    Ya, that had me going too.. I thought maybe they had shortened down SAAP (Software As A Product), or it was one of the billion Symantec products. Two links in from the story, it references this BlackHat PDF, which finally does say SAP AG.

    It's great to have short acronyms for stuff, but without any good context its worthless. It's like marketing people love their acronyms, so they can try to talk in military style alphabet soup. Well, at least the military alphabet soup makes perfect sense when it's in context.

    I worked at places where they had code named and acronymed everything. They weren't terribly consistent, and there was no reference document. There were also many duplicates. "Work on DC" could have been the servers near Washington DC; the datacenter (pick one, maybe two or three); or domain controller. It could also be an acronym for a client (two matched), or you could have misunderstood it for PC or TC, which were also used. The best was that they had several code names, all two words long, and the first word was the same for most of them. I just called them all [blah]things, and let someone else figure out what I was talking about. That was fine, since there were about a dozen words in use at the company that *all* translated to "thing". Almost everything could be translated to "fix the thing to make the thing work so the other thing works."

    I did everything I could not to recite this.

    Obviously the problem with the SAP thing is relatively important (more so to users of it), but without know it, the thing [SAP] has a security flat with the thing [SAP] router letting remote attackers access the thing [SAP].

I disagree. Here's why.

"Although I seriously doubt Symantec's 5 million number is right,...." I could see it. According to Gartner, "smartphone sales to end users reached 115 million units in the third quarter of 2011. The Android OS accounted for 52.5 percent of smartphone sales to end users in the third quarter of 2011 more than doubling its market share from the third quarter of 2010." Add in the Android phones sold prior to third quarter 2011 that are still in use.
Now we are talking about an under 10% successful infection. That doesn't grab headlines. Of course, an anti-virus vendor who happens to sell "end point protection" at $29 a year for their Pro version may have a financial incentive to make sure they are in news.

Phones are appliances, and trying to handle malware the same way we handle it on computers (which is to say, after the fact) is not going to work.

Smartphones are not appliances. Quit thinking of them as such. They are small, portable computers that meet most of the end user's needs. Hence the popularity. As their primary function is to make a phone call, perhaps the GUI does not fit into our typical "this is a computer" mindset. In the same way, VoIP phones and networks have been a target for years. For example, the Cisco 7940 has webserver built in. Again, a small computer.

Google needs to keep their market open. There's not the barriers to entry Apple has erected. I'll give you they do need to co-operate with the authorities.The key here is educating the user base. This in terms of tools (anti-virus software) as well as habits (don't go here on the web).

Links:

• Cisco Voip hacking from 2006 (?)
  http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Endler.pdf
  Gartner
  http://www.gartner.com/it/page.jsp?id=1848514

And as I live in the U.S., land of the free, the following disclaimer applies: The above material is presented strictly for educational purposes

Spook BackDoors In Cisco Routers (continued - revision 3)
- Older news, but still relevant!!
Please save this story and repost it everywhere
Especially in Security Discussion Forum Sites
- You should use OpenBSD or a hardened Linux distro
For a router, NOT these blackboxes offered with
proprietary hardware & firmware!

"More on Cisco Building Surveillance into Routers"
http://hardware.slashdot.org/story/03/04/22/1656215/more-on-cisco-building-surveillance-into-routers

PDF: http://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-wp.pdf

PDF2: http://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-slides.pdf

Is Apparent US Conspiracy with Cisco about Wiretapping?
By: emptywheel Monday June 6, 2011 2:52 pm
http://emptywheel.firedoglake.com/2011/06/06/it-is-simply-not-done-in-a-civilized-jurisdiction-that-is-bound-by-the-rule-of-law/

Canada has just discovered how much corporations own our legal system, how our legal system criminalizes whistleblowers, and our utter and total disdain for the rule of law.

At issue is the apparent conspiracy between Cisco and the US government to respond to an anti-trust lawsuit launched by Peter Alfred Adekeye, a former Cisco employee. He sued because of the way Cisco forced customers to buy a maintenance contract for things like bug fixes.

This lawsuit is about Ciscoâ(TM)s deliberate and continuing attempt to monopolize for itself (and its âoepartnersâ (Cisco-authorized resellers of Cisco equipment and services nationwide) with which it does not significantly compete) the service and maintenance of Cisco enterprise (Cisco networking equipment for all segments (e.g., internet service providers, government, academia, small, medium and large business, etc.) with the exception of home networking equipment) hardware, principally routers, switches and firewalls. Cisco possesses a market share of approximately 70% in the networking equipment industry.

[snip]

To protect its over $6 billion yearly stream of service and maintenance revenue, Cisco has cleverly and uniquely conditioned the provision of its software âoeupdatesâ on the customerâ(TM)s purchase of a hardware maintenance service agreement called âoeSMARTnet,â

[snip]

The effect of this leveraging of monopoly power and unlawful tie-in and/or bundling is to effectively preclude any non-Cisco affiliated Independent Service Organization (âoeISOâ) from competing for the business of servicing Cisco networking hardware, thus preserving for itself all but a pittance of that line of commerce which is separate and distinct from the âoeupdatesâ of its software.

In response, Cisco counter-sued, accusing Adekeye of illegally accessing Cisco services. And Cisco either lied persuasively or got DOJ to conspire in the intimidation campaign, because DOJ then charged Adekeye with 97 violations thatâ"the Canadian judge who just blew this up suggestedâ"should have only amounted to one single violation.

The US also refused to allow Adekeye to enter the US after 2008, meaning he couldnâ(TM)t testify in the litigation. Finally, in 2010, he flew to Canada to testify. At t

Spook BackDoors In Cisco Routers (continued - revision 3)
- Older news, but still relevant!!
Please save this story and repost it everywhere
Especially in Security Discussion Forum Sites
- You should use OpenBSD or a hardened Linux distro
For a router, NOT these blackboxes offered with
proprietary hardware & firmware!

"More on Cisco Building Surveillance into Routers"
http://hardware.slashdot.org/story/03/04/22/1656215/more-on-cisco-building-surveillance-into-routers

PDF: http://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-wp.pdf

PDF2: http://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-slides.pdf

Is Apparent US Conspiracy with Cisco about Wiretapping?
By: emptywheel Monday June 6, 2011 2:52 pm
http://emptywheel.firedoglake.com/2011/06/06/it-is-simply-not-done-in-a-civilized-jurisdiction-that-is-bound-by-the-rule-of-law/

Canada has just discovered how much corporations own our legal system, how our legal system criminalizes whistleblowers, and our utter and total disdain for the rule of law.

At issue is the apparent conspiracy between Cisco and the US government to respond to an anti-trust lawsuit launched by Peter Alfred Adekeye, a former Cisco employee. He sued because of the way Cisco forced customers to buy a maintenance contract for things like bug fixes.

This lawsuit is about Ciscoâ(TM)s deliberate and continuing attempt to monopolize for itself (and its âoepartnersâ (Cisco-authorized resellers of Cisco equipment and services nationwide) with which it does not significantly compete) the service and maintenance of Cisco enterprise (Cisco networking equipment for all segments (e.g., internet service providers, government, academia, small, medium and large business, etc.) with the exception of home networking equipment) hardware, principally routers, switches and firewalls. Cisco possesses a market share of approximately 70% in the networking equipment industry.

[snip]

To protect its over $6 billion yearly stream of service and maintenance revenue, Cisco has cleverly and uniquely conditioned the provision of its software âoeupdatesâ on the customerâ(TM)s purchase of a hardware maintenance service agreement called âoeSMARTnet,â

[snip]

The effect of this leveraging of monopoly power and unlawful tie-in and/or bundling is to effectively preclude any non-Cisco affiliated Independent Service Organization (âoeISOâ) from competing for the business of servicing Cisco networking hardware, thus preserving for itself all but a pittance of that line of commerce which is separate and distinct from the âoeupdatesâ of its software.

In response, Cisco counter-sued, accusing Adekeye of illegally accessing Cisco services. And Cisco either lied persuasively or got DOJ to conspire in the intimidation campaign, because DOJ then charged Adekeye with 97 violations thatâ"the Canadian judge who just blew this up suggestedâ"should have only amounted to one single violation.

The US also refused to allow Adekeye to enter the US after 2008, meaning he couldnâ(TM)t testify in the litigation. Finally, in 2010, he flew to Canada to testify. At t

So apart from the fact they're walled gardens, each implement a different subset of the standard that corresponds to whatever actual underlying protocol they use, and (in the case of MSN and Facebook) have their own authentication system that no-one else uses, in theory with a good wind behind you they can actually be connected to with some of the same code.

Well, yes :) Still, it's much better than what has to be done for other protocols.

Black Hat != Def Con. Def Con is the convention for Hackers. https://www.defcon.org/html/links/dc-about.html Black Hat is the convention for Corporates. http://www.blackhat.com/html/about.html

I don't care WHO said it. That's nothing but FUD.

He knows better then you. Trust me. Or remain a fool. http://www.blackhat.com/presentations/bh-europe-09/Miller_Iozzo/BlackHat-Europe-2009-Miller-Iozzo-OSX-IPhone-Payloads-whitepaper.pdf

Jailbroken versus Factory iPhones
Jailbroken phones are much easier to work with than factory phones. The main difference is that the jailbroken phone disables code signing. This allows for the running of arbitrary third party, unsigned, applications. Such applications include a shell, sshd, gdb, python, etc. It is no wonder that researchers prefer to work on jailbroken phones. After all, besides the code signing, there appears to be no real distinctive difference between the jailbroken and factory phones. However, this is not the case.

Many researchers, including one of the authors of this paper, have given talks where their results tacitly relied on the fact a phone was jailbroken. This is because, by disabling the code signing requirements, it doesnt just change what programs may be executed, but it fundamentally changes the way the memory page protections work. As we discussed, at this point, it is not clear how to write to a page and then make that page executable on a factory phone. While there may be a clever way to accomplish this, at the present time, any discussion of shellcode with regards to the iPhone implies the phone is jailbroken. This includes payloads that return into mprotect to set page permissions for their shellcode. If you attempt to mprotect a page which has previously had data written to it on a factory iPhone, the mprotect will fail with a return value of -1 and errno set to “Permission Denied”.

Interesting, maybe, but I don't know that I've seen anything more impressive than heap spraying. That's a hard technique to pull off.

You can't show a list of zero day exploits, by definition.

Zero day exploits are exploits for vulnerabilities that have been public knowledge for, wait for it, zero days. In other words, a '0day' is a piece of exploit code or vulnerabilty information that has not been diclosed. So, it is impossible to list the number of Linux, or any other operating system, zero day exploits in the wild.

The important metrics for risk analysis of a particular system are:
1. The number of disclosed vulnerabilities $V_d$
2. The number of those that have mitigating patches available $V_p$
3. The number of said patches that are actually deployed on the system of interest $P$
4. The total number of vulnerabilities on that class of system $V_t$

These numbers are related as follows, with the actual values left as an exercise for the risk analyst:
$V_t > V_d > V_p > P$

However, this relationship implies that every real system, consisting of some type of operating system with installed application software, has a non-zero attack surface.

Based on the number of publicly known exploits, both patched and unpatched, there must be a non-zero number number of '0day' vulnerabilities in existance, which will be in use by black-hat hackers, penetration testers and national security or intelligence agencies. This number $V_0$ is simply $V_t - V_d$ and attempts have been made to estimate this based on trends in public disclosures of vulnerabilities [1].

[1] Exposing Vendors (In)security Performance

grkvlt.

Agreed, but this part of the article had me intrigued:

It wasn't a totally perfect solution. Most specifically, ISPs can force a downgrade of https to http, but Sullivan said that Facebook had not seen that happen.

I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?

It's called SSL Stripping... It's an old issue, but a recent tool has made it a bit more mainstream. There's a presentation here: http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf. And a tool here: http://www.thoughtcrime.org/software/sslstrip/

The slides are worth looking through. At the root it's a very simple concept: people do not type https into the browser, they usually get to https through a redirect from http. A MiTM can tamper with that and continue talking http with the client... or he can talk https with both client and server (two different connections), but then he needs to play some tricks to get a signed certificate for a domain that looks to the user like facebook.com.

but Sullivan said that Facebook had not seen that happen.

How would they know? the MiTM could easily talk https with facebook.

(shameless plug) Here is his talk description, and his materials will be on-line next week after this talk. https://www.blackhat.com/html/bh-dc-11/bh-dc-11-briefings.html#Roth

True enough, but encryption works as a digital signature

No, it doesn't. Encryption without authentication is always subject to terrible attacks. Always include an authenticator in an encrypted message. An attacker not being able to decrypt a message is no barrier to his being able to manipulate it for profit.

You're not the only who has wondered that. See Kret, 2004. BlackHat Spam exists not because it is profitable - the revenue derived from people replying to spam messages is actually tiny - but because it is useful as a communications channel.

It's worth noting that the presentation titled "Bad Memmories" was presented at the BlackHat conference is very similar to this. PDF available http://media.blackhat.com/bh-us-10/whitepapers/Bursztein_Gourdin_Rydstedt/BlackHat-USA-2010-Bursztein-Bad-Memories-wp.pdf

You can do this automagically with a spam filter, with an accuracy around 99.9%

See the BlackHat 2010 paper "Keeping the Good Stuff In: Confidential Information
Firewalling with the CRM114 Spam Filter and Text Classifier".

Here's the URL to the PDF:

https://media.blackhat.com/bh-us-10/whitepapers/Yerazunis/BlackHat-USA-2010-Yerazunis-Confidential-Mail-Filtering-wp.pdf

Well, it doesn't have to be signed by a PKI. I don't trust any program just because someone was willing to pay a root CA to sign their keys.

For example, look at the Debian project. They sign all their packages with their own keys (which aren't signed by a CA AFAIK). So I download their keys over a secure channel when I download the distribution or buy them on CD. Now I can download packages even over untrusted networks (like at an University, or other public places) and I can be rather certain that I get the unmodified Debian packages.

The update protocol could just store the signing key from a particular software during registration. If any subsequent update isn't signed by that exact key, a warning could be displayed. I consider such a system to be much more secure than a complex PKI system where thousands of keys are allowed to sign the updates.

There was actually a fun story regarding update signing with a PKI a few years ago. Microsoft had signed their updates, but before installation, the only thing Windows checked was whether the update was signed with a key which was signed by the same root CA as Microsoft's key was.

So a few guys collected private keys for certificates which were signed by the same CA, which was possible during that time because of the predictable PRNG Bug in Debian's OpenSSL package.

Then, in possession of some private keys whose corresponding public keys were signed by VeriSign, they were able to sign Windows updates, just like any person who was willing to pay $200 to VeriSign for a CSR was, because all certificates signed by VeriSign were trusted by Windows.

Even the BlackHat audience couldn't believe that when they heard it the first time...(see "Hacking and Injecting Federal Trojans.")

There are ways for forensic investigators to determine if a picture has been digitally altered.

Very interesting read.

Yes, “pictures don’t lie” is an over-generalization, and like all over-generalizations it is false. However that doesn’t make it any less generally true.

Targeting the admins for access was one of the major points in HD Moore and Valsmith's talk(PDF) from Blackhat US 2007.

He cracked the SLB9635TT12 as seen on the Wiki page image.

Thanks, that is helpful, but where is this Wiki page? I looked at the BlackHat session links and right now there are just some slides that are very generic and don't mention any parts. The video and audio is not up yet.

I have no doubt he could tell us this EK you mention but this might violate the DMCA if he did.

I wouldn't think so, but even so he could instead sign a message with the EK and get the same effect, as suggested above.

Jailbroken versus Factory iPhones Jailbroken phones are much easier to work with than factory phones. The main difference is that the jailbroken phone disables code signing. This allows for the running of arbitrary third party, unsigned, applications. Such applications include a shell, sshd, gdb, python, etc. It is no wonder that researchers prefer to work on jailbroken phones. After all, besides the code signing, there appears to be no real distinctive difference between the jailbroken and factory phones. However, this is not the case.

Many researchers, including one of the authors of this paper, have given talks where their results tacitly relied on the fact a phone was jailbroken. This is because, by disabling the code signing requirements, it doesnt just change what programs may be executed, but it fundamentally changes the way the memory page protections work. As we discussed, at this point, it is not clear how to write to a page and then make that page executable on a factory phone. While there may be a clever way to accomplish this, at the present time, any discussion of shellcode with regards to the iPhone implies the phone is jailbroken. This includes payloads that return into mprotect to set page permissions for their shellcode. If you attempt to mprotect a page which has previously had data written to it on a factory iPhone, the mprotect will fail with a return value of -1 and errno set to “Permission Denied”.

One acronym and two words ... SSL Script Exploit with more information available here!

Of course the iphone is innovative. Who else but apple would think it's a good idea to blindly execute whatever program it receives by SMS?

Android? (They hadn't finished testing Windows Mobile as of when they published that paper.)

Interesting summary and paper. The gist of it is that EV-validating the main page doesn't help if it pulls in content that's protected by a weaker certificate.

I can't believe browsers do this. Just like there's a warning when a page protected by normal SSL includes unprotected content, there ought to be a warning about an EV-validated page including non-EV-validated content.

It's really terrifying how people who really should know better are negligent when it comes to browser security.

you've clearly never tried to look at skype's code then. It has multiple levels of code obfuscation.

Last I checked the majority of the program's contents are encrypted. The loader decrypts it into memory, and also deletes the boot-loader from memory. Additionally, the the program will try and detect if you are running it in a debugging environment and jump into random pages. This in turn is hard to detect because seemingly random jumps are all over the code from checking checksum's on itself (to make sure you didn't put in software debugging).

I'm not even explaining this fully-
from: http://blogs.securiteam.com/index.php/archives/355
read: http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf

You can find the archives of the talks here http://www.blackhat.com/html/bh-usa-09/bh-usa-09-archives.html , including Moxie's presentation and a video of his talk.

According to the previous article, they have found a way to send sms messages without any provider: "This method does not use the carrier and so is free (and invisible to the carrier)". So blocking at the provider level won't work unfortunately

http://www.blackhat.com/presentations/bh-europe-09/Gassira_Piccirillo/BlackHat-Europe-2009-Gassira-Piccirillo-Hijacking-Mobile-Data-Connections-whitepaper.pdf The weakest link is always exploited first. Trust nothing.

Non only apple fanboys

Yes, only apple fanboys.

From: http://www.blackhat.com/html/bh-usa-09/bh-usa-09-speakers.html#Miller

We present techniques which allow a researcher to inject SMS messages into iPhone, Android, and Windows Mobile devices.

You'll note the specific absence of the phrases vulnerability or code execution in that description. And if you'd bothered to keep it in context, you would have included the next sentence, which mentions that the reason it's important is that this is the ability to inject SMS without using the carrier.

So yeah, it is only apple fanboys.