Sunday, January 26, 2014

Why Hacking XMLCrypto is Bad, Really Bad!!!

From the get-go, I've always avoided cracking XMLCrypto. Every time I see a discussion about hacking it, I always say leave it alone. To some people, that came across as protecting my vested interest. That can never be farther from the truth.

I've also been in discussion with a few people wanting to do their own solution, and they always focus on this one class: The XMLCrypto class. I don't blame them. I mean, this is the shortest way to their goal. I mentioned in one of my previous blogs that I looked at this and have almost considered doing exactly just that. But...my training and experience pushed me to find another way. And there's always another way. Working for a top tier security company, I've seen all this happen too often. Bad guys are always trying different things to spread harm. And I love my car too much to have to worry about this problem.

More and more solution are coming out and they're all centered on cracking XMLCrypto. There's one solution that is particularly bad. For one, this was based off of somebody else's work. For another, it entailed patching 3 class files. 3 Class Files!!! Seriously?!? If he knew what he was doing, he wouldn't be patching 3 files. If everyone had at least some sort of basic security training, they'd leave XMLCrypto alone. If everyone cares about their cars and their friend's cars as much as I do mine, they'd leave XMLCrypto alone.

So, why is it bad? For those who know E-Sys, you know that it is only part of a bigger solution. PSdZ (PSdZData) is what makes it work. All files in PSdZ are digitally signed, encrypted and some are even compressed. There's a reason for that. The very reason we digitally sign a document is to preserve its integrity and verify it's authenticity.  When you patch XMLCrypto, you take all that away. You dump the digital signature and accept everything blindly.

XMLCrypto is our last defense in verifying FA, FP, CAFD and everything else. It is our protection from tampered files. Think of it as the firewall of PSdZ. It only allows trusted and verifiable files.

Figure 1: XMLCrypto doing its job

Like I said, patching it takes away all these feature and benefits. It's akin to creating a wide hole in the firewall. Wait, not just a hole, but you're actually breaking down the entire defense wall. Why anyone would do it is well beyond me. It such a shame they don't understand this concept and the danger of doing such a thing.

Figure 2: Patched XMLCrypto Class

Proof of Concept: Download this file: Modified CAFD This is an CAFD, altered and repackaged. Unpatched E-Sys will never accept this CAFD file as it knows it's tampered and will never pass verification. But those with patched XMLCrypto will have no trouble using this file. In fact, the app will gladly accept anything you throw at it.

But what can a tampered CAFD do, you ask? CAFD is a file template which contains things like default values base on your Vehicle Order. Unfortunately, it also contains values for transport mode. What is "Transport Mode"? It's when your car needs a ride to the dealership because it wouldn't start on its own :).

Kidding aside, it is very easy to get these values and replace the ones used as default values, package and distribute it as "New" version of PSdZ. None would be the wiser, certainly, not your patched E-Sys.
 
This is why I didn't patch XMLCrypto. I hope everybody realizes this.

13 comments:

  1. You've certainly convinced me!
    Tx!

    ReplyDelete
    Replies
    1. It makes a lot more sense if you've ever worked in cyber security firm or if you're familiar with cyber threat landscape

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. "Hacking XMLCrypto is Bad, Really Bad" - do not think so.
    http://youtu.be/jUXda9ZOH44

    ReplyDelete
    Replies
    1. Of course you don't. This concept is hard to understand unless you work in cyber security or have a minimum decent exposure to it.

      I can tell you right now, there are several people working on improved CAFD. it's only logical to think that the reverse is also true. If you can enable things, you can also disable things. I already have a proof of concept for you, so not sure why we're discussing this.
      The video shows it cannot process a corrupted CAFD but I wasn't talking about this type. Have you tried processing a good formatted CAFD with modified content? Like I said, I have a POC

      Delete
    2. The video was shows hash of the file, to avoid suspicion of substitution files.

      Delete
  4. I used your Modified CAFD.
    "Proof of Concept: Download this file: Modified CAFD This is an CAFD, altered and repackaged."

    ReplyDelete
    Replies
    1. This is getting too funny. Why are you wasting time manipulating the app just so you can show the error message? Did you even understand what the message was?

      I'll save you the trouble: There are only two places where you can invoke that error, and it is way, way, far from even opening the CAFD files.

      private Document createXMLDocument(String xmlData)
      {
      if (singleInstance == null) {
      throw new PSdZStateException(ErrorCategory.SYSTEM_ERROR, PSdZErrorCodes.INVALID_CALL_FOR_DECRYPT_VERIFY_XML_PLEASE_CALL_INIT_METHOD_OF__FIRST, new Object[] { getClass().getName() });
      }

      }
      And...
      public Document decryptVerifyXML(File paramFile)
      {
      if (singleInstance == null) {
      throw new PSdZStateException(ErrorCategory.SYSTEM_ERROR, PSdZErrorCodes.INVALID_CALL_FOR_DECRYPT_VERIFY_XML_PLEASE_CALL_INIT_METHOD_OF__FIRST, new Object[] { getClass().getName() });
      }

      }

      I know the code well. Now, tell me, where in that code does CAFD get openned? And what is your point?

      You should know exactly what the error should be. Or maybe you don't. But either way, you are missing the point.

      XMLCrypto has only one purpose and that is to verify and ensure documents are signed and trusted. Alter XMLCrypto, and you remove that feature. Compromised security? You can bet your bottom dollar

      Delete
  5. Well, I'm not gonna argue your rigged video, it's a moot point.

    I'm glad you're trying to improve the solution. That's a step in the right direction and is what I'm hoping for when I wrote the article.

    But so long as it's centered on XMLCrypto, you can only improve it so much. You can retain some of the checks but not all of them. The very premise of your solution is to force E-Sys to accept random certificate and is the root of my contention.

    XMLCrypto is a lock and key algorithm. You either have the master key or you force the lock to accept any key. You obviously don't have the master certificate, so.

    If you or anyone just spend more time looking into it, you'll realize that there are multiple ways of doing it without compromising the whole system. I already did it, it's only logical that it can be done by somebody else too.

    Good luck on whatever you end up doing, I just hope it's away from XMLCrypto. Should you take this route and not the easy one, I sincerely hope you'd succeed

    ReplyDelete
  6. Hi TokenMaster,
    As you already know, nowdays we have problem with newer (v55) trimmed CAFD files.

    I am just curious how a decrypted XML file looks inside. Maybe there is a solution to match a trimmed and untrimmed file to each other and based on the common things I could copy the missing information from untrimmed to trimmed.

    ReplyDelete
  7. Trimmed CAFDs are not a problem. If someone's telling you otherwise, tell them @SkaterMeNot will be very happy to prove them wrong. V54.3+, and V55 were never an issue and I code with it.

    ReplyDelete
    Replies
    1. Is it possible to share the "solution" with me? Bimmerfest forum is just full of questions..

      Delete
  8. Yes please, tell me the solution too...

    ReplyDelete