INSIGHTS | August 8, 2012

Impressions from Black Hat, Defcon, BSidesLV and IOAsis

A week has passed since the Las Vegas craziness and we’ve had some time to write down our impressions about the Black Hat, Defcon and BSidesLV conferences as well as our own IOAsis event.

It was great for me to meet lots of people—some of who I only see once a year in Las Vegas. I think this is one of the great things about these events: being able to talk for at least a couple of minutes with colleagues and friends you don’t see regularly (the Vegas craziness doesn’t allow long chats most of the time). I also got to meet people personally for the first time after working together and/or communicating just by email, Twitter, or chat. The IOActive team delivered a lot of successful talks that were well received by the public, which makes me proud of our great team and reflects well our constant hard work.

By Fernando Anaboldi

 

Fwknop at IOAsis:

The “Single Packet Authorization” term was first mentioned by MadHat at the BlackHat Briefings in July 2005; however, the first available implementation of SPA was the release of fwknop in May 2005 by Michael Rash. Basically, it grants access to a service upon receiving a particular packet.

We had the opportunity at the IOAsis to attend a fwknop presentation given by Michael Rash. The tool is currently capable of performing several useful things:

·         It allows you to hide a service on a “closed” port.
·         It lets you create a “ghost service” where a port switches for a short period of time to whatever service is requested within an SPA packet (e.g. SSHD)—and it doesn’t seem to be susceptible to replay attacks like a normal port knocking implementation would.
·         And the list goes on.

 

Hidden and obscuring available services on external networks looks like a first interesting line of defense, and fwknop seems to be the leader in that field.

 

By Ian Amit @iiamit

 

BlackHat/BSides/Defcon Week: Finding My Peace

 

After finally recovering from a week (which felt like a month) in Vegas, I can safely say that I found my peace. Although it was one of the more hectic weeks I’ve had this year—and the most successful BlackHat/BSides/Defcon personally—I managed to find myself in a better place professionally, socially, and generally. How did this come about?

 

Although BlackHat has been wandering the past few years between what it used to be—a highly professional security conference—and what it started to become (for me at least)—a vendor dog-and-pony show—I thought the new format of tracks focused on different security elements made a difference in how attendees approached the topics. Additionally, the arsenal pods allowed more free-form presentations and discussions on new technologies and ideas while capitalizing on the hallway-track that conferences so famously miss out on.

 

My schedule really put me in a position to appreciate the entire spectrum of our amazing community: speaking at BlackHat first thing in the morning after the keynote, switching gears to volunteer for the security staff at BSidesLV, and then speaking at BSides. From the more polished feel of BlackHat to the relaxed atmosphere of BSides, from a stressful speaking slot to giving back to the community, it just made perfect sense…

 

Having a chance to get together with people I consider friends online and offline was another critical aspect of my week in Vegas. Although some of these meetings were ridiculously short, the energy, and the relationship boost they gave was invaluable. A critical part of being in information security is the ability to work with industry peers in ways that nurture critical thinking, innovation, and peer-support (and criticism). Being able to throw around research initiatives; explore new elements of the information security world; and talk about business, government, international relations, law, economics, physical security, and other crazy aspects that we all need to take into account is a must-have in an industry that has almost zero-tolerance for failure.

 

Wrapping it up with a massive Defcon attendance, talks, and of course the occasional party was the cherry on top. Although some nights felt more like work than play, you won’t hear me complaining because even though party hopping between 4–5 venues to catch up with everyone really took its toll physically, I got to see a beautiful sunrise over the desert.

 

Last but definitely not least, getting the chance to meet with co-workers from around the globe was a great experience made possible by working for a company large enough to have people in almost every time zone. So, being able to do that against the backdrop of an amazing Freakshow party (thanks again to Keith Myers and Infected Mushroom) just made all the talks about exploits, kernel space vulnerabilities, counter-intelligence, and social engineering that much more appropriate ?

 

Until the next Vegas, stay safe!
INSIGHTS | July 19, 2012

IOActive Las Vegas 2012

That time of the year is quickly approaching and there will be nothing but great talks and enjoyment. As a leading security and research company, IOActive will be sharing a lot of our latest research at BlackHat USA 2012, BSidesLV 2012, and IOAsis.  And, of course, we’ll also be offering some relaxation and party opportunities, too!

This year we are proud to be one of the companies with more talks accepted than anyone else at BlackHat USA 2012, an incredible showing that backs up our team’s hard work:
·         SEXY DEFENSE – MAXIMIZING THE HOME-FIELD ADVANTAGE, by Iftach Ian Amit
·     EASY LOCAL WINDOWS KERNEL EXPLOITATION, by Cesar Cerrudo
·     THE LAST GASP OF THE INDUSTRIAL AIR-GAP, by Eireann Leverett
·     HERE BE BACKDOORS: A JOURNEY INTO THE SECRETS OF INDUSTRIAL FIRMWARE, by Ruben Santamarta
We also will be showing interesting tools at BlackHat Arsenal:
·         BURP EXTENSIBILITY SUITE by James Lester and Joseph Tartaro
…and we will be presenting at BSidesLV 2012, too:
·         SEXY DEFENSE – MAXIMIZING THE HOME-FIELD ADVANTAGE, by Iftach Ian Amit
·         OCCUPY BURP SUITE: Informing the 99% What the 1% are Taking Advantage Of, by James Lester and Joseph Tartaro
But wait, that’s not all—at same time as BlackHat and BSidesLV we will be running IOAsis, where VIPs can meet with our team and also attend exclusive talks, where our team will present their latest research. 
Enough already? No, there’s still more. For the second year IOActive will be sponsoring BarCon, an exclusive, invitation-only event where the great hacking minds get together to talk about who knows what. And to drink. 
And last, but certainly not least, IOActive will present the fifth annual Defcon Freakshow, the freakiest party for celebrating Defcon 20!  More information is available on the Facebook page: http://www.facebook.com/events/409482889093061/

 

If you are not tired of reading yet, continue and find more information about our talks at BlackHat USA 2012 and BSidesLV 2012:

 HERE BE BACKDOORS: A JOURNEY INTO THE SECRETS OF INDUSTRIAL FIRMWARE, by Ruben Santamarta
July 25, 2012. 5:00–6:00pm. BlackHat USA 2012

PLCs, smart meters, SCADA, Industrial Control Systems…nowadays all those terms are well known for the security industry. When critical Infrastructures come into play, the security of all those systems and devices that control refineries, and water treatment or nuclear plants pose a significant attack vector.

For years, the isolation of that world provided the best ‘defense’ but things are changing and that scenario is no longer valid. Is it feasible to attack a power plant without ever visiting one? Is it possible to hack into a smart meter…without having that smart meter? Yes, it is. This talk discusses the approach followed to do so, mixing theory and practice.

This presentation pivots around the analysis of firmware through reverse engineering in order to discover additional scenarios such as backdoors, confidential documentation or software, and vulnerabilities. Everything explained will be based on real cases, unveiling curious ‘features’ found in industrial devices and disclosing some previously unknown details of an interesting case: a backdoor discovered in a family of smart meters.

We will navigate through the dark waters of Industrial Control Systems, where security by obscurity has ruled for years. Join us on this journey, here be backdoors…

THE LAST GASP OF THE INDUSTRIAL AIR-GAP, by Eireann Leverett
July 25, 2012. 2:15–3:15pm. BlackHat USA 2012

Industrial systems are widely believed to be air-gapped. At previous Black Hat conferences, people have demonstrated individual utilities control systems directly connected to the internet. However, this is not an isolated incident of failure, but rather a disturbing trend. By visualizing results from SHODAN over a 2-1/2–year period, we can see that there are thousands of exposed systems around the world. By using geo-location and vulnerability pattern matching to service banners, we can see their rough physical location and the numbers of standard vulnerabilities they are exposed to.

This allows us to look at statistics about the industrial system security posture of whole nations and regions. During the process of this project, I worked with ICS-CERT to inform asset-owners of their exposure and other CERT teams around the world. The project has reached out to 63 countries, and sparked discussion of convergence toward the public internet of many insecure protocols and devices.
The original dissertation can be found here:  https://www.ioactive.com/wp-content/uploads/2012/07/2011-Leverett-industrial.pdf

EASY LOCAL WINDOWS KERNEL EXPLOITATION, by Cesar Cerrudo
July 26, 2012. 5:00–6:00pm BlackHat USA 2012

For some common local kernel vulnerabilities there is no general, multi-version, reliable way to exploit them. While there have been interesting techniques published, they are neither simple nor do they work across different Windows versions most of the time. This presentation will show easy and reliable cross-platform techniques for exploiting some common local Windows kernel vulnerabilities. These new techniques even allow exploitation of vulnerabilities that have been considered difficult or almost impossible to exploit in the past.

SEXY DEFENSE – MAXIMIZING THE HOME-FIELD ADVANTAGE, by Iftach Ian Amit
July 25, 2012. 10:15–11:15am.BlackHat USA 2012
July 25, 2012. 5:00–6:00 pm. BSidesLV 2012

Offensive talks are easy, I know. But the goal of offensive security at the end of the day is to make us better defenders. And that’s hard. After the penetration testers (or worse, the red team) leaves, there’s usually a whole lot of vulnerabilities, exposures, threats, risks and wounded egos. Now comes the money time—can you fix this so your security posture will actually be better the next time these guys come around?

This talk focuses mainly on what should be done, not what should be BOUGHT—you probably have most of what you need already in place and you just don’t know it yet.
The talk will show how to expand the spectrum of defenders from a reactive one to a proactive one, will discuss ways to perform intelligence gathering on your opponents, and will model how that can assist in focusing on an effective defense rather than a “best practice” one. Methodically, defensively, decisively. The red team can play ball cross-court, so should you!

BURP EXTENSIBILITY SUITE, by James Lester and Joseph Tartaro
July 25, 2012. 3:30–4:30 pm BlackHat USA 2012 – Arsenal

Whether it be several Class B Subnets, a custom web application utilizing tokenization, or the integration of third-party detection/exploitation software, there comes a time when your go-to testing application is insufficient as is. With Burp Suite Extensibility you can push these requirements to the next level by building functionality that allows you to perform your required task while maintaining efficiency, value, and, most of all, detection/exploitation of the specified target. Several extensions along with a common extensibility framework will be on display to demonstrate its ability, adaptation, and ease of use while still reaching your testing requirements. Along with the demonstration, these extensions will be released to the public during the week of BlackHat to encourage further development and extensibility participation.

OCCUPY BURP SUITE: Informing the 99% What the 1% are Taking Advantage Of, by James Lester and Joseph Tartaro
July 26, 2012. 3:00–4:00 pm BSidesLV 2012

In this presentation, James Lester and Joseph Tartaro will focus on building demand, support, and an overall desire around the creation of Burp Suite extensions with the hope of bringing extensibility to the forefront of web application testing. Lester and Tartaro will introduce up to a dozen extensions they’ve created that utilize currently-accessible functionality within the extensibility suite. Along with the release of these extensions, a campaign will be presented to organize and develop an extension community that documents tool primers, lessons learned, and tips/tricks; and hosts extensions and tools catered to Burp. Something learned isn’t research until it’s shared—putting this statement into practice, the duo believes that BSides is the perfect environment to help collect data, convey interests, and share results.
INSIGHTS | July 16, 2012

The Value of Data

Have you ever entered an office and seen a pile of money sitting unattended and easily accessible on a desk? How many people in your company have a key or combination to a safe with money inside and can open that safe without any controls? Do you leave money in a non-secure place that everyone knows about and can freely access?

Your probable answer to all these questions is NO, which makes sense—what doesn’t make sense is how so many companies don’t think the same way about data. I think data is worth a lot of money if you consider how important it is in terms of cost to the company: cost when it’s stolen, cost when it’s not available, et cetera. Data deserves to be protected as if it were money, but most of it is freely available by way of corporate databases; once you access the database you can play with the data at will, bypassing only modest controls or restrictions.
Of course you need a username and password to make the initial connection or exploit a SQL injection vulnerability (for example), but we all know it’s not that difficult to get access, as shown by recent events. A lot of user passwords have been leaked, obtained from successfully-hacked companies that apparently didn’t protect their data properly and, as a result, put their business at serious risk.
The main cause of data breaches is an improperly-secured database. Unfortunately, when it comes to database security, most companies are ages away from doing it properly.
For example, if the statement used to access a table is always:
Select * from user_accounts where user_email = X
why would you let anyone execute the next SQL statement:
Select * from user_accounts
Why not use stored procedures exclusively and remove all direct access to tables? Why not set alerts to trigger when common SQL injection-related errors occur? Why not monitor the database in real time to detect suspicious activities? Why not create a table named “important_data_is_here” and fire all the alarms when someone tries to access it?
Database servers don’t have advanced security features, but there are numerous third-party solutions that do—Database Activity Monitoring (DAM: a kind of database IPS) being one example—and a very small percentage of companies are using them. This isn’t just about using a DAM product (which won’t solve all your problems anyway), but it does provide a good start, allowing you to know in “real time” whether someone is digging around and playing with your databases.  
If you don’t want to spend money on third-party solutions, there are ways to do customized DAM builds using database-provided functionality that involves creating alerts on specific actions, setting custom permissions on different database objects, monitoring and analyzing logs, creating a database honeypot and querying and analyzing system tables; however, when you have dozens (or hundreds) of databases, the difficulty level increases quickly and you’ll need to have database security-wise personnel in place.
I’ve researched database security for more than 10 years and have seen database software vendors seriously improve the security of their products, but I have yet to see noticeable improvements at the company level—as indicated by all the breaches we know and don’t know about—corporations still don’t seem to get that data is money.
INSIGHTS | June 28, 2012

Inside Flame: You Say Shell32, I Say MSSECMGR

When I was reading the CrySyS report on Flame (sKyWIper)[1], one paragraph, in particular, caught my attention:
 
In case of sKyWIper, the code injection mechanism is stealthier such that the presence of the code injection cannot be determined by conventional methods such as listing the modules of the corresponding system processes (winlogon, services, explorer). The only trace we found at the first sight is that certain memory regions are mapped with the suspicious READ, WRITE and EXECUTE protection flags, and they can only be grasped via the Virtual Address Descriptor (VAD) kernel data structure
 
So I decided to take a look and see what kind of methods Flame was using.
Flame is conceived to gather as much information as possible within heterogeneous environments that can be protected by different solutions, isolated at certain levels, and operated upon by different profiles. Which means that, from the developers point of view, you can’t assume anything and should be prepared for everything.
Some of the tricks implemented in Flame seem to focus on bypass just as much AV products, specifically in terms of heuristics. A distributed “setup” functionality through three different processes (winlogon, explorer, and services ) is way more confusing than letting a unique, trusted process do the job; i.e. it’s less suspicious to detect Internet Explorer coming from explorer.exe than winlogon.
In essence, the injection method seems to pivot around the following three key features:
·         Disguise the malicious module as a legitimate one; Shell32.dll in this case.
·         Bypass common registration methods supplied by the operating system, such as LoadLibrary, to avoid being detected as an active module.
·         Achieve the same functionality as a correctly-registered module.
 
So, let’s see how Flame implements it.
During the initial infection when DDEnumCallback is called, Flame injects a blob and creates a remote thread in Services.exe. The blob has the following structure:
 
The loader stub is a function that performs the functionality previously described: basically a custom PE loader that’s similar to the CryptoPP dllloader.cpp[2] with some additional tricks.
 

The injection context is a defined structure that contains all the information the loader stub may need including API addresses or names, DLL names, and files—in fact, the overall idea reminded me of Didier Stevens’ approach to generating shellcodes directly from a C compiler[3]

Injection Context: Blob + 0x710

 
 
 

API Addresses:

esi             OpenMutexW
esi+4        VirtualAlloc
esi+8        VirtualFree
esi+0Ch   VirtualProtect
esi+10h    LoadLibraryA
esi+14h    LoadLibraryW
esi+18h    GetModuleHandleA
esi+1Ch   GetProcAddress
esi+20h    memcpy
esi+24h    memset
esi+28h    CreateFileMappingW
esi+2Ch   OpenFileMappingW
esi+30h    MapViewOfFile
esi+34h    UnmapViewOfFile
esi+38h    ReleaseMutex
esi+3Ch   NtQueryInformationProcess
esi+40h    GetLastError
esi+44h    CreateMutexW
esi+48h    WaitForSingleObject
esi+4Ch   CloseHandle
esi+50h    CreateFileW
esi+54h    FreeLibrary
esi+58h    Sleep
esi+5Ch   LocalFree
The loader stub also contains some interesting tricks.

 

Shell32.dll:  A matter of VAD

To conceal its own module, Flame hides itself behind Shell32.dll, which is one of the largest DLLs you can find on any Windows system, meaning it’s large enough to hold Flame across different versions.
 
 
 
Once shell32.dll has been mapped, a VAD node is created that contains a reference to the FILE_OBJECT, which points to Shell32.dll. Flame then zeroes that memory and loads its malicious module through the custom PE loader, copying sections, adjusting permissions, and fixing relocations.
 
 
 
As a result, those forensics/AntiMalware/AV engines walking the VAD tree to discover hidden DLLs (and not checking images) would be bypassed since they assume that memory belongs to Shell32.dll, a trusted module, when it’s actually mssecmgr.ocx.
The stub then calls to DllEntryPoint, passing in DLL_PROCESS_ATTACH to initialize the DLL.
 
 
 
The malicious DLL currently has been initialized, but remember it isn’t registered properly, so cannot receive remaining events such as DLL_THREAD_ATTACH, DLL_THREAD_DETACH, and DLL_PROCESS_DETACH.
And here comes  the final trick:
 
 
 
The msvcrt.dll is loaded up to five times, which is a little bit weird, no?
Then the PEB InLoadOrder structure is traversed to find the entry that corresponds to msvcrt.dll by comparing the DLL base addresses:
 
 
 
Once found, Flame hooks this entry point:
 
 
 
InjectedBlock1 (0x101C36A1) is a small piece of code that basically dispatches the events received to both the malicious DLL and the original module.
The system uses this entry point to dispatch events to all the DLLs loaded in the process; as a result, by hooking into it Flame’s main module achieves the goal of receiving all the events other DLLs receive. Therefore, it can complete synchronization tasks and behaves as any other DLL. Neat.
I assume that Flame loads msvcrt.dll several times to increase its reference count to prevent msvcrt.dll from being unloaded, since this hook would then become useless.
See you in the next post!
INSIGHTS |

Thoughts on FIRST Conference 2012

I recently had the opportunity to attend the FIRST Conference in Malta and meet Computer Emergency Response Teams from around the world. Some of these teams and I have been working together to reduce the internet exposure of Industrial Control Systems, and I met new teams who are interested in the data I share. For those of you who do not work with CERTs, FIRST is the glue that holds together the international collaborative efforts of these teams—they serve as both an organization that makes trusted introductions, and vets new teams or researchers (such as myself).

It was quite an honor to present a talk to this audience of 500 people from strong technical teams around the world. However, the purpose of this post is not my presentation, but rather to focus on all of the other great content that can be found in such forums. While it is impossible to mention all the presentations I saw in one blog post, I’d like to highlight a few.
A session from ENISA and RAND focused on the technical and legal barriers to international collaboration between National CERTS in Europe. I’m interested in this because during the process of sharing my research with various CERTs, I have come to understand they aren’t equal, they’re interested in different types of information, and they operate within different legal frameworks. For example, in some European countries an IP address is considered private information and will not be accepted in incident reports from other teams. Dr. Silvia Portesi and Neil Robinson covered a great wealth of this material type in their presentation and report, which can be found at the following location:
In the United Kingdom, this problem has been analyzed by Andrew Cormack, Chief Regulatory Advisor at Janet. If I recall correctly, our privacy model is far more usable in this respect  and Andrew explained it to me like this:
If an organization cannot handle private data to help protect privacy (which is part of its mission), then we are inhibiting the mission of the organization with our interpretation of the law.
This is relevant to any security researcher who works within incident response frameworks in Europe and who takes a global view of security problems.
Unfortunately, by attending this talk—which was directly relevant to my work—I had to miss a talk by Eldar Lillevik and Marie Moe of the NorCERT team. I had wanted to meet with them regarding some data I shared months ago while working in Norway. Luckily, I bumped into them later and they kindly shared the details I had missed; they also spent some of their valuable time helping me improve my own reporting capabilities for CERTs and correcting some of my misunderstandings. They are incredibly knowledgeable people, and I thank them for both their time and their patience with my questions.
Of course, I also met with the usual suspects in ICS/Smart Grid/SCADA security: ICS-CERT and Siemens. ICS-CERT was there to present on what has been an extraordinary year in ICS incident response. Of note, Siemens operates the only corporate incident response team in the ICS arena that’s devoted to their own products. We collectively shared information and renewed commitments to progress the ICS agenda in Incident Response by continuing international collaboration and research. I understand that GE-CIRT was there too, and apparently they presented on models of Incident Response.
Google Incident Response gave some excellent presentations on detecting and preventing data exfiltration, and network defense. This team impressed me greatly: they presented as technically-savvy, capable defenders who are actively pursuing new forensic techniques. They demonstrated clearly their operational maturity: no longer playing with “models,” they are committed to holistic operational security and aggressive defense.
Austrian CERT delivered a very good presentation on handling Critical Infrastructure Information Protection that focused on the Incident Response approach to critical infrastructure. This is a difficult area to work in because standard forensic approaches in some countries—such as seizing a server used in a crime—aren’t appropriate in control system environments. We met later to talk over dinner and I look forward to working with them again.
Finally, I performed a simple but important function of my own work, which comprises meeting people face-to-face and verifying their identities. This includes our mutually signing crypto-keys, which allows us to find and identify other trusted researchers in case of an emergency. Now that SCADA security is a global problem, I believe it’s incredibly important (and useful) to have contacts around the world with which IOActive already shares a secure channel
INSIGHTS | June 13, 2012

Old Tricks, New Targets

Just a few days ago, Digitalbond announced that they had been victims of a spear phishing attack. An employee received an email linking to a malicious zip file, posing as a legitimate .pdf paper related to industrial control systems security. Therefore, the bait used by the attackers was supposedly attracting targets somehow involved with the ICS community. (more…)

INSIGHTS | June 6, 2012

Summercon 2012

Hi Everyone,
Chris Valasek guest blogging here at IOActive. I just wanted to tell everyone a little bit about my involvement with Summercon and what to expect at the conference. Although I’m one of the current organizers (along with Mark Trumpbour @mtrumpbour), I’m obviously not the originator, as it started many years back (1987, I believe) as detailed in the most recent Phrack magazine.


 I started attending in 2000 when it was in Atlanta, GA and had a fantastic time. Over the years, the conference has changed and organizational efforts have varied, as running a conference is quite subjective and provides little utility (at times). Around 2006, the changing of the guard happened once again, leaving Mark and me the new organizers of the con. Like others that came before us, we put our own touch on the conference and have probably strayed further from the original than any before us.

 

While the talks are still the main attraction, the ability to meet people and have a good time is really what we want it to be all about. Many of us live in a world without much social interaction. The purpose of Summercon, in my opinion, is to provide an event that promotes social interaction of people with similar but varying backgrounds. If you really want to learn about the material being presented on, then you will take the time to review the content and figure out its purpose after the presentation. The ability to talk to others about your ideas and thoughts, regardless of their relevance to computer security, is the main benefit of gathering in a centralized location.

 

With that being said, I really do think we have a fantastic line-up of speakers this year that will promote stimulating conversation throughout the weekend (https://www.summercon.org/). Whether you’re interested in Android hacking, instrumentation, or reverse engineering, I think you’ll be happy with the speakers this year (and every year for that matter!).

 

Lastly, I’d like to talk a bit about sponsorship. Although we feel that we had to ‘sell-out’ a bit by acquiring sponsors, it does facilitate having many more people attend and present at Summercon. I want to remind everyone that we’re not out to make a profit, but to throw the best party we can. By having sponsors, such as IOActive, we can ensure that speakers don’t have to pay their own way and attendees can have a blast learning something while making new friends.

 

        cv
P.S. We have big plans for next year, so follow @SummerC0n on twitter for more information.
INSIGHTS | May 24, 2012

QR Fuzzing Fun

QR codes [1] have become quite popular due to their fast readability and large storage capacity to send information. It is very easy to find QR codes anywhere these days with encoded information such as a URL, phone number, vCard information, etc. There exist tons of apps on smartphones that are able to read / scan QR codes.

 
 
The table below shows some of the most common apps and libraries for the major mobile platforms – keep in mind that there are many more apps than listed here.
 
Platform
Popular QR Apps / Libraries
Android
·       Google Goggles
·       ZXing
·       QRDroid
iOS
·       Zxing
·       Zbar
BlackBerry
·       App World
Windows Phone
·       Bing Search App
·       ZXlib

QR codes are very interesting for attackers as they can store large quantity of information, from under 1000 up to 7000 characters, perfect for a malicious payload, and QR codes can be encrypted and used for security purposes. There are malicious QR codes that abuse permissive apps permissions to compromise system and user data. This attack is known as “attagging”. Also QR codes can be used as an attack vector for DoS, SQL Injection, Cross-Site Scripting (XSS) and information stealing attacks among others.
 
I have been pentesting Apps that supported QR codes lately, so I thought will be a good idea to fuzz this feature looking for bugs. I developed a tool for QR fuzzing called IOAQRF (beta phase) that is quite easy to use and modify as well in case you need to add something else.

This tool is composed of two files: a Python file that generates QR fuzz patterns and a shell script that can be used to generate common QR code content that apps use, such as phone numbers, SMS, and URLs. Previous work has been done on this field [2] [3] but more can be researched for sure! Enjoy the fuzzing!
 
 
Links
 
 
IOAQRF directory output
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Opening index.html with fuzz QR codes
 
INSIGHTS | May 22, 2012

ST19XL18P – K5F0A Teardown

4 Metal, 350 nanometer fabrication process, EAL4+ smart card.  A device fabricated in 2002 and yet, today the latest ST19W/N series only main differences are the ROM data bus output width into the decrypt block and the fabrication process (180nm and 150nm shrink).

The device was dipped into a HydroFluoric (HF) bath until the active shielding fell off.  The result of this saved about 10 minutes of polishing to remove the surface oxide and Metal 4 (M4).  This also helps begin the polishing process on the lower layers fairly evenly.

The oxide thickness of a layer once the passivation oxide is removed requires less than 2 minutes per layer to remove.  We purposely stop just before the Metal 3 (M3) surface is exposed leaving the vias visibly clear (there are several gates tied to the ground of the mesh on Metal 4 (M4) as well as the active shield’s begin and end vias.

The device was very modularly placed n’ routed.  The MAP consists of asymmetric and symmetric crypto functions (DES, RSA, etc).
The EEPROM control logic is actually in the lower left corner of the EEPROM block.

As Metal 3 (M3) was removed exposing the M2 layer, the device is beginning to not look so complicated.

Metal 1 (M1) shows us all the transistors.  We did not polish down to the poly.  Most of the gates are understandable without it for the purposes of finding the clear data bus.

Most likely, these NVM areas in Figure 7 & 8 are trimming or security violation related.  No further investigation is planned on these areas (it isn’t necessary).

Strangely enough, it is now understandable why ST cannot achieve high performance on the ST19 platform.  Each logic area with access to the clear data bus runs via a high-output driver that is tri-stated (hi-z) when not driven.  This means that all drivers are OR-tied and only one set of 8 drivers are ever active at a time.  This is a very large and cumbersome way of creating a MUX.
As time permits, the ST19W and ST19N series will be looked at.  It is expected to again find this kind of pattern.  Overall, finding the clear data bus took 1.5 hours once the images were created.  Most of the 1.5 hours was the alignment of the layers.