You are currently browsing the category archive for the ‘security’ category.

I was just reading the newest post by Google’s Project Zero. They just released a report on a massive bug that allows remote code execution by exploiting a vulnerability on the 802.11 Broadcom SoC used in most smartphones.

Actually, the bug is not massive (it is, after all, just a simple buffer overflow because boundaries are not well checked when processing a specific type of packet), but its consequences are massive indeed. The vulnerability is specific to the parsing of certain messages in 802.11z TDLS, a mode of P2P ad-hoc communication. The report published by Gal Beniamini is just the first part of the overall project, and it “just” shows up to remote code execution on the Broadcom wifi SoC, but it hints that it can be leveraged to gain remote code execution ability in the application’s processor:

In the next blog post, we’ll see how we can use our assumed control of the Wi-Fi SoC in order to further escalate our privileges into the application processor, taking over the host’s operating system!

Long story shirt, this vulnerability results in a massive vulnerability. Theoretically (I am eager to see the second part of this report!), an attacker can take over a smartphone’s OS by simply sending malformed WiFi frames, achieving full device takeover by WiFi proximity alone. The good news is that this bug has been patched already both for iOS devices and Android devices, so I’d say you go ahead and update your mobile’s OS if you haven’t in a while.

I strongly recommend folks to read the report by Gal Beniamini, as it is excellently written and easy to understand and follow. It’s actually a great reference/introduction to buffer overflows and how to leverage them for malicious intent. The overall exploit is rather complex, but very nicely explained step by step in the report.

Fun stuff!

I was reading this morning a new paper on the topic of LTE IMSI catchers: https://arxiv.org/pdf/1702.04434.pdf

Mjølsnes, Stig F., and Ruxandra F. Olimid. “Easy 4G/LTE IMSI Catchers for Non-Programmers.” arXiv preprint arXiv:1702.04434 (2017).

Although this is old news, it is exciting to see that the recent discovery and implementation of LTE IMSI catchers by the team of Prof. Seifert at TU Berlin (Oct 2015 – https://arxiv.org/pdf/1510.07563.pdf) has sparked the interest in this area. The paper also mentions the DoS threats that were introduced by the same team in [1]. I have done some work and implementation of LTE IMSI catchers and the DoS exploits myself in the past as well ([2] and [3]).

I was giving a talk on this topic last week at UC Irvine, trying to encourage graduate students to focus their PhD research in this area as there is still a lot of work to be done. We need the talented minds of graduate researchers to come up with new threats and, more importantly, solutions to these threats.

Back to this new paper, it is a great overview of IMSI catchers and it is great that the authors implemented the IMSI catcher using an alternative tool (Open Air Interface). I found interesting, though, that they state that implementing an IMSI cather on openLTE requires source code modification such that it is not a viable option for “non programmers”.

Although the claim of their implementation being for non-programmers is obviously correct, their LTE IMSI catcher uses very similar software and the same computing equipment as the ones in [1,2,3]. I would argue that adding 3 lines of code to openLTE is something a non-programmer could do as well. This is what the authors of [1] did. The only modification required at openLTE (as I have explicitly stated at every talk I have given) is mostly to add an fprintf statement where openLTE parses the AttachRequest message or the TAU/LocationArea Update message. Although one can do slightly fancier things.

Anyhow, maybe I am too optimistic and expecting a non-programmer to add an fprintf statement in openLTE is perhaps asking too much 🙂

Regardless, this new paper is great and very interesting and an excellent reference on this topic. I am wondering if they will be presenting their work at a conference soon?

I look forward to more and more research in this area.

[1] Shaik, Altaf, et al. “Practical attacks against privacy and availability in 4G/LTE mobile communication systems.” arXiv preprint arXiv:1510.07563(2015).

[2] Jover, Roger Piqueras. “LTE security and protocol exploits.” ShmooCon (2016).

[3] Jover, Roger Piqueras. “LTE security, protocol exploits and location tracking experimentation with low-cost software radio.” arXiv preprint arXiv:1607.05171 (2016).

Authentication in mobile networks is executed leveraging a symmetric key system. For each mobile subscriber, there is a secret key that is known only by the mobile device and the network operator. Actually, it is not the device itself holding the key, but the SIM card. On the network side, in the case of LTE, the secret key is stored in the Home Subscriber Server (HSS).

Based on this pre-shared secret key, a mobile device and the network can mutually authenticate itself. Though, this is not necessarily the case. For some reason someone must have thought, when designing 2G-GSM, that having the end point authenticate the mobile network was not a requirement… too bad that not having mutual authentication opens the door to all types of rogue base station MitM attacks. Bad things also happen when this pre-shared “secret” key is sent from the SIM card manufacturer to the mobile operator in the clear in a bunch of DVDs and someone manages to steal them.

After years or security research in mobile networks, identifying, implementing and testing protocol exploits, I started thinking that perhaps it would be a good idea to transition the security architecture of a mobile networks towards a PKI-based system. This is why I really enjoy reading research papers with PKI proposals for mobile networks, which is a rather rare topic in the research community. Thanks to Google Scholar, a very interesting paper showed up in my radar: Chandrasekaran, Varun, and Lakshminarayanan Subramanian. “A Decentralized PKI In A Mobile Ecosystem.

PKI would increase the complexity of each cryptographic operation, but it is not like device and network authenticate each other constantly. Definitively, a lot of research would have to be done to validate whether it would be possible.

With a PKI-based authentication architecture in mobile networks, so many cool things could potentially be done. For example, it is very well understood that, regardless of mutual authentication and strong encryption, a mobile device engages in a substantial exchange of unprotected messages  with *any* LTE base station (malicious or not) that advertises itself with the right broadcast information (and this broadcast information is transmitted in the clear in the SIB broadcast messages). And this is the source of a series of protocol exploits and attacks. Perhaps, by means of PKI, broadcast messages could be “signed” by the operator in a way that mobile devices could verify their freshness (to avoid replay attacks) and verify that the base station is legitimate. This would allow mobile devices to verify the legitimacy of a base station before starting to engage in RACH procedures, RRC connection establishments, NAS attach exchanges, etc.

Anyhow, very interesting paper on cool things that could be done applying PKI to mobile networks. Worth reading it.

 

(Yes, after months? maybe years? I decided to get back to being somehow active on my blog… Most likely I’ll just be posting about security and wireless/mobile interesting stuff)

I was reading this morning a very cool paper from a team at MITRE implementing a jamming mitigation engine leveraging beamforming. The idea is to generate a null in reception at the direction from which the jamming signal is coming from.

Link to the paper: http://ieeexplore.ieee.org/abstract/document/7795331/

It is very interesting that this type of jamming mitigation is becoming popular. It is an area with a lot of potential, specially in the context of 5G, communication at mmWaves and massive arrays of antennas.

My former team and I worked in a very similar idea in the past. We both implemented a beamforming-based mitigation for radio jamming against LTE (details in this paper) and there’s a bunch of patents already public about that technology: beamforming at the eNodeB and beamforming at the UE. In the case of the UE, we also used beamforming to increase the capacity and throughput of the system… a bit of a utopian idea that, actually, now makes much more sense with carrier frequencies in the mmWave range and above and massive arrays of antennas in the context of 5G. I strongly recommend to read Prof. Rappaport’s work in this area for more details.

Anyhow, the paper is VERY interesting and presents some exciting area in this area.

https://static-content.springer.com/image/art%3A10.1186%2F1687-417X-2014-7/MediaObjects/13635_2013_Article_22_Fig7_HTML.jpg

I was reading last night about Blackphone, one of the most interesting things presented at the recent Mobile World Congress in Barcelona. This new handset is being developed by a Spanish startup (Geeksphone) in partnership with the US-based security firm Silent Circle. The whole system appears to be based on a security-enhanced version of Android known as PrivatOS.

This phone is clearly a very interesting idea and a product to consider, specially because it is the first time someone does an actual step towards ensuring privacy of communications for smartphone users. However, I would like to have more details on how everything work. Blackphone claims that it can do encrypted voice calls, but something tells me that this is probably only possible among Blackphones and you cannot have an encrypted call with a “normal” phone. Moreover, this is not something new, as there are apps out there that allow to do the same things on, for example, an Android phone. The only privacy concern with those is whether the server running the app in the background gets to “see” the messages or not. And the same question applies to the Blackphone. I am assuming that, if the crypto is well done, everything stays within the phones involved in the “secret call”. But, again, having more tech details would be helpful.

On top of secured calls and messages, which can already be done with several well known apps (for example RedPhone), Blackphone has other interesting features, such as a fine-grained control of the permissions each app gets. On top of that, Blackphone does very simple things automatically, such as configuring WiFi in a way that it is not trying to connect to any hotspots it senses (avoiding potential Man-in-the-Middle attacks). It also seems to offer a way to remotely wipe the device without requiring a centralized service (like the Find My Phone feature from iCloud). I wonder how they do this, though, and how they address the wipe command from an arbitrary place in the Internet (i.e. my home computer) to the Blackphone without a server somewhere in between that keeps an open connection with the phone.

All in all, a very interesting phone, yours for 629$.

blackphone

Through one of my colleagues I learned yesterday about the infamous iOS SSL bug that resulted in iOS devices accepting any certificates whether they were correct or incorrect. This could allow an attacker or man in the middle to eavesdrop or intercept traffic theoretically secured through, for example, https.

I am not going to write today about what the bug does and the potential impact. I will, however, highlight the fact that this bug seems to have gone unnoticed since iOS 6 in 2012, which is quite scary. If you are interested in the bug and more details on the media burst it has created, you can read about it here, here or here.

I want to focus specifically on what the bug was. This bug that has terrifying consequences is just a basic and simple human mistake, probably originated at a classic copy-paste of code. Let’s look at the code, which I found here and is, in turn, from the Apple’s published open source code (which, obviously, is already fixed).

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,uint8_t *signature, UInt16 signatureLen)
{
    OSStatus        err;
    ...

    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
        goto fail;

    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;

    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
        goto fail;
    ...

fail:
    SSLFreeBuffer(&signedHashes);
    SSLFreeBuffer(&hashCtx);
    return err;
}

Essentially, after the second check, the line of code that goes to fail is repeated. Therefore, the third and last check for the hash is never executed and this subroutine always goes to fail. As you can see, this is not the fanciest bug ever. On the contrary, it is most likely a classic copy-paste human error.

I have always been very particular when coding in C and Java and I ALWAYS use {} for condition statements. So, although this

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;

is exactly the same as this

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0){
    goto fail;
}

using the latter would have avoided this bug. So, long story short, the conclusion is: always use {}. And a related corollary, vi and vim for Unix are cool and you look very cool and smart using them, but always use an IDE when coding. They are very smart and helpful. An IDE would have highlighted in bright annoying yellow the third hash check and labeled it as “dead code“. If you are a Unix user, I recommend Eclipse.

I read this morning some very interesting news about Twister, a new decentralized and anonymous Twitter-like social network. It was created by Miguel Freitas, an engineer based in Rio De Janeiro, this new micro-blogging application can’t be shut down by, for example, some nation state or large corporation. Also, Twister is designed in such a way that other users cannot know whether you are online, what your IP address is, or who you follow.

As a bitcoin “aficionado”, I find particularly interesting that the magic behind Twister is this popular alternative currency. It is another great example of the great range of potential applications that bitcoins unfold.

You can read more about this story at Wired Magazine:

Twister is surprisingly easy to use for an application that’s so new, that isn’t controlled by a central authority, and that places so much emphasis on security. Other decentralized alternatives to Twitter and Facebook — such as Pump.io, Identica and Diaspora — require that you either operate your own dedicated server or trust someone else to run a server for you. Twister works more like peer-to-peer file sharing software: Launch the app, and it connects with other users. There’s no need for a central server.

It manages this trick through the bitcoin protocol, though not the network that actually drives the digital currency. Basically, the protocol handles user registration and logins. Just as machines — called miners — verify transactions over the bitcoin network to ensure no one double-spends bitcoins and everyone spends only their own coins, a network of Twister computers verifies that user names aren’t registered twice, and that posts attached to a particular user name are really coming from that user.

Posts are handled through the BitTorrent protocol. This lets the system distribute a large number of posts through the network quickly and efficiently, and it lets users receive near-instant notifications about new posts and messages — all without the need for central servers.

I was reading this story earlier today after a colleague shared it. I thought it was very interesting. The research company Renesys has recently disclosed their findings on something as interesting as concerning. For a few days, all the traffic coming from a list of some of the major cities in the US and over the world was routed over Belarus and Iceland. Renesys claims this was an attack and that the main goal was to scan, analyze and perhaps even store all the traffic to obtain who knows what.

In the data analysis they perform they found highly interesting cases, like the one mentioned in the article. An email sent from Guadalajara in Mexico to DC was, at some intermediate step in Virginia, routed to Russia and then, after going through the potentially malicious route in Belarus, was routed back to the US via Frankfurt and New York. It seems that everything originated from an attack on the BGP routing tables (BGP hijacking).

routeAll our communications are encrypted and secured and, unless you work in some top secret organization, there is nothing to worry about. But, still, this is quite preoccupying. I wonder what was the motivation behind this attack.

The report from Renesys presents more evidence from the subsequent attack that routed traffic over Iceland. This report, which you can find here, also discusses in the implications of this attack.

When looking for a good link to refer readers to BGP hijacking information, I found this Defcon talk. Very interesting stuff.

Did you install iOS 7 because you did not want to wait. Well, in that case, you should make sure you do not loose your phone or get it stolen. The reason is a quite preoccupying and basic security flaw in iOS 7 that allows to bypass the lock screen.

This flaw was found by a Spanish soldier, who posted a video on YouTube to prove it. Now Apple representatives say they are working on fixing it.

You can read more about it in La Vanguardia (news in Spanish).

By the way, note that the flaw affects every type of device able to run iOS 7 *except* the new iPhone 5S.

I recently read a very interesting and detailed article that a colleague at work recommended. The article presents a very thorough overview of the latest revolution in consumer electronics combined with wireless communications: the Internet of Things (IoT).

The concept of the IoT defines a (near) future scenario where most (if not all) things on our physical world and lives will be interconnected with each other using all kinds of wireless protocols, such as WiFi, ZigBee, ZigWave, etc. On top of this myriad of interconnected sensors and actuators, a new playground for developers and people with ideas will be ready for new services (and even entire businesses) to be created, all following a similar “mobile OS – app” scheme. And all these new services will be based, according to the article’s author, on simple “if – then” rules:

If  the sun hits your computer screen, then you lower a shade. If  someone walks in the door, then you turn down your music. If  there’s too much noise outside, then you close your window. If  you have a Word document open but haven’t finished writing a sentence in 10 minutes, then you brew another pot of coffee.”

But all these cool new applications will result on new challenges. One of them (the main one, according to the author), will be battery and wireless charging technologies. Indeed, while semiconductors and transistor technology has evolved steadily following Moore’s law, battery technology has been pretty much stale (What time in the afternoon you have to charge your smart-phone on a day you go to work? If it is after 4pm, I want to know what phone you have). There is a great need for better and longer lasting batteries for mobile devices, as well as some kind of technology that feeds itself wirelessly through the signals it receives. Something similar to an RFID tag. Perhaps some day the power consumption of electronic devices will be low enough to get them to charge the battery by means of the actual power the wireless signal carries. Until then, some proposals might help us along the way. For example the wireless electric transmission proposed by the MIT start-up WiTricity.

IoT

I am a bit surprised that the author does not highlight too much the security challenges that the IoT will bring to communication systems. In do not think that “[…] Just as with social networking, the privacy concerns of a sensor-­connected world will be fast outweighed by the strange pleasures of residing in it“. I would definitively not feel comfortable at all with my garage door opening when my IoT hub at home, after receiving a message from my car’s geo-location system, sends an “open” command over ZeeWave… specially knowing that someone will show how to hack ZeeWave this summer at Blackhat. I agree with the author, however, in the fact that “[…] our recent hacking epidemic has largely exploited the human interface—the password. We’re always the weak link in online security […]“.

Anyhow, one thing I do know is that in the near future the IoT will change things and our day-to-day lives will look much like the movie Minority Report, with cereal boxes with displays and interactive commercials, personalized advertisements in the subway and smart stores.

About me:

Born in Barcelona, moved to Los Angeles at age 24, ended in NYC, where I enjoy life, tweet about music and work as a geek in security for wireless networks.
All the opinions expressed in this blog are my own and are not related to my employer.
About me: http://rogerpiquerasjover.net/

Blog Stats

  • 124,284 hits

Twitter feed

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Enter your email address to follow this blog and receive notifications of new posts by email.