1/29/2014 Weekly Infosec Reactions

My ROP Chain Attempt

1/25/2014 Fuses for Pic18f4550

Microcontrollers are really awesome , they are everywhere  that's the reason why actually I'm working on a proyect that involves it. The market has a wide range of  manufacturers like Atmel, Microchip, Motorola among others in order to this I've chosen Microchip by his usability and his features between them :
memories(ROM , RAM, EEPROM), Ports, serial IO (input and output) devices, Timers and Interrupt sources, Adc converters, Comparator, Pwm modules and others.


Another thing to say is they are commonly know as PIC microcontrollers PIC or just  PICmicro. They  have a Harvard architecture, and instruction words are unusual sizes. Originally, 12-bit instructions included 5 address bits to specify the memory operand, and 9-bit branch destinations. Later revisions added opcode bits, allowing additional address bits.
Picmicro are divided in family based on the word assembly language instruction, varying from 8 ,16, 32 bits depending on the specific PIC.The family clasification can be found here :


http://www.microchip.com/pagehandler/en-us/products/picmicrocontrollers

Pic 18f4550:

Pic 18f4550 

When you're in a proyect you need to make the right choices and this pic is great it came with 32Kb of  flash memory and other nice features, here is a sumary of the most valuable:

•  IC, 8BIT FLASH MCU, 18F4550, PDIP40
•  Controller Family/Series: PIC18F4xxx
•  Program Memory Size: 32KB
•  RAM Memory Size: 2KB
•  CPU Speed: 48MHz
•  No. of I/O's: 35
•  Digital IC Case Style: DIP
•  No. of Pins: 40
•  Embedded Interface Type: EUSART, I2C, SPI, SPP, USB
•  Supply Voltage Min: 4.2V
•  Supply Voltage Max: 5.5V
•  MSL: -
•  SVHC: No SVHC (20-Jun-2013)
•  Core Size: 8bit
•  Device Marking: PIC18F4550-I/P
•  EEPROM Memory Size: 256Byte
•  Flash Memory Size: 32KB
•  IC Generic Number: 18F4550
•  IC Temperature Range: Industrial
•  Logic Function Number: 18F4550
•  Memory Type: Flash
•  Microprocessor/Controller Features: SPI, I²C, CCP, ECCP, SPP, EUSART, 2 x Comparators, 1 x 8-bit timer, 3 x 16-bit timer
•  No. of ADC Inputs: 13
•  No. of Bits: 8
•  No. of Internal Interrupts: 20
•  No. of PWM Channels: 5
•  No. of Timers: 4
•  Number of bits In Timer: 16
•  Number of bits in ADC: 10
•  Operating Temperature Max: 85°C
•  Operating Temperature Min: -40°C
•  Operating Temperature Range: -40°C to +85°C
•  Oscillator Type: External, Internal
•  Peripherals: ADC, Comparator, PWM, Timer

Fuses Pic 18f4550:

This part was taken from the avr tutorials its very well explained:

Fuses are an extremely important part programming a chip, but are rarely explained thoroughly. You only need to set them once, but if you don't do it right, it's a disaster!

What is a fuse?
You know about flash, eeprom and RAM as parts of the chip. What I did not mention is that there are also 3 bytes of permanent (by permanent I mean that they stick around after power goes out, but that you can change them as many times as you'd like) storage called the fuses. The fuses determine how the chip will act, whether it has a bootloader, what speed and voltage it likes to run at, etc. Note that despite being called 'fuses' they are re-settable and dont have anything to do with protection from overpowering (like the fuses in a home). 

As we can read in the quote above they're  necesary for a proper operation , the other thing is that when you're flashing out this chips they have a code protection fuses which if you activate this you won't be able to use the microcontroller again,because you're protecting  a session in rom memory.

Here are the fuses that I've been using this week, remember this is for a pickit 3 proper development , this will work with another programmer that has circuit debuger like icd and others.

just save this code as a fuses.h and include in your main.c  program.

#ifndef FUSES_H
#define FUSES_H

#ifdef __cplusplus
extern "C" {
#endif
//******************************************
//FUSES USADOS CON CRISTAL DE 20MHZ Y USO DE PROGRAMADOR PICKIT3,

#pragma config PLLDIV = 5       // (CRISTAL DE 20 MHz),Divide by 5 (20 MHz oscillator input)
#pragma config USBDIV = 2       //USB clock source comes from the 96 MHz PLL divided by 2
#pragma config CPUDIV=OSC1_PLL2 //Primary Oscillator Src/1][96 MHz PLL Src/2]  cpu trabajara a 48Mhz.
#pragma config FOSC = HSPLL_HS  //HS oscillator, PLL enabled (HSPLL)
#pragma config FCMEN = OFF      //Fail-Safe Clock Monitor disabled
#pragma config IESO = OFF       //Oscillator Switchover mode disabled
#pragma config PWRT = ON        //Power-up Timer Enable bit
#pragma config BOR = OFF        //Brown-out Reset Enable bits: Brown-out Reset
                                //enabled in hardware only (SBOREN is disabled)
#pragma config BORV = 0         //Brown-out Reset Voltage bits,Maximum.
#pragma config VREGEN = ON      // USB voltage regulator enabled
#pragma config WDT = OFF        //WDT disabled (control is placed on the SWDTEN bit)
#pragma config WDTPS = 32768    //Watchdog Timer Postscale Select bits>> 1:32768
#pragma config MCLRE = ON       //MCLR pin enabled; RE3 input pin disabled
#pragma config LPT1OSC = OFF    //Timer1 configured for higher power operation
#pragma config PBADEN = OFF     //PORTB<4:0> pins are configured as digital I/O on Reset
                                //If i need to use the RBx as analog in/out set this bit to ON
#pragma config STVREN = OFF     //Stack full/underflow will not cause Reset
#pragma config LVP = OFF        //PROGRAMACION EN BAJO VOLTAJE
#pragma config XINST = OFF      // Instruction set extension and Indexed Addressing mode enabled
                                //the above bit is used  enterely for debug program in circuit (ICPORT)
#pragma config CP0 = OFF        //Code Protection bit disable for 0,1,2
#pragma config CP1 = OFF        //
#pragma config CP2 = OFF        //
#pragma config CPB = OFF        //Boot Block Code Protection bit:
#pragma config CPD = OFF        //Data EEPROM Code Protection bit.
#pragma config WRT0 = OFF       //Write Protection bit for 0,1,2 is not write-protected
#pragma config WRT1 = OFF
#pragma config WRT2 = OFF
#pragma config WRTB = OFF       //PROTECCI?N DE ESCRITURA PARA EL BLOCK DE BOOT
#pragma config WRTC = OFF       //Configuration Register Write Protection bit,disable
#pragma config WRTD = OFF       //Data EEPROM Write Protection bit,is not write protected
#pragma config EBTR0 = OFF      //000800-001FFFh
#pragma config EBTR1 = OFF      //Boot Block Table Read Protection bit,disable between
#pragma config EBTRB = OFF      //000000-0007FFh and 002000-003FFFh
#pragma config CCP2MX = OFF
#pragma config DEBUG = ON       //ENABLE FOR PICKIT 3

//DISABBLE THE DEBUG OPTION WHEN You're going to do the proper deployment.

#ifdef __cplusplus
}
#endif
#endif /* FUSES_H */

1/15/2014 FWD: Security Risks of Embedded Systems

Microcontrollers and Chips are the main problem to update to the proper firmware 

We're at a crisis point now with regard to the security of embedded systems, where computing is embedded into the hardware itself -- as with the Internet of Things. These embedded computers are riddled with vulnerabilities, and there's no good way to patch them.

It's not unlike what happened in the mid-1990s, when the insecurity of personal computers was reaching crisis levels. Software and operating systems were riddled with security vulnerabilities, and there was no good way to patch them. Companies were trying to keep vulnerabilities secret, and not releasing security updates quickly. And when updates were released, it was hard -- if not impossible -- to get users to install them. This has changed over the past twenty years, due to a combination of full disclosure -- publishing vulnerabilities to force companies to issue patches quicker -- and automatic updates: automating the process of installing updates on users' computers. The results aren't perfect, but they're much better than ever before.

But this time the problem is much worse, because the world is different: All of these devices are connected to the Internet. The computers in our routers and modems are much more powerful than the PCs of the mid-1990s, and the Internet of Things will put computers into all sorts of consumer devices. The industries producing these devices are even less capable of fixing the problem than the PC and software industries were.

If we don't solve this soon, we're in for a security disaster as hackers figure out that it's easier to hack routers than computers. At a recent Def Con, a researcher looked at thirty home routers and broke into half of them -- including some of the most popular and common brands.

To understand the problem, you need to understand the embedded systems market.

Typically, these systems are powered by specialized computer chips made by companies such as Broadcom, Qualcomm, and Marvell. These chips are cheap, and the profit margins slim. Aside from price, the way the manufacturers differentiate themselves from each other is by features and bandwidth. They typically put a version of the Linux operating system onto the chips, as well as a bunch of other open-source and proprietary components and drivers. They do as little engineering as possible before shipping, and there's little incentive to update their "board support package" until absolutely necessary.

The system manufacturers -- usually original device manufacturers (ODMs) who often don't get their brand name on the finished product -- choose a chip based on price and features, and then build a router, server, or whatever. They don't do a lot of engineering, either. The brand-name company on the box may add a user interface and maybe some new features, make sure everything works, and they're done, too.

The problem with this process is that no one entity has any incentive, expertise, or even ability to patch the software once it's shipped. The chip manufacturer is busy shipping the next version of the chip, and the ODM is busy upgrading its product to work with this next chip. Maintaining the older chips and products just isn't a priority.

And the software is old, even when the device is new. For example, one survey of common home routers found that the software components were four to five years older than the device. The minimum age of the Linux operating system was four years. The minimum age of the Samba file system software: six years. They may have had all the security patches applied, but most likely not. No one has that job. Some of the components are so old that they're no longer being patched. This patching is especially important because security vulnerabilities are found "more easily" as systems age.

To make matters worse, it's often impossible to patch the software or upgrade the components to the latest version. Often, the complete source code isn't available. Yes, they'll have the source code to Linux and any other open-source components. But many of the device drivers and other components are just "binary blobs" -- no source code at all. That's the most pernicious part of the problem: No one can possibly patch code that's just binary.

Even when a patch is possible, it's rarely applied. Users usually have to manually download and install relevant patches. But since users never get alerted about security updates, and don't have the expertise to manually administer these devices, it doesn't happen. Sometimes the ISPs have the ability to remotely patch routers and modems, but this is also rare.

The result is hundreds of millions of devices that have been sitting on the Internet, unpatched and insecure, for the last five to ten years.

Hackers are starting to notice. Malware DNS Changer attacks home routers as well as computers. In Brazil, 4.5 million DSL routers were compromised for purposes of financial fraud. Last month, Symantec reported on a Linux worm that targets routers, cameras, and other embedded devices.

This is only the beginning. All it will take is some easy-to-use hacker tools for the script kiddies to get into the game.

And the Internet of Things will only make this problem worse, as the Internet -- as well as our homes and bodies -- becomes flooded with new embedded devices that will be equally poorly maintained and unpatchable. But routers and modems pose a particular problem, because they're: (1) between users and the Internet, so turning them off is increasingly not an option; (2) more powerful and more general in function than other embedded devices; (3) the one 24/7 computing device in the house, and are a natural place for lots of new features.

We were here before with personal computers, and we fixed the problem. But disclosing vulnerabilities in an effort to force vendors to fix the problem won't work the same way as with embedded systems. The last time, the problem was computers, ones mostly not connected to the Internet, and slow-spreading viruses. The scale is different today: more devices, more vulnerability, viruses spreading faster on the Internet, and less technical expertise on both the vendor and the user sides. Plus vulnerabilities that are impossible to patch.

Combine full function with lack of updates, add in a pernicious market dynamic that has inhibited updates and prevented anyone else from updating, and we have an incipient disaster in front of us. It's just a matter of when.

We simply have to fix this. We have to put pressure on embedded system vendors to design their systems better. We need open-source driver software -- no more binary blobs! -- so third-party vendors and ISPs can provide security tools and software updates for as long as the device is in use. We need automatic update mechanisms to ensure they get installed.

The economic incentives point to large ISPs as the driver for change. Whether they're to blame or not, the ISPs are the ones who get the service calls for crashes. They often have to send users new hardware because it's the only way to update a router or modem, and that can easily cost a year's worth of profit from that customer. This problem is only going to get worse, and more expensive. Paying the cost up front for better embedded systems is much cheaper than paying the costs of the resultant security disasters.

This essay originally appeared on Wired.com.
http://www.wired.com/opinion/2014/01/theres-no-good-way-to-patch-the-internet-of-things-and-thats-a-huge-problem/ or http://tinyurl.com/ngoxykw

Security vulnerabilities in routers:
https://www.defcon.org/images/defcon-18/dc-18-presentations/Heffner/DEFCON-18-Heffner-Routers.pdf or http://tinyurl.com/mycykl7

Security vulnerabilities of older systems:
http://www.acsac.org/2010/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=69&type=2 or http://tinyurl.com/l57yph8

Embedded malware:
http://news.cnet.com/8301-10784_3-9970972-7.html
http://nakedsecurity.sophos.com/2012/10/01/hacked-routers-brazil-vb2012/ or http://tinyurl.com/8js9jg2
http://www.symantec.com/connect/blogs/linux-worm-targeting-hidden-devices or http://tinyurl.com/ncwl6rr
http://arstechnica.com/security/2013/11/new-linux-worm-targets-routers-cameras-internet-of-things-devices/ or http://tinyurl.com/mcv73mj

Two essays that debunk the "NSA surveillance could have stopped 9/11" myth:
http://www.cnn.com/2013/12/30/opinion/bergen-nsa-surveillance-september-11/
http://www.newyorker.com/talk/comment/2014/01/13/140113taco_talk_wright

The changing cost of surveillance:
http://ashkansoltani.org/2014/01/09/the-cost-of-surveillance/
http://www.yalelawjournal.org/the-yale-law-journal-pocket-part/constitutional-law/tiny-constables-and-the-cost-of-surveillance:-making-cents-out-of-united-states-v.-jones

Source :
CRYPTO-GRAM, January 15, 2014