Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

Friday, March 20, 2009

Software Security

In the world of Facebook, E-Commerce and Email; modern threats have emerged exploiting application level vulnerabilities more than ever, A simple bug in a web or desktop application could lead to hundreds thousands dollars loss and sensitive information disclosure. Hence the need for security measures on the application level.

The CuttingEdge Club will organize a two hours session to discover the modern applications threats together with the mitigation techniques, discussing the different activities that should be done throughout the different phase of the software development life cycle to end with a more secure software.

The session will be in Wednesday 25th March, 2009 - 5:30 PM, ITWorx - Free Zone. The speaker is Ahmed Saafan, Information Security Engineer, Raya Security Services.

CuttingEdgeClub is an ITWorx technical seminar club for technology enthusiasts. Its mission is to provide an easy gateway to pertinent and updated technology information for a growing audience in a simple, pragmatic and accessible way.


Wednesday, March 18, 2009

Blocking IP Addresses Using MMC

I was searching for a solution to block any communication with specific IP addresses. I have come to this solution using MMC (Microsoft Management Console). The following steps will allow you to block any communication - whatever the protocol is - with specific IP addresses or subnet:

1. Open Start Manu > Run > Write "MMC". Then press Enter.
2. In the Management Console > File > Add/Remove Snap-in...
3. In the opened dialog, leave "Local Computer" as it's and click "Finish".



4. You will have a new node in the left tree called: "IP Secuirty Policies in Local Computer".
5. Right click on this node and select "Create IP Security Policy".
6. In the opened dialog, write "Block IP".
7. Click Next till the end of the wizard and then "Finish".
8. You will have an item in the left pane called: "Block IP". Right click on it and select "Properties".



9. In the opened dialog, click "Add".
10. Go through the wizard, till you reach a step called: "IP Filter List".
11. Click "Add". IP Filter Dialog will open.



12. Modify the name of your IP Filter and click "Add" to add an IP filter policy.
13. Click "Next. Leave "Source Address" as "My IP Address".
14. In the destination address, you can select "A specific IP Address". You can also filter by DNS or subnet. Enter the IP address to block. Then click Next.



15. Leave the protocol to be "Any" and click "Next".
16. Then click "Finish".
17. Apply all changes, and close all the opened windows. You may have to add "Block" action if it doesn't exist.
18. After you finish, don't forget to write click on "Block IP" policy and select "Assign".



Now try to ping the blocked IP addresses. You should get "Destination Unreachable" message.


Saturday, February 16, 2008

Securing Configurations

Have you ever wanted to provide a level of protection to your values in the configuration files? aspnet_regiis will help you in encrypting the configuration section(s) in your config files. The executable resides in: "<windows_root>\Microsoft.NET\Framework\<framework_version>" and it was common to be used in installing ASP.NET on IIS. However, you can use it as well in encrypting/decrypting the configuration files.

Here is the command line used for encrypting a section in the web.config of SecureWebProj application:

aspnet_regiis.exe -pe connectionStrings -app /SecureWebProj

-pe attribute is used to tell the executable to encrypt the specified section. You can also use -pd attribute instead of -pe if you want to restore or decrypt the section to its original values. -app attribute is for specifying the application virtual path.

After encrypting the connectionStrings section, the web.config will look like that:

<connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>j2E3lO/bMp8ljiDFKhRJu33zVD0mrXD7k5WV4nQ5uNJEav7cKcjhtO1ztCfxJw7ZE5uNdj+THVwJroZBoPEhtPAISPH75Zq
5C1G+5WOLcBwBBzbcp7C6i6U7+/IWmThTNFRAEdQp/lHryDkapep4MNUCGNZlcVLlmX0n/bqZEoE=</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
<CipherData>
<CipherValue>D/Z9ZyH7P+9e3kDi5gLevpdqbjwia0uQ/cOB0gHVXc8=</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20


Sometimes you just need to map the operation direct to the application physical path. This would be useful if you are using ASP.NET Development Server instead of IIS.
aspnet_regiis.exe -pef connectionStrings E:\Projects\SecureWebProj

Encrypting the configuration sections won't prevent you to access the configuration values from your code. If you have already completed the project and you need to encrypt some sections inside the configuration files, you don't have to modify your application code anymore. The code will still run properly and won't be affected by the encryption changes.

The nice part is that you can encrypt the web.config sections even within your code. The following sample encrypts the connectionStrings section in the web.config of SecureWebProj:

Configuration cfg = WebConfigurationManager.OpenWebConfiguration("/SecureWebProj");
ConnectionStringsSection section = (ConnectionStringsSection)(cfg.GetSection("connectionStrings"));
section.SectionInformation.ProtectSection("RsaProtectedConfigurationProvider");
cfg.Save();
1
2
3
4


You may ask: This is an encryption operation, so where the encryption keys? Actually, each .NET installation will create by default a new key container in your machine formally called: NetFrameworkConfiguarationKey. This will contains the needed keys for the providers to work. However, you can create a new key container using aspnet_regiis as well.
aspnet_regiis.exe -pc SecureKeyContainerName -exp

You may find more about securing your key containers in this MSDN entry: Securing ASP.NET Configuration. In the later command line, -exp attribute means that the key container is exportable. You can export this container to XML file and use it in any other machine. This would be useful if your application is running in a web farm and you want to share the encrypted configurations across the farm machines.

DZone


Friday, February 23, 2007

Filtering Procedures.. Do you make it right?

All of us do filtering in their project. It's one of the most repeated functionalities. But do we make it well? How do you make your filtering procedures? Ok.. Have a look on the following one:

CREATE PROCEDURE std_GetFiles
@fileCategory varchar(50),
@tag varchar(50)
AS
declare @SQL as nvarchar(200)

SET @sql = 'SELECT * FROM tscoFileIndex WHERE '

if @fileCategory <> null
set @sql = @sql + ' FileCategory = ' + @fileCategory + ' and '

if @tag <> null
set @sql = @sql + ' tag = ' + @tag + ' and '

SET @SQL= LEFT(@SQL, LEN(@SQL) -4)

GO


This is the first way come to your mind when you trying to do filtering. But take care. Actually, all the string concatenation in this procedure make your data under threaten. As this allow procedure users to inject sql statements inside your concatenated query by passing unexpected paramaters through "fileName" and "tag" inputs. Also the many if conditions here affects your procedure performance.

The alternative, which is better than this, would be something like that:

CREATE PROCEDURE std_GetFiles
@fileCategory varchar(50),
@tag varchar(50)
AS

SELECT *
FROM tscoFileIndex
WHERE (@fileCategory is null OR FileCategory = @fileCategory ) AND (@tag is null OR tag = @tag)

GO


So, you match all rows if the parameter is null, and use the
condition when the parameter is not null.

kick it on DotNetKicks.com


Friday, December 08, 2006

Can You Hear Me Now?


Cell phone users, beware. The FBI can listen to everything you say, even when the cell phone is turned off.

A recent court ruling in a case against the Genovese crime family revealed that the FBI has the ability from a remote location to activate a cell phone and turn its microphone into a listening device that transmits to an FBI listening post, a method known as a "roving bug." Experts say the only way to defeat it is to remove the cell phone battery.

"The FBI can access cell phones and modify them remotely without ever having to physically handle them," James Atkinson, a counterintelligence security consultant, told ABC News. "Any recently manufactured cell phone has a built-in tracking device, which can allow eavesdroppers to pinpoint someone's location to within just a few feet," he added.

References: ABC News


Friday, July 21, 2006

Webservice Authentication

Suppose you have a collection of webservices resides in some server. You would like not to give a public access to these webservices. What shall you do?

Actually, you need some how an authentication mechanism to compromise the accessablity. One soultion would be to make an authentication webservice. Any client wants to access your webservices, should call it first. This webserice simply will take 2 parameters: username and password. The return value would be a hashcode.

This hash code could be used afterward in accessing any other webservice. The interfaces for example for your webservices could be something like that:

[C#]

string wsAuthenticate(string username, string password)
string wsAnyOtherWebservice(string accessCode, ... )

As you see, the returned hash code (access code) form wsAuthenticate will be used in accessing the other webservices and the client will not be able to get the service unless he have an account in your system.


Monday, April 10, 2006

SQL Injection - Part 2

In part 1, we discussed a simple methodology in using SQL injection to break a security point in web applications. Actually, this was the simplest way. As you know more about the generated errors of the different database engines, you will do better with SQL injection.

Some methods of SQL injection, depends on how you can inject some SQL statement in the page parameters, to gain usefull errors! .. So funny, aha! Actually, these errors gives you some usefull information about the inner structure of the victim database. This will help in making greater destruction!

One of the SQL injection methods is to concatenating "Having" statement in your query string. As we know, "Having" is used alwayes with "Group by" statement to inforce some condition on the grouping SQL statement. But if the "Having" is inserted in a sql statement without "Group By" we get a horrible error!

Suppose we have web page which displays products for a certain category. For example, our page url is something like that:


http://online-store.com/products.aspx?catID=1

The previous url will get all the products of the category that have ID = 1. Now, lets playing with this url and make the following trick:


http://online-store.com/products.aspx?catID=1 having 1=1 --

When submitting the previous url, the resulting page will display an error like that:


Microsoft OLE DB Provider for SQL Server (0x80040E14)

Column
'products.ID' is invalid in the select list because it is not contained in an
aggregate function and there is no GROUP BY clause.

/products.aspx, line 24
SQL Server tried to execute the following SQL statement after injecting our "Having":


select * from products where catID=1 having 1=1 --

As you see, we have "Having" without "Group By". And in a SQL statement with "Group By" and "Having", all the columns after "SELECT" should be in the "Group By" clause. So, the db engine didn't find the first column which is "products.ID" in the "Group By" clause and throw this error.

Actually, we got two usefull infomration from this later error. The table name - "Products" and a column on it - "ID" column.

Now, Try to add the "ID" column after a "Group By" clause in the url:


http://online-store.com/products.aspx?catID=1 Group By ID having 1=1 --

You get the following error:


Microsoft OLE DB Provider for SQL Server (0x80040E14)

Column
'products.Name' is invalid in the select list because it is not contained in an
aggregate function and there is no GROUP BY clause.

/products.asp, line 24

You got the idea, aha! .. You have now another column name in the table. You just go on with this trick until you got all the table columns!

Suppose, now you discovered that the "Products" table contains only 3 columns "ID", "Name", and "Description". And on a way or another you got that the site users are stored in a table called "users". Well, try to make the following trick. Inject a UNION statement in your url so that, you view products data followed by users data. Cool, isn't it?!


http://online-store.com/products.aspx?catID=1 UNION SELECT 1, username, password FROM users --

Now, you got a list of the products, followed by all the site users with their passwords!

Actually, you can be more destructive by executing some harming SQL statements. For example, you can make something like that:


http://online-store.com/products.aspx?catID=1; drop table users;

Some database engines like SQL Server support such kind of SQL queries. You execute two or more queries in one time. Now, your victim loses his users table!

Also, you may execute some built-in stored procedures which exists in SQL server:


http://online-store.com/products.aspx?catID=1; exec master..xp_cmdshell
'iisreset'; --

This was a short tour in exploring SQL injection.


References


SQL Injection - Part 1

Security .. This word repeated regularly when taking about critical applications. Actually, security is one of the most important aspects in developing applications, especially, web applications. Why? Because, web applications has a very unique property .. "It's a public application!". This means many people have access to your application, many people has access to your services. And as long as the accessibility increase, threatens also increase.

SQL Injections is one of the simplest and popular attacks on the net. However, it needs somehow experienced attackers in SQL and database engines.

Dynamic web forms usually receive parameters and according to these parameters the web-form rearrange its behavior and layout. Parameters are sent to the web-forms through HTTP using one of the two methods: GET or POST - Actually explaining these methods is out of our scope here.

For example, using GET method, we can send parameters to the web form like:


mydomain.com/Login.asp?username=nour&password=mypass

As shown, the "Login" page receives two parameters: username and pass. In your login page, you may check the credentials of the user using a SQL statement like that:

sql = "SELECT username, password FROM users WHERE username=" & username
& " AND password=" & password


Suppose that our lovely attacker now try to play with this login page. He will simply pass the parameters to this web-form as following:

mydomain.com/Login.asp?username=nour&password=mypass or 1=1

Actually, if this login page is for an administration page, for example, then you're in a critical situation! Why? .. The "password" parameter is now "mypass or 1=1". And after concatenated with the SQL statement in our page, the SQL statement will be like that:

SELECT username, password FROM users WHERE username=nour AND password = mypass or 1=1

As you can see, the WHERE condition will not return only one record. Actually, it will return all users records in your system. A great disaster! . So, if your authentication method is built on this query, it will return always results and any user can access it regardless of the given password! Actually, this is a simple demonstration of what can be done with SQL injection.

Wait for more in Part 2...


References