Category: RESEARCH

RESEARCH | August 19, 2014

Silly Bugs That Can Compromise Your Social Media Life

By Ariel Sanchez
A few months ago while I was playing with my smartphone, I decided to intercept traffic to see what it was sending. The first thing that caught my attention was the iOS Instagram app. For some reason, the app sent a request using a Facebook access token through an HTTP plain-text communication.

Here is the original request that I intercepted from the Instagram app:
 
POST /api/v1/fb/find/?include=extra_display_name HTTP/1.1
Host: instagram.com
Proxy-Connection: keep-alive
Accept: */*
Accept-Encoding: gzip, deflate
Content-Length: 337
Content-Type: multipart/form-data; boundary=Boundary+0xAbCdEfGbOuNdArY
Accept-Language: en;q=1, es-MX;q=0.9, fr;q=0.8, de;q=0.7, zh-Hans;q=0.6, zh-Hant;q=0.5
Cookie: ccode=AR; csrftoken=dab2c8d0c4fd28627ac9f2a77fa221d2; ds_user_id=1045525821; igfl=testlocura; is_starred_enabled=yes; mid=UuvAbgAAAAHj6L0tnOod5roiGYnr; sessionid=IGSC3aaf1427aa901bb052263b368642a34fe59897cba046682b7d95775ae70db64d%3AioaQSiHdJ61kCjuRaAD9sEJTEWXv6dqB%3A%7B%22_token%22%3A%221045525821%3Au91J1dZgsiJCBo0QVeF98nkohO0TV928%3A70d9eee5449941dc80fb238991e191f8f33cac5c98c1b078d86975b07979531d%22%2C%22last_refreshed%22%3A1392496331.661547%2C%22_auth_user_id%22%3A1045525821%2C%22_auth_user_backend%22%3A%22accounts.backends.CaseInsensitiveModelBackend%22%2C%22_platform%22%3A0%7D
Connection: keep-alive
User-Agent: Instagram 5.0.2 (iPhone5,3; iPhone OS 7_0_4; en_US; en) AppleWebKit/420+
 
–Boundary+0xAbCdEfGbOuNdArY
Content-Disposition: form-data; name=”fb_access_token”
 
CAABwzLixnjYBAE71ZAmnpZAaJeTcSqnPSSvjEZA0CqIokUOj60VkZCOhuZCy4dT6TlcG9OpbMIO7dJnGiROm7XFEnRj….
–Boundary+0xAbCdEfGbOuNdArY–

After a quick review, I determined that the request was sent when I clicked on the Facebook Friends button, which allows users to search for friends from their Facebook account.
 
As an aside, an access token is an opaque string that identifies a user, app, or page. It can be used to perform certain actions on behalf of the user or to access the user’s profile. Each access token is associated with a select set of permissions that allow users to perform actions, such as reading their wall, accessing friend profiles, and posting to their wall.
 
In this case, these permissions were granted to the access token:
  • installed
  • basic_info
  • public_profile
  • create_note
  • photo_upload
  • publish_actions
  • publish_checkins
  • publish_stream
  • status_update
  • share_item
  • video_upload
  • user_friends
Potential Risk
 
Sending a request using access token through a plain-text communication poses a potential risk. An attacker who can intercept the app’s traffic and acquire access tokens can gain access to Facebook user accounts and manipulate their walls and access personal information.
 
If you use Instagram on a public WiFi, then someone might access your Facebook account and hack it.
 
Conclusion
 
Third-party apps that use these access tokens to associate users with their Facebook accounts should take extra precautions to protect their integrity and confidentiality. This will help avoid potential risks of leaking user information. 
 
Instagram already fixed the vulnerability mentioned in this blog post. 
Ariel Sanchez
RESEARCH | August 14, 2014

Remote survey paper (car hacking)

By Chris Valasek
Good Afternoon Interwebs,
Chris Valasek here. You may remember me from such nature films as “Earwigs: Eww”.
Charlie and I are finally getting around to publicly releasing our remote survey paper. I thought this went without saying but, to reiterate, we did NOT physically look at the cars that we discussed. The survey was designed as a high level overview of the information that we acquired from the mechanic’s sites for each manufacturer. The ‘Hackability’ is based upon our previous experience with automobiles, attack surface, and network structure.
Enjoy!
RESEARCH | July 31, 2014

Hacking Washington DC traffic control systems

By Cesar Cerrudo

This is a short blog post, because I’ve talked about this topic in the past. I want to let people know that I have the honor of presenting at DEF CON on Friday, August 8, 2014, at 1:00 PM. My presentation is entitled “Hacking US (and UK, Australia, France, Etc.) Traffic Control Systems”. I hope to see you all there. I’m sure you will like the presentation.

I am frustrated with Sensys Networks (vulnerable devices vendor) lack of cooperation, but I realize that I should be thankful. This has prompted me to further my research and try different things, like performing passive onsite tests on real deployments in cities like Seattle, New York, and Washington DC. I’m not so sure these cities are equally as thankful, since they have to deal with thousands of installed vulnerable devices, which are currently being used for critical traffic control.

The latest Sensys Networks numbers indicate that approximately 200,000 sensor devices are deployed worldwide. See http://www.trafficsystemsinc.com/newsletter/spring2014.html. Based on a unit cost of approximately $500, approximately $100,000,000 of vulnerable equipment is buried in roads around the world that anyone can hack. I’m also concerned about how much it will cost tax payers to fix and replace the equipment.

One way I confirmed that Sensys Networks devices were vulnerable was by traveling to Washington DC to observe a large deployment that I got to know.

When I exited the train station, the fun began.

RESEARCH | April 17, 2014

A Wake-up Call for SATCOM Security

By Ruben Santamarta
During the last few months we have witnessed a series of events that will probably be seen as a tipping point in the public’s opinion about the importance of, and need for, security. The revelations of Edward Snowden have served to confirm some theories and shed light on surveillance technologies that were long restricted.
 
We live in a world where an ever-increasing stream of digital data is flowing between continents. It is clear that those who control communications traffic have an upper-hand.
 
Satellite Communications (SATCOM) plays a vital role in the global telecommunications system. Sectors that commonly rely on satellite networks include:
  • Aerospace
  • Maritime
  • Military and governments
  • Emergency services
  • Industrial (oil rigs, gas, electricity)
  • Media
It is important to mention that certain international safety regulations for ships such as GMDSS or aircraft’s ACARS rely on satellite communication links. In fact, we recently read how, thanks to the SATCOM equipment on board Malaysian Airlines MH370, Inmarsat engineers were able to determine the approximate position of where the plane crashed. 
 
IOActive is committed to improving overall security. The only way to do so is to analyze the security posture of the entire supply chain, from the silicon level to the upper layers of software. 
 
Thus, in the last quarter of 2013 I decided to research into a series of devices that, although widely deployed, had not received the attention they actually deserve. The goal was to provide an initial evaluation of the security posture of the most widely deployed Inmarsat and Iridium SATCOM terminals.  
 
In previous blog posts I’ve explained the common approach when researching complex devices that are not physically accessible. In these terms, this research is not much different than the previous research: in most cases the analysis was performed by reverse engineering the firmware statically.

 
What about the results? 
 
Insecure and undocumented protocols, backdoors, hard-coded credentials…mainly design flaws that allow remote attackers to fully compromise the affected devices using multiple attack vectors.
 
Ships, aircraft, military personnel, emergency services, media services, and industrial facilities (oil rigs, gas pipelines, water treatment plants, wind turbines, substations, etc.) could all be affected by these vulnerabilities.
 
I hope this research is seen as a wake-up call for both the vendors and users of the current generation of SATCOM technology. We will be releasing full technical details in several months, at Las Vegas, so stay tuned.
The following white paper comprehensively explains all the aspects of this research IOActive_SATCOM_Security_WhitePaper
RESEARCH | March 16, 2012

Atmel AT90SC3232CS Smartcard Destruction

By IOActive

Having heard that Atmel actually produced three variants of the AT90SC3232 device, we did some digging and found some of this previously never-seen-by-Flylogic AT90SC3232CS.  We had already several AT90SC3232 and AT90SC3232C.  We assumed that the CS was just a 3232C with an extra IO pad.  Well, one should never ass-u-me anything!  The AT90SC3232CS is a completely new design based on the larger AT90SC6464C device.

Decapsulation revealed that Atmel actually did place an active shielding over the surface of the device.  A 350nm, 4 metal process was used on the AT90SC3232CS where the AT90SC6464C was a 350nm, 3 metal.

A quick polishing session removes that residue you saw in the previous photo.  Now the device looks very similar to the AT90SC6464C.

Given the AT90SC family all run encrypted code that even Atmel claims they don’t know the key on.  It’s mandatory to polish down the device and image areas of interest at each level to trace through the logic.

With the chip at Metal 2, it was time to go to Metal 1.  This is where the actual transistor is put together to become something such as AND, OR, INVert, …

While not really required but always desired, removal of Metal 1 leaves us with the poly/diffusion areas visible.  This is always helpful to explain P/N FETs for our purposes.
Given the feedback received from the recent 3 Metal display, we thought we would do it again.  This time however, we imaged it at 1000x for a distance of 25,000 pixels across by 2413 down (25,000 is the max a JPEG will allow).

Having no knowledge of how the Atmel AVR smart card family works means we have to tear it down and trace out the databus paths.  The next 4 images are just a sample of the real image we created.  The real image is so huge, it would take days to download.

The next four images can be clicked on to open up the full 25,000 pixel JPEG.  Metal 4 was not imaged because it was the active shield.  The active shield is an obstacle  that can be ignored until the signals determined to be important are identified.

 

This is definitely the memory encrypt-decrypt block (MED) or at least the entry of it ;).

 

RESEARCH | January 8, 2009

Intel 4004

By IOActive

Before going deeper into the analysis of today’s chips, we will take a quick journey to where it all began: the Intel 4004, world’s first widely-used microprocessor. The 4004 and most other antiquated chips differ from modern chips in two main characteristics: They only use a single type of transistor (PMOS or NMOS) and each logic gate is custom-designed to best utilize the available area — an inevitable optimization for chips built from transistors about 150x larger than those used in their modern descendants.

Each of the gates is composed of two transistors and one resistor. If either of the transistors is open (that is: having Vcc applied to its gate), the output is strongly connected to Vcc. If neither of the transistors is open, the gate is weakly connected to GND through the resistor, but still strong enough to pull the output to GND.

PMOS is very area-efficient, but more power hungry and slower than alternatives such as CMOS, which combines PMOS and NMOS transistors as illustrated in this post. It’s beautiful to see how none of the inefficiencies we see in modern chips are found on the 4004 and how the available space is completely filled with logic.

As a challenge for next time, identify the extra 3 layers that the Intel museum claims. Last episode’s challenge was correctly solved first by Jeri Ellsworth. Respect for her almost perfect circuit diagram as well as her remarkable on-your-kitchen-table semiconductors fab.

Credit for the chips go to Tim McNerney. Tim is an expert on the 4004 who has built an interactive exhibit of the chip for the Intel museum. For more information please visit the Intel 4004 35th anniversary project web site.

-Karsten Nohl