Shikayat hai ke vo mulakat nahi karta
Muskurata hai magar bat nahi karta
Shabdo ko rakhat hai motyon ki tarah
kanjoos hai kabhi istemal nahi karta
manta nahi kahna mera bas yunhin
Apne main magan hai kuch khayal nahi karta
har sur ko janta hai pahchanta hai har kala ko
phir bhi adhura sa hai koi pura kam nahi karta
While i was scrolling my old mails in search of some financial document i found one interesting doc on which i was working long time back and due to some unknown reason didn't able to continue it. Here i am posting that unfinished work. I will try to cover topics in detail in future .
Obfuscation
To totally obscure with non-germane information in a verbose manner, with the intent to provide a non-answer, and provide total befuddlement.
“Any hacker worth his salt is an artist in obfuscation”.
In network security, obfuscation refers to methods used to obscure an attack payload from inspection by network protection systems.
Encryption vs Obsfucation
Obfuscation
Obfuscation, in general, describes a practice that is used to intentionally make something more difficult to understand. In a programming context, it means to make code harder to understand or read, generally for privacy or security purposes. A tool called an obfuscator is sometimes used to convert a straight-forward program into one that works the same way but is much harder to understand.
Encryption
The manipulation of data to prevent accurate interpretation by all but those for whom the data is intended. Financial institutions use encryption to increase the security of data transmitted via the Internet.
Method of obfuscation
Recreational Obfuscation
There are many varieties of interesting obfuscations ranging from simple keyword substitution, use/non-use of whitespace to create artistic effects.
Obfuscation by code morphing
This is achieved by completely replacing a section of the compiled code with an entirely new block that expects the same machine state when it begins execution as the previous section, and will leave with the same machine state after execution as the original. However, a number of additional operations will be completed as well as some operations with an equivalent effect.
Obfuscation in malicious software
Spammers frequently use obfuscated JavaScript or HTML code in spam messages. The obfuscated message, when displayed by an HTML-capable e-mail client, appears as a reasonably normal message—albeit with obnoxious JavaScript behaviors such as spawning pop-up windows. However, when the source is viewed, the obfuscations make it far more difficult for investigators to discern where the links go, or what the JavaScript code does.
Trail obfuscation
The purpose of trail obfuscation is to confuse, disorientate and divert the forensic examination process. Trail obfuscation covers a variety of techniques and tools that include “log cleaners, spoofing, misinformation, backbone hoping, zombied accounts, trojan command”.
Advantages of obfuscation
Intellectual property protection
Size reduction
Library linking
Disadvantages of obfuscation
When used alone
At best, obfuscation merely makes it time-consuming, but not impossible, to reverse engineer a
program. When security is important, measures other than obfuscation should be used.
Debugging
Obfuscated code is extremely difficult to debug. Variable names will no longer make sense, and the structure of the code itself will likely be modified beyond recognition. This fact generally forces developers to maintain two builds:
Portability
Obfuscated code often depends on the particular characteristics of the platform and compiler, making it difficult to manage if either change
Obfuscation for Evasion
Protection provided by Security devices can be bypassed by obfuscating the exploit/shellcode . Some of the known methods are:
Encoding
Directory traversing
Null characters
Spaces
Security Story is an artifact that anyone (developer, manager, business owner, user, etc ) can read and feel assured that their security concerns are addressed.It is a collaborative effort that highlights how the implementation, application design, service infrastructure, organization processes, and the business environment itself protect what’s important to the business.
There is no fixed format or content for a security story as a security story should evolve over the life of an application. A story may contain text, images, diagrams, spreadsheets, links, and other formats.
security story can be write in many ways most commonly it can start with capturing the concerns of application stakeholders, including both application providers and application users followed by list down the lifelines of the application.You need to create strategy to defend the each lifeline.Build the specific defence and proof of these defenses should be included in story. security stories are not static they has to change when condition changes .
Reference: http://www.ruggedsoftware.org/
Recently one of my friend ask if there is any good reference to to incorporate security testing with agile development. Unfortunately we didn't able to find any such reference.Although Rugged approach look promising and also claim to support agile way of security testing of application. The ultimate goal of including Security testing in SDLC is to produce secure code.
Rugged approach doesn't focus only finding vulnerabilities but try to improve overall capability of an organization to develop secure Code. To achieve this goal organization must establish process to monitor upcoming threats. there should be a communication path so everyone can share all the security-relevant information about the application . A standard mechanism of defence should be use across the organization . Don't trust third party component used in your product, establish guidelines for each component that details the secure use of that library. Build applications that will be largely resistant to the threats of the future for example using strong input validation, in-application attack detection and safe interpreter use can eliminate many flaws forever. Defences should be continuously verified and monitored all the way through development and into production. Being Rugged means that you constantly patch and refactor your software development organization to eliminate the organizational bugs that are causing insecure code.
Reference: http://www.ruggedsoftware.org/
Reference: http://www.ruggedsoftware.org/
Recently i was looking talks on RSA 2012. One talk which got my attention is Adversary ROI: Why Spend $40B Developing It, When You Can Steal It for $1 M. Two points i liked most are
1. The Adversary Doesn’t Care About Your ROI/ROSI.
2. Whatever security measures you put should reduced the the Adversary ROI .
Lets see the formula of adversary ROI
Adversary ROI= ((( Attack value (Value of Assets Compromised + Adversary Value of Operational Impact) - Cost of the Attack) x Probability of Success )/Cost of the Attack)-Deterrence Measures (% Chance of Getting Caught x Cost of Getting Caught)
Most important factor of this ROI is the cost of the attack if your security measures can increase the cost of attack ( which most of the measures do) it will reduce the adversary ROI by multi fold this the area where most of the security vendors focused there effort along with reducing the probability of the success. Advancement of attack tools and techniques reducing the attack cost and increasing the probability of success white hackers/Defenders caught themselves in a rat race to build the countermeasures. As best practice multilayer security (IPS/IDS/Firewall/antimalware)has to be implement to affect these vectors of adversary ROI.
Let say after applying all the measures attacker still able to penetrate your system but if you can be alarmed and act (here your various monitoring system play a great role for example File/Registry/Process Integrity monitoring system, Log Inspection system etc. ) before adversary able to steal/damage your assets this will reduce the probability of success .
What if your assets has been stolen/damaged before you able to act still there is hope in the form of your risk management policy and forensics that can help in recovery and catching your adversary. These two factor increase the chance of catching the hacker.
Now there is one factor which you cannot control directly is the impact of getting caught it’s lot depend of the government/country rules and regulation how they treat your adversary.
while you can reduce the value of assets compromised it’s not always possible and not advisable too but you cannot control the Adversary Value of Operational Impact as it’s depends on type of adversary you are dealing with.
one this should be note here factor affecting adversary ROI should be considered in totality not in isolation.
Reference.
http://365.rsaconference.com/servlet/JiveServlet/previewBody/3429-102-1-4545/GRC-202.pdf
Flexibility over Detailed Processes
Best Practices over Templates
Deployment orientation over Process orientation
Reviews over Quality Assurance (departments)
Business driven over Model driven
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Sql Injection Is the most common vulnerability found in Web applications. whenever i talk about it’s prevention most common answer comes as input validation which is most cost effective and can be implemented without changing the code (using some third party product like WAF,IPS/IDS,Proxies) or without changing the sql statements by implementing such functions' in web application itself. But this is trivial to bypass ( we are living in the world where of hell lot of character encoding are supported) and many time lead to broken applications.
In this article i will try to explore the fixing the problem in it’s root . Modern application has been build using multi-tier architectures and most common architecture is 3-Tier Architecture.
3-Tier Architecture: This involves three layers Client layer, Server layer and business logic tier, service tier or middle tier (layer). In the client-server solution the client was handling the business logic that makes the client “thick”. A thick client means that it requires heavy traffic with the server, thus making it difficult to use over slower network connections like Internet and Wireless .
In 3-tier Architecture, the client is only handling presentation logic. This means that only little communication is needed between the client and the middle tier making the client “thin” . So a typical view would be Client tier <---> Middle tier<---> Database Tier
Many Developer believe that following Secure coding practice for middle tier only will prevent SQL injection which is not always true that we will see in short while.
not let’s have a look of a typical sql injection flaw
Dynamic Queries: The following (Java) example is would allow an attacker to inject code into the query that would be executed by the database. The unvalidated “userName” parameter that is simply appended to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing databases is all too common. this is also know as Dynamic Queries.
String query = "SELECT EmployeeId FROM Employee WHERE Emp_name = " + request.getParameter("userName");
Statement stmt = connection.createStatement();
ResultSet results = stmt.executeQuery( query );
In sql Community to make an sql statement Sql injection proof use of Parameterized Queries is highly recommended.
Parameterized Queries: They are are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.
Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker.For example, if an attacker were to enter the userName of blah' or '1'='1, the parameterized query would not be vulnerable and would instead look for a Emp_name which literally matched the entire string blah' or '1'='1.
String username = request.getParameter("userName");
String query = "SELECT EmployeeId FROM Employee WHERE Emp_name = ? ";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, username);
ResultSet results = pstmt.executeQuery( );
Another benefit of using Parameterized Queries is to get performance enhancements for details Pleas check http://www.simple-talk.com/sql/t-sql-programming/performance-implications-of-parameterized-queries/
Another method that can be use to make your database access Sql Injection proof is to use Stored procedures .
Stored procedures: They have the same effect as the use of prepared statements when implemented safely i.e Stored procedures must not use any dynamic Sql statements. It require the developer to define the SQL code first, and then pass in the parameters after. The difference between prepared statements and stored procedures is that the sql code for a stored procedure is defined and stored in the database itself, and then called from the application. Using this technique requires great interaction between database developer and middle tier developers.
String username = request.getParameter("username");
CallableStatement cstmt = connection.prepareCall("{call getEmpId(?)}");
cstmt.setString(1, username);
ResultSet results = cstmt.executeQuery();
References:
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
http://blog.simcrest.com/what-is-3-tier-architecture-and-why-do-you-need-it/
https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet
http://www.simple-talk.com/sql/t-sql-programming/performance-implications-of-parameterized-queries/
