As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Bonus points for explaining how you improved it.
Real life security by obscurity?
The key to the front door is stashed under a rock nearby, or under the welcome mat, or on top of a high railing.
These are all instances of security through obscurity, as in, it is right out in the open for anyone to grab, but most people wont be able to find it without huge amounts of searching. However, a dedicated attacker can walk right in.
Some people like to make their javascript difficult to read (and therefore hack) by using obfuscation. Google is among the users of this technique. At the simplest level, they change the variable and method names to a single inscrutable letter. The first variable is named "a", the second is named "b" and so on. It does succeed in making the javascript exceedingly difficult to read and follow. And it adds some protection to the intellectual property contained in the javascript code, which must be downloaded to the user's browser to be usable, therfore making it accessible to all.
In addition to making it difficult to read the code, this shortening of variable names reduces the size of the javascript code that has to be downloaded to the user's browser. Theoretically, this can reduce network traffic.
Here's an article about Google's obfuscation, and here's a list of available tools.
On a website I did some contract work on I noticed that they were storing double-hashed passwords. From memory, they were storing something like
$encrypted_password = md5( sha1( plaintext_password ) );
When I asked what the purpose of this was, I found out that the guy who wrote the account creation/login script had been reading about dictionary attacks. He figured that no one would ever think to create a dictionary where they hash inputs with md5 and sha1.
I improved the system by adding a random salt column to their user table. I left the double-hashing in though. It doesn't do anything to hurt the security of the system, and to be honest, I thought it was pretty clever for someone who didn't really know much about security to think of this.
Seen: Websites use a complex url to access ajax components rather than actually password protect them such as:
domain.com/3r809d8f09feefhjkdjfhjdf/delete.php?a=03809803983djfhkjsdfsadf
the string has remained constant, the query is random and is designed to stop attackers.
Improvement: Restrict the page to being accessed only from certain IP addresses. Add an authentication string to the query that is a salted hash of the access time.
In a more "real life" example, I don't know if it's intentional or not, but I like the way none of the doorbells in my block have any names on them, and that their numbers seem to have no correlation to the apartement numbers whatsoever. Ie. ring on #25 for apartement 605, #13 for apartement 404 and so on. :)
One vendor we deal with requires us to post the username and password in the querystring in ROT-13 "encrypted" format. No joke.
Security through obscurity is a valid tactic. Plenty of people have turned off replying with version information as a best practice for ftp and apache. Honeypots can be considered an obscured practice, since the attacker doesn't know the layout of the network and gets sucked into them. One high security site I know of assigns their username by a five digit alphanumeric phrase (such as '0a3bg') instead of using logical usernames. Anything that makes breaking into a system more difficult, or take longer, is a valid measure.
Security exclusively through obscurity is bad.
People writing their password on pieces of paper and putting it under their keyboard.
I solved it by logging into their computer with their account and sending out an embarrassing email to the group.
Seen: phpMyAdmin moved into the directory _phpmyadmin
Improvement: Disallowed access from outside the company's network.
Similar to #stech's solution.
Some of the admin pages in our application on the web, check for a local IP subnet range, else display access denied.
Improvement is accessed is restricted to users who are inside the network or VPNed to it.
Back in the old DBase/Clipper days I worked for a guy who developed an application for a friend of his. This friend wanted to have some "secretly" accessible program or data (I don't recall) that required a password only known to him.
The solution, I was told, was that Clipper opened a DOS prompt in the secret directory, with black text on black background colors (some ANSI control characters accomplished this).
The user had to type in the password, but this being input line of the DOS command prompt, the "password" was really the name of a batch file that was then executed.
I once saw a photography website where you could strip some characters off from the photo thumbnail pictures url to get the full version.
Many professional photographer websites use Javascript to prevent people from right-clicking on images to "save as ...". Most of those sites also don't do any watermarking.
I used to surf with referer headers disabled... it's quite surprising how many websites will blow up or flat-out reject you if they don't know where you came from.
One website had a poll and used cookies to prevent you from voting multiple times. You could simply erase that cookie and keep voting. And you could script it all using wget, too.
The example I see of this all the time is something being done in source code that the developer assumes no one will ever see. You see this a lot with crypto-keys in particular, embedded right in the source code. A lot of times it is not even a question of decompiling the code, they could outright just use the library.
The solution is always to teach the developer to assume that someone has the source code and can use it against you.
Going to great lengths to hide software names and version numbers .
Ie. changing Tomcat server name and version to some quotes and random numbers (like 666), changing the name and version numbers of regular javascript libraries like scriptaculous and prototype and so on.
In a current project we're using Google Web toolkit (GWT) and this sneaky little thing compiles Java to javascript (which you have little to no control over) and includes the string "GWT" and version number. Totally unacceptable of course so we'll need to make a script that will run after GWT compile to remove all these references(!).
/admin without password.
Yes I've seen it, it's very real.
Related
Users can get their own subsites on ours, so that www.example.com/subsite/gary would then be a specific users subsite.
However I am worried about the possibility of homographic / unicode spoofing attacks, where a malicious user creates an account with a different username but with unicode characters that will appear the same to others, and in that way can pass around a link purporting to be gary when it is in fact someone else.
The only solution I've seen to this that looks mature is UCAPI http://www.casaba.com/products/UCAPI/ but I would prefer not to use it, I would like to have something that works with node.js. (to the extent that I would rather implement myself if need be)
has anyone an example where they can check for these kinds of homographic / spoofing attacks with node.js?
You could try using Unicode normalization with String.prototype.normalize which is available in Node.js v0.12, but I doubt that takes care of every possible attack vector.
Use UCAPI — it’s made for your exact use case.
Wait long enough and someone will implement it for you - https://www.npmjs.com/package/homoglyph-search
Regardless of the language I'm always puzzled by the concept of security through an if. All the code I write relies on success of that one line with if statement:
user = getUserName();
password = getPassword();
if (match(user, password)) {
print secret information;
}
Since it's only one line I feel like sabotage can be relatively simple. Am I overlooking things, or is a single if really the best way to do this?
You are right, an if like this is easily hacked. If one reverse engineers this application, you can easily modify a few instructions to skip the if.
There are various options, like obfuscating the executable or adding more complex checks and in add them in various places in your application. But whatever you do, your application can always be hacked.
Best thing is not to worry about it. By the time your application is so good and great and widely used that people are actually willing to put effort in cracking it, you will probably make enough money to protect it better. Until then, it's a waste of time to even think about it.
In the specific case you are showing, if you were really worried about unauthorized people seeing the secret information output by "print secret information;" you would encrypt the "secret information" with the supplied password. This would ensure that only the person who was able to provide the proper password would be able to see the secret information.
There's one thing about IF's that is often overlooked. It's called timing attack. Suppose you have a web application that does comparison based on direct matching of password sent against password stored in the DB (yes, I know that nobody in his mind will store passwords in the DB, but as Cheshire Cat said, "we are all mad here"). Then comparison procedure takes different time depending on whether the passwords don't match on the first character, on the second one or on the last one. While it might seem that the time difference is tiny, it's enough for attacker to attempt to guess the password even across internet, not talking about local analysis. Timing attack is a bit more complicated, than I described, but in general IF comparison is not 100% safe, at least not in all cases.
The if statement is absolutely secure, and can never be the cause of a vulnerability. Vulnerabilities arise from nearly everything else in your code.
It is possible that the comparison operator that you are using is flawed. For instance the == operator employs fuzzing matching where a range of possible values are accepted. This might not be good for secuirty but its hard to come up with a good example, it doesn't really matter for a password. A simple $password==$_GET['password'] should work just fine.
Your if statement could also be relying on bad regular expression such as
if(preg_match('/(.+)\\.js/'.$_GET['file'])){
readfile($_GET['file']);
}
In this case the regex is looking for a .js anywhere in the string, not enforcing it to be at the end.
?file=../../.js/../../../../../../../etc/passwd
(And this vulnerability won me $3,000 in the Mozilla bug bounty program ;)
If this is a server code - this is not a problem, as long as you keep your server secure.
If this is a client code - you are right. Someone can manipulate your code - either the binary file or the memory image (once loaded). However, this is true for any client application. You can only make it harder (by using tools like PECompact + Anti-debug plugin for example), but you can't achieve very strong security.
I'm not sure to understand your question.
Software security techniques are imperfect, and AFAIK they pre-suppose few bugs in the compiler, and a "perfect" hardware (that is, the processor is interpreting correctly the machine code).
I am not familiar (but interested) with approaches for imperfect hardware (except of course by using redundancy or other techniques, e.g. ECC, to detect hardware errors).
There is nothing insecure about one line with an if in it.
If the code is running on your server, what matters is how secure that server is. If an hacker gains access to it, it doesn't matter how complicated your code is, he will be able to circumvent it.
Similarly, if your code runs on the computer of a potential attacker (like a computer game that you want to protect), there is nothing you can do to stop the attacker. You can make his work slightly more difficult, but that's all.
You shouldn't worry about the security of one line, but of the system as a whole. If you make your code more complicated, all you did is introduce more potential for bugs. Using more complicated code is an attempt at security through obscurity, which doesn't work.
If you can't trust your computer to execute a simple if correctly, you can't trust it at all.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm a member and contributor of the Argentum Online (AO) community, the first MMORPG from Argentina, which is Free Software; which, although it's not 3D, it's really addictive and has some dozens of thousands of users.
Really unluckily AO was developed in Visual Basic (yes, you can laugh) but the former community, so imagine, the code not only sucks, it has zero portability.
I'm planning, with some friends to rewrite the client, and as a GNU/Linux frantic, want to do it cross-platform. Some other people is doing the same with the server in Java.
So my biggest problem is that we would like to use a rapid development language (like Java, Ruby or Python) but the client would be pretty insecure. Ruby/Python version would have all it's code available, and the Java one would be easily decompilable (yes, we have some crackers in the community)
We have consider the option to implement the security module in C/C++ as a dynamic library, but it can be replaced with a custom one, so it's not really secure.
We are also considering the option of doing the core application in C++ and the GUI in Ruby/Python. But haven't analysed all it's implications yet.
But we really don't want to code the entire game in C/C++ as it doesn't need that much performance (the game is played at 18fps on average) and we want to develop it as fast as possible.
So what would you choose in my case?
Thank you!
There's an old adage: 'security by obscurity is no security'.
Don't worry about the code being available, that will make no difference at all. Instead, design the network protocol so it is hard to crack, which means really strong authentication for transactions that matter.
Actually, what I'd do, is try to port the game to Mono, starting from the VB source you have now, and gradually write new code in either C# or IronPython.
The client being "secure" or not should, ideally, not be an issue. If it is an issue, there's a problem with the game's architecture.
The client being able to do "whatever it wants" is irrelevant. In a well-architected multiplayer game, the client only has the data that it absolutely needs, and all actions are authorized by the server.
Let's say someone hacks a client to say that their opponent is dead. Fine. They can hack it on their client all day long, and maybe even trick the renderer into rendering the opponent falling over. However, they should not have any authority to say whether or not the opponent is dead - that's up to the server. So the server gets a message saying "Opponent X is dead." The server should be smart enough to go "ummmm, no" and the opponent happily keeps being alive and doing whatever he wants.
This is an ideal, of course, and often some compromises need to be made for fluidity of gameplay and/or server load. However, for the important things, everything should be verified by the server. Especially in an MMO.
Treat your game as if your client was open source.
I would suggest an upgrade path from VB6 -> VB.NET. Visual Studio would take care of most of the conversion process for you. After you get it properly ported, you could convert it to C# if you want. Then you'll have to create workarounds for non-portable(Windows only) features and those not supported by Mono.
I don't get it. You want to rewrite a free software program and make it closed source? I guess you can do it if you rewrite everything, but since now it is open, the protocol is open too.
So, even if security through obscurity was fine (and it is not), you would not have it anyway since there is no obscurity.
in no occasion the client should be authoritative about anything more than what he wants to do (and even in that case, it's the server who decides if he can do it, and what is the outcome)
in no occasion the client should know things he is not supposed to show
fail those, and everything else won't matter any more.
If the overall design is flawed, either fix it or stop worrying: it is pointless to brush your teeth if a tiger is eating you.
I can't comment the last answer..
The thing is that this game in particular, has some thinks that changing them will make the game totally different..
For example, the client knows at each moment where are the other users. (its a tile engine based game) so, when a character is invisible, it is posible to see it accessing to the code (or editing memory or handling the packets).. Okey, let's say the client doesn't know anything about the invisible characters.. When a character casts an spell, he has an "Overhead" message, like "VAX IN TAR" or things like that.. So, you can see the position of the character that casted that spell.. People often send an empty chat (it is fair in the game) so, whoever is able to read the chats and look for an empty chat (full of spaces), he knows where an invisible char is..
And all things like that. It is possible to do all those things to put the ALL the stuff in the server, but it would be a whole different game.
This game is a very dinamic game, every player make a lot of things, and having all this things in the server will make it totally unplayable.
Sorry for my bad english.
(Im a friend of alcuadrado, who can't comment in the other post, sorry if this is not an answer)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am currently working on a project where i need to create some architecture, framework or any standards by which i can "at least" increase the cracking method for a software, i.e, to add to software security. There are already different ways to activate a software which includes online activation, keys etc. I am currently studying few research papers as well. But there are still lot of things that i want to discuss.
Could someone guide me to some decent forum, mailing list or something like that? or any other help would be appreciated.
I'll tell you the closest thing to "crackproof": a web application.
Desktop applications are doomed, for many other reasons, but making your application run "in the cloud", in a browser, gives you a lot more control about security.
A desktop software runs on the client's computer, so the client has full access to it. A web app runs on your server, so the client only sees a tiny bit of it.
You need to begin by infiltrating the local hacking gang, posing as an 11 year old who wants to "hack it up". Once you've earned their trust you can learn what features they find hardest to crack. As you secretly release "uncrackable" software to the local message boards, you can see what they do with it. Build upon your inner knowledge until they can no longer crack your software. When that is done, let your identity be known. Ideally, this will be seen as a sign of betrayal, that you're working against them. Hopefully this will lead them to contact other hackers outside the local community to attack your software.
Continue until you've reached the top of the hacker mafia. Write your thesis as a book, sell to HBO.
Isn't it a sign of success when your product gets cracked? :)
Seriously though - one approach is to use License objects that are serialized to XML and then encrypted using public/private key pairs. They are then read back in at runtime, de-serialized and processed to ensure they are valid.
But there is still the ubiquitous "IsValid()" method which can be cracked to always return true.
You could even put that method into a signed assembly to prevent tampering, but all you've done then is create another layer of "IsValid()" which too can be cracked.
We use licenses to turn on or off various features in our software, and to validate support/upgrade periods. But this is only for our legitimate customers. Anyone who wants to bypass it probably could.
We trust our legitimate customers to not try to bypass the licensing, and we accept that our illegitimate customers will find a way.
We would waste more money attempting to imporve the 'tamper proof' nature of our solution that we loose to people who pirate software.
Plus you've got to consider the pain to our legitimate customers, and asking them to paste a license string from their online account page is as much pain as I'd want to put them through. Why create additional barriers to entry for potential customers?
Anyway, depending on which solution you've got in place already, my description above might give you some ideas that might decrease the likelyhood someone will crack your product.
As nute said, any code you release to a customer's machine is crackable.
Don't try for "uncrackable." Try for "there's enough deterrent to reasonably protect my assets."
There are a lot of ways you can try and increase the cost of cracking. Most of them cost you but there is one thing you can do that actually reduces your costs while increasing the cost of cracking: deliver often.
There is a finite cost to cracking any given binary. That cost is increased by the number of binaries being cracked. If you release new functionality every week, you essentially bifurcate your users into two groups:
Those who don't need the latest features and can wait for a crack.
Those who do need the latest features and will pay for your software.
By engaging in the traditional anti-cracking techniques, you can multiply the cost of cracking one binary an, consequently, widen the gap between when a new feature is released and when it is available on the black market. To top it all off, your costs will go down and the amount of value you deliver in a period of time will go up - that's what makes it free.
The more often you release, the more you will find that quality and value go up, cost goes down, and the less likely people will be to steal your software.
As others have mentioned, once you release the bits to users you have given up control of them. A dedicated hacker can change the code to do whatever they want. If you want something that is closer to crack-proof, don't release the bits to users. Keep it on the server. Provide access to the application through the Internet or, if the user needs a desktop client, keep critical bits on the server and provide access to them via web services.
Like others have said, there is no way of creating a complete crack-proof software, but there are ways to make cracking the software more difficult; most of these techniques are actually used by bad guys to hide the malware inside binaries and by game companies to make cracking and copying the games more difficult.
If you are really serious about doing this, you could check e.g., what executable packers like UPX do. But then you need to implement the unpacker also. I do not actually recommend doing this, but studying game protectors and binary obfuscation might help you in your quest.
First of all, in what language are you writing this?
It's true that a crack-proof program is impossible to achieve, but you can always make it harder. A naive approach to application security means that a program can be cracked in minutes. Some tips:
If you're deploying to a virtual machine, that's too bad. There aren't many alternatives there. All popular vms (java, clr, etc.) are very simple to decompile, and no obfuscator nor signature is enough.
Try to decouple as much as possible the UI programming with the underlying program. This is also a great design principle, and will make the cracker's job harder from the GUI (e.g. enter your serial window) to track the code where you actually perform the check
If you're compiling to actual native machine code, you can always set the build as a release (not to include any debug information is crucial), with optimization as high as possible. Also in the critical parts of your application (e.g. when you validate the software), be sure to make it an inline function call, so you don't end up with a single point of failure. And call this function from many different places in your app.
As it was said before, packers always add up another layer of protection. And while there are many reliable choices now, you can end up being identified as a false positive virus by some anti-virus programs, and all the famous choices (e.g. UPX) have already pretty straight-forward unpackers.
there are some anti-debugging tricks you can also look for. But this is a hassle for you, because at some time you might also need to debug the release application!
Keep in mind that your priority is to make the critical part of your code as untraceable as possible. Clear-text strings, library calls, gui elements, etc... They are all points where an attacker may use to trace the critical parts of your code.
I know SQL Injection is one... what are the others...
OWASP.org keeps a list. Start with the OWASP top ten.
Others have said this, but...
Essentially all security vulnerabilities come from data. If your program doesn't process any data it's likely to be secure. It's also likely to be pretty useless :).
That leads to what I think is the core concept of making code secure:
Don't trust your data. Ever.
Sanitize everything you possibly can. You can rely on the security guarantees of your platform (for instance, it's highly unlikely that you'll see a classic string based buffer overflow in a managed language like Java or C#), but otherwise you need to validate everything that comes into your application.
Never store plaintext passwords, either. (I can't tell you how many commercial packages I've evaluated for my company which did -- and then acted nonchalant about it when I called them out. My favorite excuse, from a CRM vendor: "Will your end users typically have Enterprise Manager or Query Analyzer on their desktops?")
Here is a list of Top 10 Secure Coding practices. It is as good a start as any. Consider #8, Defense in Depth, in particular.
Massage and filter ALL input to your program before processing.
Never process input without filtering and truncating.
-R
Buffer overflows are the classic if you're writing C, as they often allow the execution of arbitrary code by an attacker.
This is for web stuff but since you left it open ended...
JavaScript injection. If you allow any input from any source that's being outputting somewhere JavaScript could be typed in the input and then when it's outputting (unless properly encoded/decoded) it will output the raw javascript.
You could consider the chapters of this book to be a pretty good checklist...
19 Deadly Sins of Software Security
Simply program defensively. For each function/method/procedure/subroutine consider "What is the expected input? What do I do when the input deviates from that? How can I most easily ensure that the input will not deviate from that." Know your input; know your output. Don't go overboard, but also understand that data in a database might have been compromised. If a particular set of data can be constrained in some particular way then select your data types and variables to play to that. Keep numeric things numeric.
Whenever I see a String object in a program I facetiously ask "What would happen if this string contained the lyrics to Gilbert and Sullivan songs?" Simple if-else checks and premature return statements at the beginning of a function can prevent that sort of thing from wreaking havoc later.
I like to model my system with Threat Modeling Tools. This particular one lets you model different applications and gives you all types of information about what types of threats are applicable based on the model as well as some mitigations and their risks. It also let's you track these risks throughout the dev. life cycle to come up with mitigation plans. It's pretty cool. :)
I second the recommendation for: 19 Deadly Sins of Software Security
It isn't just a checklist, read it to understand many of the aspects of software security. Some are broad items, that let you understand the reasoning behind many of the different security issues.
Avoid sending plain text usernames.
how about verifying user input? For example, you're expecting a 10 digit phone number, but you get "800OHNOES!"
In addition to the wonderful guidance on OWASP, also check out the SANS/CWE.
Sending plain text passwords without first encrypting them is never a good idea.