Are there any known methods that can be used to make your software immune to viruses? To be more specific, the development is done in .NET. Is there anything built into .NET that would help with this? I had someone specifically ask me about this and I did not have the slightest clue.
Update: Immunity in this situation would mean immune to exploitation. At least I believe that's what the person asking the question to me wanted to know.
I realize this is an extremely open ended question and that software development is way off from being at a point where it software developed can really be immune to viruses.
When you say immune to viruses, do you mean immune to exploitation? I think any software being immune to viruses is some way off for any development platform.
In general, there are two important activities that lead to secure software
1) Safety by design - does the
inherent design of a system allow an
attacker to control the host machine. However, a secure design won't protect against insecure coding.
2) Secure coding - most
importantly, don't trust user input. However, secure coding won't protect against an insecure design.
There are several features of .NET that help reduce the liklihood of exploitation.
1) .NET takes care of memory
allocation and destruction. This helps prevent exploitable heap corruption.
2) .NET, by default, will bounds check array accesses. In C based languages, overwriting, or underwriting into arrays has allowed attackers to write memory into the target process.
.
3) .NET execution model is not
vulnerable to stack overflows in the
same way as the normal x86 execution
model. Arrays are allocated on the
heap.
4) you can set Code Access permissions, if used properly these help prevent untrusted code performing privileged actions on the host machine.
Related
What is a code reuse attack, and how can we defend against them? I'd love an example.
I don't understand how a reuse attack is significantly different from a buffer overflow attack.
Can anyone help me on this issue?
It is a technique of exploitation which relies on executing the code which is already present in the memory (e.g. as part of the standard library) instead of shipping it to the attacked host as part of the payload. This significantly complicates the job of the attack mitigation software since the surface area of the attack shrinks and makes it much harder to detect (e.g. by fingerprinting) and distinguish from the legitimate traffic.
Here is the wiki https://en.wikipedia.org/wiki/Return-oriented_programming
Code reuse attack uses a vulnerability like buffer overflow, memory leak etc. With the help of these vulnerabilities, an adversary uploads a malicious payload to victim machine to hijack control flow or attack to other systems. Code reuse attack uses Return Oriented Programming or Jump oriented Programming. This attack comes from either by stack or heap by using data cache.
Target hardware is a rather low-powered MCU (ARM Cortex-M3 #72MHz, with just about 64KB SRAM and 256KB flash), so walking the thin line here. My board does have ethernet, and I will eventually get lwIP (lightweight TCP/IP FOSS suite) running on it (currently struggling). However, I also need some kind of super light-weight alternative to SSL/TLS. I am aware of the multiple GPL'd SSL/TLS implementations for such MCU's, but their footprint is still fairly significant. While they do fit-in, given everything else, don't leave much room for others.
My traffic is not HTTP, so I don't have to worry about HTTPS, and my client/server communication can be completely proprietary, so non-standard solution is okay. Looking for suggestions on what might be the minimalistic yet robust (well a weak security is worthless), alternative that helps me --
Encrypt my communication (C->S & S->C)
Do 2-way authentication (C->S & S->C)
Avoid man-in-middle attacks
I won't be able to optimize library at ARMv7 assembly level, and thus bank entirely on my programming skills and the GNU-ARM compiler's optimization. Given above, any pointers of what might be the best options ?
If any of those small TLS implementations allow you to disable all X.509 and ASN.1 functionality and just use TLS with preshared-keys you'd have quite a small footprint. That's because only symmetric ciphers and hashes are used.
There's CurveCP. It's meant to completely replace SSL.
It's fairly new, and still undergoing development, but its author is a well-known expert in the field, and has been carefully working toward it during the past decade. A lot of careful research and design has been put into it.
My immediate reaction would be to consider Kerberos. It's been heavily studied, so the chances of major holes at this point are fairly remote. At the same time, it's fairly minimalist, so unless you restrict what you need to do, you're probably not going to be able to use anything much more lightweight without compromising security.
If that's still too heavy for your purposes, you're probably going to need to impose some restrictions on what you want done.
You might have a look at MST (Minimal Secure Transport) https://github.com/DiplIngFrankGerlach/MST.
It provides the same security assurances as TLS, but requires a pre-shared key. Also, it is very small (less than 1000 LoC, without AES) and can therefore easily be reviewed by an expert.
I know it is to come with variant of answer about two years later, yet... "PolarSSL's memory footprint can get as small as 30k and averages below 110k." https://polarssl.org/features
I just stumbled upon this article:
Lessons from Anonymous on cyberwar
A cyberwar is brewing, and Anonymous reprisal attacks on HBGary Federal shows how deep the war goes.
http://english.aljazeera.net/indepth/opinion/2011/03/20113981026464808.html
Are there techniques to really protect our own developed software against highly sophisticated techniques ?
For example can't a simple crc check be enough ?
uPDATE: My question is not about protecting the software against cracking, it's about protecting the USER pc from being infiltrated. why wouldn't be enough to just check the crc and avoid running if it is not right ?
There is no guaranteed full protection. If you want your software be uncrackable or unexploitable, don't release it at all.
You want your software to verify checksums? Of what?
If the highly sophisticated techniques exploit problems in the network, the operating system or hardware; then no, user-ring software doesn't enter the picture so verifying checksums won't help.
If you want to checksum every incoming message, then you need to be able to enumerate all the possible safe incoming messages, in which case you've got an easier to use filter than checksums.
If you want to reject every incoming message that doesn't match a small list of checksums, then you've just turned one kind of attack into another : a denial of availability. This may be fine for some systems but not most.
There is no protection against 0-days, after all thats the very definition of an 0-day. ALL software is vulnerable.
But you can plan on failure. That is the point behind Defense in depth.
What you can take into mind is the principal of least privilege access. Security in layers.
I mean in operating systems or their applications. The only way I can think of is examine binaries for the use of dangerous functions like strcpy(), and then try to exploit those. Though with compiler improvements like Visual Studio's /GS switch this possibility should mostly be a thing of the past. Or am I mistaken?
What other ways do people use to find vulnerabilities? Just load your target in a debugger, then send unexpected input and see what happens? This seems like a long and tedious process.
Could anyone recommend some good books or websites on this subject?
Thanks in advance.
There are two major issues involved with "Client Side Security".
The most common client exploited today is the browser in the form of "Drive By Downloads". Most often memory corruption vulnerabilities are to blame. ActiveX com objects have been a common path on windows systems and AxMan is a good ActiveX fuzzer.
In terms of memory protection systems the /GS is a canary and it isn't the be all end all for stopping buffer overflows. It only aims to protect stack based overflows that are attempting to overwrite the return address and control the EIP. NX Zones and canaries are a good things, but ASLR can be a whole lot better at stopping memory corruption exploits and not all ASLR implementations are made equally secure. Even with all three of these systems you're still going to get hacked. IE 8 Running on Windows 7 had all of this and it was one of the first to be hacked at the pwn2own and here is how they did it. It involved chaining together a Heap Overflow and a Dangling Pointer vulnerability.
The problem with "client side security" is CWE-602: Client-Side Enforcement of Server-Side Security are created when the server side is trusting the client with secret resources (like passwords) or to send report on sensitive information such as the Players Score in a flash game.
The best way to look for client side issues is by looking at the traffic. WireShark is the best for non-browser client/server protocols. However TamperData is by far the best tool you can use for browser based platforms such as Flash and JavaScript. Each case is going to be different, unlike buffer overflows where its easy to see the process crash, client side trust issues are all about context and it takes a skilled human to look at the network traffic to figure out the problem.
Sometimes foolish programmers will hardcode a password into their application. Its trivial to decompile the app to obtain the data. Flash decompiling is very clean, and you'll even get full variable names and code comments. Another option is using a debugger like OllyDBG to try and find the data in memory. IDA-Pro is the best decompiler for C/C++ applications.
Writing Secure Code, 2nd edition, includes a bit about threat modeling and testing, and a lot more.
Is there a site, or is there a simple way of setting up one, which demonstrates what can happen with a buffer overrun? This is in the context of a web app.
The first question is... what webserver or library? IIS-6 running the ASP script interpreter? ASP.NET behind IIS-7? Apache Tomcat? Some library like the HTTPServer in Poco?
To exploit a buffer overrun you must first find a specific place in an application where the overrun can occur, and then figure out what exact bytes must be sent to overwrite memory with the right bytes to run out to the stack and then execute machine code you've sent in the overrun (because you've rewritten the stack).
http://en.wikipedia.org/wiki/Buffer_overflow
http://seclists.org/fulldisclosure/2005/Apr/412
http://www.microsoft.com/technet/security/bulletin/MS06-034.mspx
http://www.owasp.org/index.php/Buffer_Overflow
http://www.windowsecurity.com/articles/Analysis_of_Buffer_Overflow_Attacks.html
Bring on the flames, but I would say that any codebase of sufficient size contains potentially explotable buffer overflows regardless of the execution environment or source language. Sure, some languages and platforms allow the app developers to "shoot themselves in the foot" easier than others, but it all comes down to individual dilligence, project complexity, use of 3rd-party code and then there are always exploits for base implementations.
Buffer overruns are here to stay, it's just a question of mitigating exposure through safe programming practices and diligently monitoring for new exploits as they are discovered to manage risk.
A grand example is that for a web app, there's the chance for overflows in the networking implementations of all the equipment and applications handling delivery of your bytes across the Internet.
Consider the distinction of a client trying to break a server, versus one client trying to conquer other clients accessing a specific server?
Besides the simple "C" style overruns where the developer failed to follow secure programming practices, there are hidden gems like integer overflows.
Even if a certain server host environment is known to be highly stable, it no doubt makes use of a database and other operating system facilities which themselves might be exploitable through the webserver.
When you get right down to it, nothing is secure and it's really just a matter of complexity.
The only way a specific application or server can be fully secure is through diligent monitoring so issues can be corrected when questionable behavior is discovered. I highly doubt Walmart or Fedex or any other major corporation is happy to publicize breaches. Instead they monitor, fix and move on.
One could even say that SQL Injection is an abstract form of a buffer overrun, but you're simply picking where you want the buffer to end using specific characters and then providing the code you wish to execute in the right place.
They tend not to occur in web apps. Google's Web Application Exploits and Defenses codelab has a short section on it but doesn't demonstrate it:
This codelab doesn't cover overflow vulnerabilities because Jarlsberg is written in Python, and therefore not vulnerable to typical buffer and integer overflow problems. Python won't allow you to read or write outside the bounds of an array and integers can't overflow. While C and C++ programs are most commonly known to expose these vulnerabilities, other languages are not immune. For example, while Java was designed to prevent buffer overflows, it silently ignores integer overflow.
It really depends on the language you're using as to whether buffer overflow is even possible.