Not much larger than a quarter, the technology behind it is comprised of a micro controller and other associated electronics (memory, I/O, etc). The result is a very functional, yet flexible, USB thingamabob that can let people program their own logic to run their own routines, commands, and instructions.
Teensy was recently used in a unique demonstration of some interesting security implications that arise from exploiting the USB-to-OS trust relationship. By programming Teensy to identify itself as a keyboard, someone could trigger it to send automated keystrokes at will (or set via timer).
But this has been possible for years. In fact, for this example in-particular, it’s probably desirable for users to not have to do any real configuring to get their keyboard or mouse to work. Perhaps the underlying issue is that many vulnerabilities are introduced when trying to balance convenience with security.
But the flip side might be that real change is coming from the other direction. As technology evolves, it gives attackers more tools with which to express their creativity. A few short years ago, programming logic into a USB device like this might have cost a few hundred dollars of equipment and a good amount of coding, just to do something simple.
Teensy is dirt cheap and there is a software library already written for it. This makes it easy to jump right in and start making stuff because the barrier to entry for this vector has been lowered by better technology. As a tool, a device like Teensy offers potential that is only limited to what the creative individual can fit into the on-board flash memory module. In a way, the bad guys get new toys, while the good guys just get more stuff to patch, secure, and protect against.
Researchers have developed a method (pdf) by which they are able to record the sound of a dot matrix printer in operation and recreate the information that was printed based on the audio data. Data leakage from electronic devices isn’t new (TEMPEST comes to mind). However, it seems like the higher-profile methods tend to encompass electromagnetic properties rather than mechanical properties.
For authentication, newer versions of Oracle (11g+) use a session agreement and key exchange scheme known as O5Logon. It has some of the same weaknesses of authentication as the O3Logon used in previous versions of Oracle.
An example transcript of the default auth process:
1) Client connects to Server:
2) Client sends Username to Server
3) Server generates a ServerSessionID and encrypts it with AES. The key is the PasswordHash. It sends this encrypted ServerSessionID and the PasswordSalt to the Client
4) Client tries to generate a password hash using the PasswordSalt and the provided password. It decrypts the ServerSessionID using this ClientPasswordHash
5) Client generates a ClientSessionID and encrypts it with AES. The key is the ClientPasswordHash. It combines ServerSessionID and ClientSessionID to make another key which it uses to directly encrypt the provided password. It sends this encrypted password and encrypted ClientSessionID to the Server.
A more in-depth breakdown of the steps involved can be found here.
So, although there is a lot going on, the password itself is never really sent in clear text. This scheme also prevents against replay attacks, since the session IDs are different each time. The drawback is the fact that capturing all of the transmissions can allow an attacker to brute force the password in an offline environment. This is possible because guessing the hash will allow an attacker to simply decrypt the password sent from the client by sniffing the transmissions and comparing them later.
I think it’s possible to gain the same reply protection without exposing the password like that, but it would almost certainly take more steps. This scheme was probably designed to be very fast while providing protection against the most common attack scenarios. In comparison, TLS-based authentication is an alternative to O5Logon for Oracle, and does all sorts of cert. exchanging and flippidy floppidy. It provides better protection, but at the potential expense of being overkill if you just want decently secure authentication, and I think that’s one reason it’s an option instead of the default. In general, O5Logon is fine if the user chooses a strong password. As usual, the most critical link in the security chain is the individual.
Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!
The .ORG top level domain (TLD) recently received its DNSSEC signature, and now has the ability to provide integrity information about its underlying domains. This is important because it’s the first TLD to get signed. This also means it might be somewhat of a guinea pig, as any uncaught issues or bugs will probably show up when people invariably start trying to break the system.
We covered DNSSEC a bit in a previous post, and it is interesting to see how much progress has been made since then. DNSSEC isn’t new. In fact, it’s been around for a quite some time in one unfinished form or another. It wasn’t until the Kaminsky DNS cache issue a few years ago that we saw a sudden surge in DNSSEC development and deployment.
But if history is any indication, the transition might not be smooth. Each registrar under a TLD has to support DNSSEC individually. This would create new costs and overhead (especially for small registrars), in addition to exacerbating the issue of fragmentation. And although a spotty DNSSEC is better than none at all, it really needs to be ubiquitous to maximize its usefulness.
In celebration of Facebook’s recent privacy control revamp, I present a very informative tutorial video from the Electronic Frontier Foundation that gives a brief rundown of the changes, the highs, and the lows. This might also be something beneficial to share with friends or relatives on Facebook who may not be in-the-know about the increased focus on privacy control in social networking and social media.
TheKish cypher is categorized as a technique for secure communication, similar in application to Quantum encryption and Public Key cryptography. The simplified explanation is that it works by measuring the resistance of the communication medium (i.e. a circuit, or some wire) between 2 parties. One party can “send” messages by changing the resistance of the medium (i.e. placing a resistor on the wire). The other party can “read” messages by deriving the difference between the amount that the resistance has changed and the amount of resistance they are contributing to the wire as well.
Ideally, an eavesdropper would not be able to read the messages since he can’t derive this difference (he doesn’t know both resistances), hence Kish’s usefulness for secure communication.
The cool part about Kish (besides its name) is that it’s such a simple system to build from a component standpoint. In fact, most of the infrastructure for this type of system already exists– the medium itself can be any single wire connecting two parties.
- Status of the idealistic circuit scheme: Unconditionally secure; it has not been cracked.
- Status of the practical (non-ideal) system with inaccuracies and stray elements (hacking):
A small information leak of raw bits, similarly to quantum communicators. The amount of leaking information can be controlled (Alice and Bob determine the amount of information Eve can have). The scheme cannot be cracked but it can be jammed (similarly to quantum key exchange, when Eve randomly measures and supplies back a small fraction of photons; an operation which cannot be detected by Alice and Bob because it yields too small quantum error rate). However, for a major difference from quantum communicators, note that Alice and Bob are fully aware of all the information Eve knows. Thus they are in the position to discard or manipulate the information Eve has.
Apparently, it can hold its own from a security perspective (it’s certainly been scrutinizedenough). And despite not winning any popularity contests, Kish’s unique physical nature means that there may be some very specific situations where it would be the only solution for secure communications.
Browser security is a topic that spans a wide range of subjects. This isn’t surprising given the number of exploit techniques that rely on webpages as a primary delivery channel in their attacks. Successful XSS, CSRF, SQL injection (via web app), and plug-in-based attacks all take advantage of the environment provided by the web browser.
Despite the importance of the browser in the chain of security, information on exactly how it goes about managing javascript across domains and determining when to show the “save as” download dialog can be overlooked. However, this is an area where attackers may concentrate their efforts to hedge out new exploits based on a weakness in browser security.
The Browser Security Handbook, released in 2008, is a frequently-updated information repository for all things dealing with modern browser security. It includes the methods presently employed by various browser vendors to improve the security on the application end, as well as some experimental techniques.
It’s certainly worth adding to your collection of security-related links.
The Polytechnic Institute of New York University has some excellent videos of presentations from their Penetration Testing and Vulnerability Analysiscourse. These videos are great for getting a quick introduction to the topics they cover:
Source Code Auditing
Identify vulnerabilities and programmer errors by auditing source code
Reverse Engineering
Understand, modify, and analyze compiled applications and systems to identify vulnerabilities
Exploitation
Take advantage of vulnerabilities to gain access to restricted data and break security policies
Fuzz Testing
Uncover high volumes of software security errors with a special type of negative testing
Client-side Exploits
Indirectly attack the users in your network and automate the collection of data from them
Web Hacking
Identify and exploit vulnerabilities in web applications to gain access to sensitive data and escalate privileges to the host operating system
If you’ve ever had to set up iptables rulesets, then you know how obscure the syntax for those configuration files can be (unless you’re used to it already). Fortunately, FireHOL provides a simple, clean, easy-to-understand language for describing complex iptables rules.
For example, lets say I was running a local DNS cache server that is configured to hit an external DNS server on cache misses:
Obviously, FireHOL’s strength lies in its ability to represent iptables rules in a simpler, more intuitive format.
To be fair, iptables is designed to give the user as much freedom as possible to create their ruleset. This comes at a cost to usability, as the syntax can become pretty ungainly, especially for complicated setups. By simplifying the language used to describe firewall rules, FireHOL makes it that much easier to write the rules without having to google for examples to copy-paste-modify. Also, since FireHOL only provides a transitional language that is eventually converted to iptables rules, it is able to maintain that same flexibility to create highly-customized rulesets. This is true even on systems that require large and complex firewall rules.
FireHOL
If you’ve ever had to set up iptables rulesets, then you know how obscure the syntax for those configuration files can be (unless you’re used to it already). Fortunately FireHOL provides a simple, clean, easy-to-understand language for describing complex iptables rules.
For example, lets say I was running a local DNS cache server that is configured to hit an external DNS server on cache misses.
To be fair, iptables is designed to give the user as much freedom as possible to create their ruleset. This comes at a cost to usability, as the syntax can become pretty ungainly, especially for complicated setups. By simplifying the language used to describe firewall rules, FireHOL makes it that much easier to write the rules without having to google for examples to copy-paste-modify. Also, since FireHOL only provides a transitional language that is eventually converted to iptables rules, it is able to maintain that same flexibility to create highly-customized rulesets. This is true even on systems that require large and complex firewall rules.
Message Authentication Codes (MACs) are special pieces of data used to prove the authenticity and integrity of a message– to show that the message originated from a certain source and that it has not been modified. Consider a scenario in which Alice wants to send Bob an email. Upon receiving the email, Bob would like to be fairly certain that Alice was indeed the author and that the letter hasn’t been changed. When creating her email, Alice needs to have some technique that satisfies Bob’s concerns.
First, she appends a secret word to the very end of the message. This secret word is only known by Alice and Bob.
Next, she creates a unique “footprint” of her email by running it through a hash function (along with the secret appended at the end).
Finally, she sends the original message (sans the secret word) to Bob. She also sends him the digest/hash/footprint.
When Bob gets the message:
First he adds the secret word to the very end of the message (just like Alice did).
Then he runs the message + secret through the exact same hash function that Alice did.
Finally, he compares the resulting “footprint” with the one Alice sent him. If they match, the he can be confident that Alice sent it (since she’s the only other one who knows their secret) and that the message hasn’t been tampered with (since any change in the message would result in a different footprint).
This is almost identical to the way digital signatures work. However, MACs rely on a shared secret and, therefore, aren’t inherently based on public key theory. In addition, digital signatures are able to establish non-repudiation, which is not the case with MACs. In the above example, Bob could create an email from Alice to himself and Alice would not be able to prove she didn’t send it using just the MAC.
For this reason, MACs are most commonly used for inter-system communication. Webservers, specifically, make use of MACs to protect against cross-site request forgery (CSRF) attacks.
However, a common misconception with creating MACs is that any strong hash function alone is sufficient when creating an effective MAC. In reality, MAC-specific algorithms are designed to address some weakness with recklessly using block-level iterative hash functions (MD5, SHA, etc) concatenated to some shared secret. Specifically, the use of a Hash(message || secret) approach is susceptible to attack since someone could use information on known message/hash combinations to construct a new, working message/hash. By using a MAC-specific algorithm, such as HMAC or CMAC, these weaknesses can be mitigated or avoided altogether. So if you’re ever in a situation where you could benefit from a hastily-implemented MAC, be sure to consider both its strengths and weaknesses.
