3870 items (0 unread) in 69 feeds
Tomorrow I’m headed to the Fat Boy Slim Concert at Hyde Park in London.
Sunday, I’d like to go to the Wimbledon Mens Finals. If you’ve always wanted to meet me and happen to have extra tickets, now’s your chance.
Google’s Homepage Now Links to Privacy Policy.
Why? It’s not like someone is raping them on some bull shit Quality Score factor. . .
About a month ago I traveled by train for a pre-sales meeting with a prospective customer. The trip was about two hours long, which would usually mean that it’d be boring. In this case it was different though: I was surprised with free OWI (Onboard Wireless Internet) on the train!
Simply connect to the available open (no encryption) wireless access point and you will be redirected to a login portal, aka captive portal. Just like any hotspot you find at coffee shops such as Starbucks. However, I was very pleased to find out that users could login as a “guest” which means that all passengers could go online without paying any additional fee!
Just to make things clear, going online as a guest was a legitimate form of access provided, as opposed to bypassing the security of the captive portal. NO illegal cracking (i.e.: SQL injection without permission) was done whatsoever!
Kudos to the train company that provides the service! The connection wasn’t super fast, but fast enough to be able to check my email, read the news, update my RSS feeds, chat with my buddies, etc … It was quite reliable though, which is a big plus as I hate being disconnected while I’m on-line (it reminds me of the old days of dial-up Internet access).
A bit of enumeration 101 led me to learn that:
From a security point of view, this technology adds another “anonymous” point of attack to the already-large list. I say “anonymous” (within quotation marks) because there is no such thing as truly anonymous connectivity. However, one thing is true: if the bad guy knows what he is doing, it becomes unfeasible to track the point of attack and the attacker’s identity. i.e.: it’s not worth starting an investigation if the committed crime didn’t lead to a serious profit loss.
From the top of my head, these are some anonymous points of attack that come to mind:
X-Forwarded-For), there are plenty of sites that check for proxy-added headers that give away the original source IP address
Although there are tons of ways for attackers to hide their location and identity, somehow I find OWI more scary than most of them. It’s scary because the attacker is always on the move, which might make tracking his location more difficult due to time correlation issues when comparing logs.
I know what you’re thinking: how is this different to the attacker using a stolen 3G Internet card? After all, using a 3G card would also allow the attacker to be constantly changing his geographical location (i.e.: by being inside a moving vehicle). Well, that’s a good point. However, in the case of using OWI the attacker doesn’t need to steal any equipment.
If you think that being on a fast train won’t make tracking the location of the bad guy when a break-in occurs hard enough, how about doing it on a plane at 800 kmph? Yes, that’s right: free Onboard Wireless Internet aka In-flight wireless internet access, will most likely become very common in the future, which adds another anonymous point of attack to our list. Oh dear, remote Internet break-ins from planes, that’s gonna be fun!
According to Microsoft's MSRC Advance Notification, there are four patches that Windows users should expect to be released next week as part of July's scheduled Security Patch release.
All four of the proposed patches are listed as Important, and they affect core elements of Windows, SQL Server, and Exchange Server. The worst case possible from exploitation of the vulnerabilities would be remote code execution, with most only being elevation of privilege or spoofing.
The Windows Malicious Software Removal Tool will also be updated and several high-priority non-security updates will also be released through Windows Update and Windows Server Update Service.
Microsoft have also indicated that later this month they will release an update to Windows Update itself.
360desktop just launched the public beta in conjunction with the 4th of July. If you haven’t heard about 360desktop, here is a quick overview from the site:
360desktop is a free and safe software download, that transforms your standard Windows® desktop into a 360-degree panoramic workspace, giving you many times more desktop space.
Quick video demo:
30desktop runs on Windows XP and Vista. Download the public beta from the 360desktop site. Don’t forget to let us know what you think.
I am currently giving it a spin and I can tell you this much - it don’t do doodoo next to compiz-fusion on Linux.
The next STLSec is July 10 @ the Fox and Hound. Be there or be square.
We had a great crowd our second time out, about 15-20 folks, roughly the same as the first one, with a number of new faces. That’s VERY impressive considering that CITYSec groups in cities three times our size get less turnout than that… Cool, huh?
If you haven’t came out yet, please do. CitySec is what you make it, so drop by, have a few beers and help us all figure out why we’re all crazy enough to do this crap for a living. Plus, beer. I mentioned that, right?
Directions, as always, at http://www.stlsec.org
LinkedIn. STLSec, NYSEC and CHISEC all have LinkedIn groups.
Twitter. Matasano has a corp. twitter account. How could you not want to see us have to communicate in 140 characters or less?!
Finally, if you are in the US, enjoy the long weekend. If you aren’t, enjoy the normal weekend.
Almost 2 years ago, Dino declared Python to be the “lingua-franca of over-the-hill hackers”, boldly asserting that 5 out of 6 security hackers under the age of 30 preferred Ruby instead. Being 30 at the time, I was an easy psychological target for this argument. I made the switch and haven’t regretted it. You can tell me all you want that “named nested functions are just as good as lambdas”, or that “you can fake Ruby blocks with a for loop and a generator”. Ruby is just nicer to write testing code in, and makes me feel at least 2 years younger and less experienced than I really am. Thanks, Ruby!
I’ve been meaning to write a long post about our house Ruby style, and some of the Ruby tips and tricks we’ve picked up along the way. But every time I sit down to write it, that post starts sounding a lot like work. So instead, I’d like to inaugurate a new series of much easier posts: Ruby for Pen-testers.
Where was I?
1. Use Modules For Lists Of ConstantsIf you test protocols or C code, you run into lists of magic numbers all the time. For example, here’s a bit of ptrace(2):
#define PT_TRACE_ME 0 /* child declares it’s being traced */This is gross, but it’s C code, so you give them a break. But here’s some code from Pedram’s PyDbg:
TH32CS_SNAPHEAPLIST = 0x00000001Now, Pedram does have the excuse of writing in Python. But here’s Ruby-MySql:
COM_SLEEP = 0This code has no excuse. (Here’s a rewrite that is much faster). Now, let’s look at net-ssh; if you haven’t read Jamis’ net-ssh code, you shouldn’t write any more packet processing code until you do.
module ConstantsGetting closer. But not there yet. Here’s an even better way:
module EFlagsThat’s right: one module per set of constants. In other words, substitute “module” for “enum”. This has many benefits:
It’s clean. You can immediately find all the related magic numbers, both from the list, and by looking at code that uses the magic numbers —- you see Ragweed::EFlags::CARRY, you know to look for “EFlags”.
Modules come with special bonus features.
For instance:
class Module… which is super nice when you’re printing out the contents of packets.
Along with OWASP's AppSec conferences, MetriCon is at the top of my list of conferences. MetriCon brings together people with varied background and a common interest in making security more objective and measurable. This year's conference chair is Dan Geer and the agenda and speakers looks like the best yet. MetriCon 3.0 is July 29 in San Jose, along with the Usenix Security conference.
Here is my current list of talks and training
I gave a version of this talk with Brian Chess at the 2008 RSA Conference.
A couple weekends ago we experienced a pair of glider extremes at Hollister on Saturday: one very short flight and one very long flight.
The short one, unfortunately, was us. Kathleen and I headed down to fly the BASA Grob 103 on what was predicted to be an epic soaring day. And it was. Unfortunately, we got there a bit late and the weather had already developed quite a bit more than we expected.
We towed toward the east hills and got off around 6,000 feet in what seemed like decent lift. But it was hard to stay with it and the high clouds from over-development in the Santa Cruz Mountains were quickly spreading. That blocked out the majority of sunlight and shut down most of the lift. We quickly went from "wow, this is going to be a good day" to "gee, let's see if we can find enough lift to keep from having to land soon."
Before long, we were getting low and had to head back to the airport. But there was one big a problem. A wall of clouds and rain was approaching from the west and brought a wall of dust on the ground to match. There was a very visible gust front headed directly toward the airport. Folks on the radio were advising pilots to stay away because of the 30 knot crosswind.
We were getting so low at that point that I didn't like the idea of flying back through possible sink and a definite headwind just to land at an unsafe airport. Luckily we were just a few miles from the private Christensen airport, so I put the nose down and headed straight to the runway at maneuvering speed (Va). No pattern. I knew where the wind was and decided to land downhill but into the wind.
All the the while, we were watching lightning strikes in the Santa Cruz Mountains from the approaching storm--some of which started a few of the 1,000+ wild fires that have burned so much of the California countryside.
Anyway, before long we were on the ground and sitting in the glider while the storms passed. And after the fun passed, I got on the phone to call for a retrieve.
This goes down in my book as my shortest (distance and time) cross country flight. Ever.
*sigh*
More pictures available in my Christensen Landout on Flickr.
And for something completely different...In related but much better news, Hollister glider pilot Eric Rupp set a new distance record the same day, flying his DG-300 glider from Hollister to Calexico, California--right on the Mexico border. This amazing 782.66 kilometer flight has been the subject of much planning and speculation until Eric finally pulled it off. It was an amazing combination of great weather, timing, and piloting.
You can see flight details on OLC and his SPOT Satellite Messenger kept the rest of us informed on the ground while he was flying.
Eric's epic flight was covered a bit in the press as well:
Congrats to Eric on an amazing and inspiring flight.
(comments)
Nothing is better than a 3D game, but when you haven’t installed a GUI and have a quick need to play for a bit, here are 4 text based Linux games for CLI:
1. Bastet - Tetris clone:
Bastet ("bastard tetris") is an ncurses Tetris clone which is harder than every other tetris released. It is based on a heuristics engine which tries to detect which block you need or don’t need, and then gives you the blocks that you don’t need. For instance, if you usually play by leaving long "canyons" one square wide and then waiting for the long "I" block, you’ll have to wait till eternity before you see it. The heuristics have been worked on for some time and are quite nasty.
Install Bastet on Ubuntu:
sudo apt-get install bastet 2. Ninvaders - Space Invaders Clone:
nInvaders project is a Space Invaders clone for ncurses.
Ever wanted to play space invaders when you can’t find a GUI? Now you can!
Install Ninvaders on Ubuntu:
sudo apt-get install ninvaders 3. Moon-buggy - drive on the moon:
Moon-buggy is a simple character graphics game, where you drive some kind of car across the moon’s surface. Unfortunately there are dangerous craters there. Fortunately your car can jump over them!
Install Moon-buggy on Ubuntu:
sudo apt-get install moon-buggy 4. Greed - a puzzle game:
The strategy game of Greed. Try to eat as much as possible of the board before munching yourself into a corner.
Install Greed on Ubuntu:
sudo apt-get install greedHope you enjoy playing these simple, but fun Linux based CLI games. You can play any of these games by entering “/usr/games/xxxxx” with the Xs being the name of the game.
Do you know of any other fun CLI based games for Linux? Let us know in the comments. [via mellowd.co.uk]
Windows Steady State runs on XP and Vista and provides a way to “freeze” your system among other things. You can choose an option to run your system in a cached mode and any changes are discarded upon reboot.
SteadyState also provides options for updates and computer restrictions.
Seems like it would be perfect for experimenting with spyware and viruses. Also turn this on if you have any kids - no more worries about them wiping out your music collection.
Get Windows SteadyState from the Microsoft site. [via downloadsquad.com]
I’m happy to learn that IE8 is going to implement a less ambitious version of a feature which NoScript users have enjoyed for more than one year now. The announcement posts seem not to notice the resemblances of “XSS Filter” with NoScript’s Anti-XSS Protection, the most striking being their non-blocking approach: loading the target page in a “neutralized” form and emitting a warning as an info-bar, which doesn’t require interaction and therefore doesn’t necessarily interrupt user’s workflow. But that’s fine: in facts, under the hood, their filter looks quite less sophisticated than NoScript’s InjectionChecker engine, as it is based on a limited blacklist, apparently targeted to the most common reflective XSS attack patterns as seen in proofs of concept:
The XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. […]
The fact that our filter effectively blocks the common “><script>”… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.
Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8.
And there I started smiling: you realize, guys, that those listed “on sites like XSSed.com” are not “XSS vulnerabilities” which will “stop working in IE8″, but just minimal exploit test cases — <script>alert("XSS")<script> — which can be refactored and obfuscated in endless ways to obtain the “IE8 compatible” certification. Yeah, it will be great to see.
Anyway, such a feature being deployed as a built in of a popular browser, rather than as an add-on for an awesome browser, will likely keep script kiddies busy for a while, maybe taking a filter evasion crash course. I just hope it won’t give some site owners an alibi not to fix their bugs, though, putting a “This site is best viewed with IE8” badge near to their McAfee Hackersafe logo.
Final thought: echoing the news on his blog, RSnake did swiftly mention NoScript (thanks), but at the end of that post, calling for adoption of his own bright Content Restrictions idea, he forgot to say that one (experimental) implementation already exists… Do these cross-site scripting filters suppress legitimate cross-site references as well? ;)
If you saw Fred Wilson's post Are You A Connector?, you know a bit about this job already. It's a NYC based startup developing a new platform in an area that's likely to see serious growth in the next few years.
They're looking for someone with coding experience who loves showing other developers and users how stuff works: on stage, via blogs, in screencasts, and so on. It's important that this person have a technical (programming) background and also be very comfortable getting in front of people to demo and speak.
The company is New York based and this job is too. However, I'm told that a Bay Area candidate may work as well, since a presence here will be important. Otherwise, I'm sure that frequent travel to the Bay Area will be part of the gig.
The company is still a bit stealthy but more information will be forthcoming soon.
Ping me if you're interested and I'll put you in touch.
Network/Systems Administrator at Rapleaf in San FranciscoThe folks at Rapleaf ping me from time to time looking for talented engineers too. Here's the description of the position they're currently hiring for.
Rapleaf is a well-funded San Francisco startup (were currently at 15 people). We gather publicly available information from the social web on hundreds of millions of people to enable developers and companies to give their consumers a better user experience. Rapleaf has built the largest portable social graph in the world. We provide rich insight on customers for clients such as retailers, airlines, hotel chains, social networks, lead gen firms, telcos, political campaigns, financial services, and more (these companies learn about their consumers in order to give them a better user experience). The company has processed over 175 million unique searches for businesses and consumers.
You will maintain Rapleafs entire infrastructure and enhance the system to do great things as were on the trajectory to change the world. Helping grow one of the largest and most complex databases for a small start-up.
Role:
- Manage all Rapleaf servers (Linux CentOS, Redhat), backups, web servers (Apache clusters)
- Manage relationship with hosting provider and hardware vendors
- Scalability and expansion (Hadoop)
- Systems administration (DNS,LDAP,NFS,TCP/IP,SELinux)
- Some scripting (Shell, Ruby, Python, or Perl)
- Administer MySQL databases (multi-master replication, snapshot backups)
- Learn how to scale with Ruby on Rails
- Manage complex Java systems
- Manage billions of data items of pages being served
- On-call duty
Note: this job is really hard. Youll be working with some of the top search engineers in the world and they are going to expect that you kick ass. Were doing things that no one has ever done before and solving problems that have been open for years.
Qualifications:
- Master of all things Internet and Linux.
- Incredibly smart, can learn fast, and takes no prisoners
- Learn new platforms fast. We use Ruby on Rails and Java you can pick this up quickly.
- Intensely driven and proactive person.
- Extremely hard working. This is a start-up - team members work long hours.
- Quick learner and real doer. Err on execution over strategy.
- Thrive on working with A-players. Too good to spend long hours with B-players.
- Likeable person who garners respect on and off the job.
- Thrive on chaos, risk, and uncertainty.
- Should be easy to get along with, nice, fun, smart, ethical, and low-maintenance.
- Strong desire to build a more ethical society.
- Desire to be an early employee and want to be a real owner in Rapleafs future.
- Want to work with extremely large datasets and indirectly build portable APIs that thousands of other companies can build applications on top of.
- Ability to lift and install servers (50 lbs)
- Should want to live in or near San Francisco (relocation available if necessary)
Perks:
- Good salary/stock compensation.
- Personal MacBook Pro or Linux based machine
- Medical insurance, 401k.
- Kitchen stocked with food
- Work with some of the smartest engineers
- Contribute to the Rapleaf Dev blog (http://blog.rapleaf.com/dev/)
Again, ping me if you're interested or know someone who might be. I'll make an introduction for you.
(comments)
You may have already seen the news about the new XSSFilter in IE8.0 but I wanted to echo it here as well, because it’s a pretty major new release. It does a great job of preventing most of the reflected XSS attacks out there for default users of the browser when it hits production. Very cool stuff. By the way, the second link above also has a sneak peek as to another security feature in IE8.0 if you look closely.
Think of XSSFilter like noscript in Firefox, but without the turning off JS portion of the functionality, and unlike noscript, it’s default in the browser, so it will impact a lot more people. David Ross (the guy who came up with the term Cross Site Scripting in the first place, btw) wrote this tool to start tackling a problem he’s been thinking about for 8 or more years since that paper was first authored. It’s not perfect, don’t get me wrong, but it’s a huge leap forward in the right direction, and I was hugely honored to be a part of it, since I think it will have a great positive impact on consumer security while us security knuckle draggers figure out a way to get websites to start securing themselves.
Next on my wish list? Content restrictions!
Hello everyone, this is Robert "RSnake" Hansen. It’s been a while since I’ve talked with the BlueHat folks but only because I’ve been busy behind the scenes working on some cool stuff with the Microsofties. I was pleasantly surprised to hear I am now allowed to talk about one of the things I have helped work on. David Ross mentioned it in a blog post he wrote some time ago, but it has come a long way from that point. He called it “XSS-Focused Attack Surface Reduction goodness” for lack of a better term, but now I think we’ve happily settled on a shorter and more memorable name - “XSSFilter.”
In Internet Explorer 8.0, users will be protected from the vast majority of real world XSS attacks. David spent a lot of time analyzing the most common variants and has built a tool to isolate and protect against those attacks for the vast majority of Internet users out there. The tool protects against reflected XSS in particular, and not against the lesser common DOM or persistent XSS varieties. XSSFilter is certainly not a panacea and it’s still recommended that developers follow good programming practices, but this comes as welcome news to me personally and the vast majority of Internet users who will be protected from an attack they probably couldn’t even spell. And best of all, it will be by default – asking consumers to install security plug-ins has never worked well. Taking it out of the consumer’s hands is a huge leap forward.
I’ve been talking about browser security for quite a while in my speeches and on my site – we can’t expect programmers to fix all their flaws, especially in legacy applications. The browser is one of the few important choke points on the Internet, where client side issues can be heavily mitigated and we can begin to get ahead of the problem. Indeed, XSS is a prime example of what can happen when attackers start using the browser as a conduit for attacks against web applications and consumers. Since we know it’ll be a long time (or maybe even never) until we see every critical web application protecting itself, this is a great short term stop-gap for the vast majority of XSS issues against the Internet Explorer browser.
Only time will tell how attackers move and adjust to these changes, but in the near term, I’m happy to have played a small part in adding one more weapon in the fight to protect consumers.
We are very pleased to announce the availability of Matasano’s Playbook!
What is Playbook?
Playbook is a web-based command center for network firewalls. From a single console, Playbook allows firewalls teams to search firewall rulesets, design access rules with full change tracking, and push them out to one, ten or one hundred devices with a single click.
Playbook helps organizations with multiple network firewalls to better manage their policies by providing a centralized and version controlled repository of rulesets, which can be easily browsed or searched via the web. Network operators can review all recent rule changes affecting the London branch, document a recently provisioned firewall at corporate offices, and rollback to the last known version of rules for the North-East group after an update gone wrong with only a couple of clicks and without having to log into 50 different devices.
Playbook takes advantage of an expressive wiki engine to help you document rulesets, protocols, and your network infrastructure, so that you not only have a complete audit trail of all your changes, but you also know why those changes are there in the first place.
There is more information at the product’s official website. We’ll keep you posted as Playbook continues to evolve.
If you currently manage multiple firewalls and are are interested in learning more about Playbook we’d love to talk with you. Shoot us an e-mail or give us a call at 1-888-677-0666 x7529 (PLAY).
Developers often ask security folk, “Hey, how do I protect credentials in config/property files?” or “Do I need to encrypt my production binaries?” I admire their asking security for help, but often times 1) they’ve not asked the question well enough to get a good answer and 2) security folk have a hard time getting to the root of the problem to provide decent guidance.
After teaching a threat modeling course recently I thought I’d demonstrate how considering an application’s architecture, who might attack it, and what impacts a business might face as a result of attacks interrupting or subverting the system’s ability to accomplish its business objective can be very helpful in framing context-free questions like I’ve posed above. I’m of course, talking about why threat modeling, even informally, is useful.
Let’s consider the above questions in a few contexts. I’ll ‘invent’ contexts for the purpose of this conversation, but you can likely see overlap in what you do with one or two, and incredible differences in the others.
Some circumstances will warrant protecting against threat actors making changes to configuration or the code loaded into the production environment in which extensibility of that environment’s code base and flexibility of its configuration are a reality. Examples of such environments might be:
In both cases, you want to push updates or new applications/configuration in the production environment. Really, any organization that separates development from operations/deployment will have to ponder trust of its operators. Outsourcing is not a necessary condition.
“Insider” and “Administrator” threats apply in the second case, whereas a “Malicious User/operator” applies in the former. In all these circumstances, we need to rely on the actor to operate and in some cases maintain the system, but we don’t trust the threat actor with code and certain sensitive configuration elements. That’s a pickle.
In terms of the threats’ capabilities, we expect an Administrator to have intimate knowledge of (and ostensibly administrative control over) the host on which our application is deployed. They do not, probably, have reverse-engineering capabilities, or deft programming skill in non-script languages except in rare cases. Insiders may simply have access to the host (physically or through remote login), may possess the same role as the running application, but probably do not possess root privileges on our underlying host without successfully exploiting it. Their skill level will probably be less than that of an Administrator in most cases.
A malicious operator will run the complete gamut of skills as a matter of fact: there are plenty of deep technologists and tinkerers you want to sell TiVOs and cell phones to. Depending on the size of the market, the data or functionality to be protected, and the possibilities through which a “hack” could be replicated and executed by non-skilled users (my mom will not not log into her TiVO but will definitely send her cell phone away to be “unlocked”), protective schemes may or may not be of much use.
It is because these threats’ vary widely in their skill set and their understanding of the construction of the application that I’ve combined consumer devices with hosting—seemingly unrelated architectures. Opaqueness and user/operator knowledge are slippery slopes. Some people hack their TiVO and some admins haven’t the foggiest of how to tickle an app
We’re drawn to potential impacts to make sense of the capabilities we discussed above and what they might be used for. I’ll treat each system architecture in term, giving a single attack scenario for each threat.
HostingThe administrator lifts plain-text credentials out of a config file (u: oracle, pw: oracle) and conducts his/her own SQL-injection on the database, pulling tables and tables of user records, sells ‘em to organized crime: motivation, payoff, and impact. Let’s consider a code-replacement problem too, this time from the perspective of insider. An insider watches bug reports for a particular dev. team and after seeing a particularly insidious one, rolls back the version of production software to a vulnerable release, and follows the ‘script’ laid down by the bug report. He makes decent use of some coupon-codes, gets about 3-62” flat-panels shipped to his house for $3, and runs.
Consumer DevicesHere, let’s consider two scenarios as well. First, the malicious operator—a consumer—twiddles with his/her DirectTV until I figure out how it stores/sends its username/password up-stream. Discerning a weak password scheme (computable from a username) and having heard a neighbor brag about his “NFL Sunday Ticket” purchase, he/she downgrades service to the cheapest, then updates his/her DirectTV to send the neighbor’s username/password instead of their own. Beaucoup sports at petite pricing. In another scenario, imagine the malicious operator adding their own naughty code to the device to collect streams of content and drop ‘em to disk DRM-free.
One could imagine other goals, attack paths, and impacts easily. I’ve chosen these off the top of my head because they’ll demonstrate dramatically different protective schemes. I don’t know that they’re the most interest, common, or valuable scenarios to consider. I know-in some cases-that the scenarios I’ve listed are contrived.
Now, onto attacks and protective schemes:
Hosting: Code UpdatePreventing insider (or even a malicious system administrator) from loading code can be accomplished by combining an organizational tweak with a platform feature (At least where Java and .NET are concerned). By demanding code and configuration (even code security policy) be signed before promotion into a production environment, and configuring the application container to check for these signatures, one can control what code executes in a particular container. Separating the “Application Deployer” role (the one who signs and delivers code) from “Application Developer” and “System Administrator” prevents either from placing a rogue binary in place of the expected (signed) one.
Outstanding issues with this scheme include how to validate code to be signed. Did the developer inject back-door functionality that remains undetected? And, of course, how do you prevent an administrator from loading malware outside the application container (either side-by-side on the host or as a proxy between the application and a connecting system)?
Consumer Device: Code UpdateCode signing has worked for consumer devices as well. Other encrypted binary format schemes have been employed to not only disallow unauthorized parties from loading code, but also for protecting the IP contained within code updates while in transport over Teh Intarweb.
An aside: I’ve seen a code signing scheme “to prevent malware from being placed on victims’ devices.” However, they granted code signing certificates to anyone willing to register (with their address and some other information). Because they’d give signing ability to (basically) anyone who asked, their scheme did NOT prevent malware from getting onto the device. Instead, it only allowed for tracking of who was responsible for signing that malware ;-) Likewise, a system whose dynamic update function was protected by “proprietary encryption”, thus disallowing anyone from seeing patches or deploying malware in their stead. Because this “proprietary scheme” was basically just LZW, it was trivially broken.
Consumer Device: Storing CredentialsPreventing a malicious operator from observing and gaming credentials will take an entirely different tack. Think about how smart cards or GSM cell phones work. In these cases (both potentially operated by unsavory folk), a card contains both logic and a secret, known to a central authority. When the central authority (a web site, something the smart card is docking with, or inserted in to) needs to authenticate the user device, it issues a challenge to the card. Logic on the card then computes a response to this challenge based on the secret it holds and issues a response. Even if the device’s user is able to intercept both challenge and response, it should remain opaque (and therefore not suffer replay).
Advanced techniques, such as Differential Power Analysis, may be able to extract key information from such schemes even when implemented correctly. A more interesting limitation of this scheme is plausibility of its deployment. Fobs are expensive to deploy and may not even fit within the architecture being analyzed.
Hosting: Storing Credentials‘The trickiest of problems of the bunch to solve. I’ve seen a lot of different schemes discussed, some commercial, some home-rolled. One can thwart an administrator not skilled in reverse engineering and slow down a well-trained one by encrypting configuration, true. However, schemes that involve placing encryption secrets in the code that protect those config files can ultimately be reversed by a skilled administrator. Situations in which said secret was stored elsewhere and passed to the application to be used during start-up raise complexity a fair amount and can also be reversed if the administrator can debug or attach to the application’s process. And, to finish the summary, the credentials must ultimately be used somewhere. Often, it’s easier for administrators to MitM the application and that somewhere rather than do all this reversing we all find fun.
Once some kind of reas