IGinsight

IGinsight

18p

10 comments posted · 0 followers · following 0

13 years ago @ Intrepidus Group - Ins... - Android Root Source Co... · 1 reply · +1 points

This has been a very popular post for the past few days.... no comments?

13 years ago @ Intrepidus Group - Ins... - Mallory and Me: Settin... · 0 replies · +2 points

Thank You :)

Also, I think DCX meant to say *NOT* backdoored. Our original call in our earlier verisons/prototypes to our certificate creation script was just a little shady, but it is pretty safe now. We ultimately aim to yank this out completely and just replace certs on the fly and only have them in memory.

The canonicalization regex combined with the subprocess module makes command execution via the shell script invocation (directly) pretty unlikely. The cert.sh script still has a bit of attack surface, it uses the common name as a parameter to create file names. We were just a little paranoid about that one, so the regex is pretty strict. You could possibly create a file name that is a bunch of periods. We still advocate this being used as a testing tool in a controlled environment, but hey if you trust users on it... =)

And there is one small trick you can use with command line options to directly TCP forward traffic. The whole netfilter lookup piece is not used and it just dumbly forwards traffic from one ip:port (localhost:port) to some (destination:port), which is really uninteresting, but we already had all the required code to do it so I figured why not.

Jeremy

13 years ago @ Intrepidus Group - Ins... - Mobile Platform Trustw... · 0 replies · +1 points

I think I agree in principle to your assertion. It is a two way street and the user should be fully informed of exactly what they are agreeing to up front. We don't mean to suggest a user gives up any rights to their phone. Explicit consent is definitely an understood here.

It really depends on the organization and the sensitivity of the data residing on the device and if the organizations requirements are agreeable to the end user. I would not be terribly happy with anything over the top myself, but at the same time I want to make sure the right controls are in place where it really matters.

As far as remote wipe goes, I don't think it is so scary to give your company that privilege (at least in iOS land). Regular backups of your mobile device should be performed. The mobile platform vendors are moving towards storing sensitive (corporate) data in separate silos and providing features that allow just that data to be wiped, which is ideal.

The best/easiest resolution for this is to simply used corporate issue devices and keep corporate data storage on personal devices to a minimum (since it is such a thorny, potentially sensitive issue).

13 years ago @ SC Magazine US - Dangers of personal de... · 0 replies · +1 points

Better coverage of this topic with more factual details here: http://intrepidusgroup.com/insight/2010/10/mobile...

13 years ago @ Intrepidus Group - Ins... - Security Dialogs and G... · 0 replies · +1 points

Thank you for checking out our blog. You have a great point. Last week I was at Source Boston and got to sit in on a few sessions. (btw- Moxie Marlinspike's presentation was fantastic:http://blogs.zdnet.com/security/?p=6291 ... can't wait to connect googlesharing with privoxy ... wait.. what was I going to talk about? ... o right ...) ...
Source Boston - "We" love to bash compliance and standards right? -- I sat in on this panel discussion to hear the other side:http://www.sourceconference.com/index.php/boston2... and really started thinking about what it would take to give the end-use consistent visual aids to make informed security (and privacy) decisions about the application and websites they use.

It's not just the browser, it's a problem in email clients, and all mobile platforms. The one organization that might be able to pull it off is ISO. but it would take YEARS --- and can you imagine trying to convince steve jobs to ugly up his baby?

In other news... Google considering taking the http:// and httpS:// part of URLs out of the bar entirely.

So the bad news is... users are going to keep getting duped and phished for a long time. The good news is, we have job security?

13 years ago @ Intrepidus Group - Ins... - Y halo thar! The New-N... · 0 replies · +1 points

14 years ago @ Intrepidus Group - Ins... - WebOS: Examples of SMS... · 2 replies · 0 points

For sure ! You tell us who said that and we'll put them on our ignorant list!

14 years ago @ Intrepidus Group - Ins... - WebOS: Examples of SMS... · 1 reply · +1 points

are you running 1.4 and can we have your phone number?

14 years ago @ Intrepidus Group - Ins... - WebOS: Examples of SMS... · 0 replies · +1 points

1.) It's mentioned in the video. 2.) You could try that but we are betting you would not be successful. k thx!

14 years ago @ Intrepidus Group - Ins... - I'm in ur 4sq, snarfin... · 0 replies · +1 points

Thanks for the comments Paul. Yes, we've been doing mobile application security work since Intrepidus started.. this is really par for the course. (unfortunately)

We are in the early infant stages of uncovering all the problems. It's not easy because each platform, (windows mobile, rim, iphone, droid, webos, brew, etc...) has it's own API and it's own way of doing things. Then throw in the handsets themselves... even inside the platform not every handset has the capabilities needed to make use of security features. So that forces developers to roll their own solutions -- and <emeril> BAM! </emeril>; it's security like it's 1999 all over again. clear-text everything, base64, homemade XOR obfuscation, shared symmetric key on a handset because "no one will ever jailbreak the handset."

Thanks for reading our blog!

-Intrepidus