|
Hi Etienne Fortin,
Yeah, in this article I am only refering to a single independent assembly. But for your 2nd question, I will reserve it for my coming articles. I am really working hard on something cool on the next releases of the articles. Give me some time
Hope you like it. Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
Going one step further than that, the hacker could even sign the tampered assembly by his own private key - so potentially fooling the CLR, if the CLR grants trust to an assembly simply if it is signed.
I now more strongly feel that the onus is now on the system administator of the machine(s) to cleverly set trust and evidence based code access security policies for the CLR so that the compromised assemblies fail to execute. This can probably only be achieved if the policy is based on the publisher's identity - be it his public key or his digital certificate.
http://dotnetyogi.blogspot.com/[^]
|
|
|
|
|
Point taken.
I am looking into it. Cheers
Regards,
Chua Wen Ching
|
|
|
|
|
No.
The public key token will be different if you sign the assembly with a different key. So the loader won't be fooled at all.
If an exe loads a library which checks for a registration, and you change the public key token of the library, then the clr won't load the "hacked" dll at all. You'd have to modify all the assemblies that references a hacked one too.
|
|
|
|
|
Hi Hugo Hallman,
Thanks for the clarification. Point taken.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
Totally agree. The hacker would have to 'unsign' and sign all the related assemblies. The CAS policies still wouldn't allow running that code if it has been set up to allow only trusted code to run. I have a feeling, in majority of the .Net running environments (especially the small to medium size sites) the code access security policies have not been set up at all. I think, as much as or more than the developers, the idea of .Net security has yet to sink in with the system administrators.
Thanks
|
|
|
|
|
"NeCoders shall not be held responsible for any cases of software/files being hacked due to the information provided in this article."
Why not?
Horia Tudosie
|
|
|
|
|
|
Hi Chua Wen Ching,
It's great article to read, and you have given a good example of strong name assemblies , but what i know that strong name are used for side by side execution of assemblies which are applicable on Public Assemblies , but any way these were very good articles and hope to get Part IV soon from you
Cheers
Nitin Sandurea
|
|
|
|
|
Just wanted to say thanks for the articles so far. I agree they might be a little verboose, but I found it easy to read and understand. thanks again & keep going!
|
|
|
|
|
Great series of articles. One thing though...
Your disclaimer is ludicrous.
NeCoders shall not be held responsible for any cases of software/files being hacked due to the information provided in this article.
That's like me writing an article "50 Ways To Infiltrate Buildings and Plant Explosives" and including a disclaimer: "RabidKangaroo shall not be held responsible for any buildings that are destroyed due to the information provided in this article."
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
Sorry, but the author is right. Security through obscurity does not work, and that's why even MS publishes deatiled information about vulnerabilities - knowing about a vulnerability in detail is the only true way of knowing if you're in danger and how you can protect yourself.
RabidKangaroo wrote:
That's like me writing an article "50 Ways To Infiltrate Buildings and Plant Explosives" and including a disclaimer: "RabidKangaroo shall not be held responsible for any buildings that are destroyed due to the information provided in this article."
RabidKangaroo never entered a building, right? A world where only hackers know how to break code is a world where no one is safe. Good programmers need to know how to break code. Trying hard to break your own code is the first line of defense against hackers.
Yes, even I am blogging now!
|
|
|
|
|
Daniel Turini wrote:
RabidKangaroo never entered a building, right? A world where only hackers know how to break code is a world where no one is safe. Good programmers need to know how to break code. Trying hard to break your own code is the first line of defense against hackers.
I agree with Daniel. To KNOW to do the attack is the best form of protecting. Writing Secure Code[^] among other very useful things, talks exactly about this...
Marcelo Palladino
Brazil
|
|
|
|
|
I don't believe there is enough content to provide a 3 part article. You could probably get good reviews (You already are but it could get better) if you condensed the 3 parts into a single part about Strong Names. Also you need to understand, like others have said, that Strong Naming isn't supposed to protected code from highjacking but to provide the ability to strongly name an aseembly for reference abilities. It also provides some other benefits when it comes to the CAS but that could be another article. The reason the hashing exists is to verify that the assembly is the same as it was before so that when an app loads the assembly it can be sure it has the one it is supposed to. If you remove the strong name then an app that references that assembly won't be able to find it thus defeating the purpose of trying to highjack the assembly.
Great article though. I need to get off my butt and submit the ones I have laying around. Kudos to you.
-
Drew
|
|
|
|
|
Hi adinnell,
Point taken. There will be a total of 9 articles or more. I will provide some detail explanations on strong name in my article 4, which is in the process.
Thanks
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
Thanks for your series of articles, they are well written and easy to understand.
I really don't see the point of strong named assemblies after reading this. I didn't think it would be that easy to crack, but I guess, having clear text IL code will always make it easily breakable.
A previous comment said that Strong Named assemblies are just for more reliable referencing. I really had the impression that it was for security, but you have blown that theory sky high!
Thanks
Being in a minority of one, doesn't make you insane George Orwell However, in my case it does
|
|
|
|
|
Thanks. Hope you like it.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
Don't forget this is very simplistic implementation of using strong names for security. A developer fluent in assembler could just as easily do something similar with compiled win32 code.
Strong names are also used for other reason like assigning privileges on a machine/enterprise based on the strong name or public (see Runtime security policy in .Net configuration, many Microsoft assembly are granted special privileges by their public key). .Restrictions can be applied for access to methods/classes in other systems based on public keys by using codeaccess security. (see StrongNameIdentityPermission).
Although as this article demonstrates Strong names could be compromised, if you employ a complete security model these changes can be detected. I would recommend that you sign all code, even if it is only deployed to desktops within your organisation. Security is not so much as preventing tamper completely, but making mechanisms that allow you to detect tamper and take appropriate action to prevent the system being compromised.
Rather than take the author at this word here suggest you get a good book on .Net security. The author is technically correct, his article is informative, but he has assumed that you are only using strong names for a single purpose which is only part of the .Net security model.
Sorry about the rant but as a consultant I often come into organisations where no security has been applied to .Net code, even on public web servers.
.Net code can be made secure, but like any good security system a compromise has to be expected and dealt with appropriately. To assume that you code/System will never be compromised just means you will never know when it is.

|
|
|
|
|
HI J.B,
Thanks. Point taken.
Cheers.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
|
Hi S.Senthil Kumar,
Point taken.
From my understanding:
1) Strong Name represents a global unique identifier for assemblies
2) Also to sign assemblies
The SNK does stop you from modifying the il, then assemble back to exe.
Anyway thanks for the reply. Please correct me if i am wrong 
|
|
|
|
|
Remove security checks all over by removing the security related assembly declarations from machine.config...
VictorV
|
|
|
|
|
Hi Victor,
Thanks for commenting. Can you elaborate a bit more by remove security checks in machine.config please?
Thanks again.
Regards,
Chua Wen Ching
Visit us at http://www.necoders.com
|
|
|
|
|
ai,ai, I think I got things mixed up: I meant that you can remove the strongname CAS permission check from the security.config, for example to allow non-strongname-complient assemblies to call strong name protected (linkdemand) assemblies/methods. sorry.
VictorV
|
|
|
|
|
Hey Victor
I think you mean sn -Vr assemblyname? which signals the CLR to not check for a signature on the specified assemblies.
--
Only the true wise understand the difference between knowledge and wisdom.
|
|
|
|