|
Written by Dave Smith
|
|
Sunday, 14 February 2010 20:11 |
|
In continuation of our summary and recap of Shmoocon, here is a link to the mobile security talk that we referenced in the previous blog posting:
http://www.vimeo.com/9303379
And of course, on novcon.TV here
It is a fascinating talk that will make you think twice about a lot of your habits and behaviors and how you think about mobile security and your phone. Shmoocon had a lot of eye-opening information this year, and this talk is certainly worth checking out.
|
|
Last Updated on Sunday, 14 February 2010 20:28 |
|
Written by Dave Smith
|
|
Thursday, 11 February 2010 21:01 |
|
We're back from Shmoocon 2010, with much learned. The nature of the threats to our security is a constantly changing dynamic, and the conferences are a great way to link up with great minds in the field to get a better understanding of that dynamic. It has always been my view that security is relative. A lock's purpose is not to keep something protected against any possible thief, but rather to slow the thief down and disrupt their cost/benefit ratios. The same applies in information security. There is no absolute security, but there are certainly precautions and behaviors that make you a harder target than the next guy.
P2P and Social Networks are two major risks to the average user when not properly used. For P2P, see George's article on the dangers of default sharing settings. For social networks, it's far too easy and too tempting to hit that "allow/accept" button for a person who wants to be your friend that you are not sure you know, or for the latest game that all of your friends are playing.
At the conference we heard about the dangers of both. From pulling personal information from profiles that accept you, to applications and games, even social iphone games that allow you to be tracked everywhere you go in the real world. The scary part is that these are the exploits we hear about, not the countless ones we haven't yet heard about.
We heard that windows servers using certain web services, in an attempt to be helpful, will pass windows filename pseudonyms from a request through to the OS. This effectively bypasses access control, mime-type parsing definitions, and other protections.
We heard that it's not just the bugs and vulnerabilities of an application that make it dangerous, but sometimes the application's features themselves are the biggest threat. Features designed without fully understanding their impact on the security of the application, its data, or its users allows for new vectors of attack.
So how do you protect yourself against vulnerabilities that cannot be patched?
The basics cannot be stressed enough.
P2P networks
George summed it up pretty well in his article. Also see the article in CSO Online about the talk from Shmoocon.
Social Networks
For all your social networking activities, be very careful who you share your information with. Do not friend people you do not know, if you plan on sharing personal information, photos, etc.
Security vendor Sophos did a study a couple years ago on users and identity information. For the study they created a fictitious facebook profile with the profile picture of a plastic frog and requested 200 users to friend them. 87 friended the plastic frog, many of whom exposed personal information such as birthdate, address, phone numbers and employment/education histories.
Unfortunately it's not just about vetting your friends. Applications and games can access your profile information, and not all developers are angels. Many game developers' revenues are based on getting you to click on ads, give your personal information to survey and marketing firms, etc. And some are more malicious than that.
Also see our article on basic computer security for more information on the dangers of social networks.
Location Based Games and Services
I think this one should be fairly obvious. If you play a location based game on your iphone or other smart/connected device, you are handing over your real-time location to people you have not met. The implications of this were made very clear at a talk at Shmoocon where users' daily lives could be seen as mapped out data on Google Earth.
For the Admins
It is very, very important to stay on top of what the current attack trends are. As is the case in the windows file pseudonyms vulnerabilities discussed at Shmoocon this year, the attacks do not have to be extremely high tech, and the exploited vulnerability does not have to be some brand new bug. Some of our biggest vulnerabilities are bigs that have existed since the beginning of an application or platform. Keeping on top of patches is not enough. Knowing how to quickly detect and respond to the very latest threats requires knowing about and understanding those threats. Be active in the community.
Security takes all of us.
|
|
Last Updated on Saturday, 13 February 2010 20:12 |
|
Written by George Edgar
|
|
Friday, 05 February 2010 22:37 |
|
For those of you out there that are using P2P software to download music and share your files: please go and check what directories you are sharing. Until today, I did not realize just how many people share out C:\. For those of you that do not know, this shares out your entire hard drive partition. If you insist on using P2P software then create a new folder and only share that folder. P2P software can be very dangerous. Just about everybody does their taxes on their computer and saves their files in "My Documents". Unfortunately, the defaults of many P2P applications share out this folder. This is identity theft waiting to happen. So go and check what you are sharing out and do not open executables, PDF's, or other files from any unknown source, from P2P, Email, or any other method.
|
|
Written by Dave Smith
|
|
Tuesday, 12 January 2010 19:13 |
|
As an addendum to the previous article on storing IP Addresses as IP Numbers in SQL, we would like to show the same process, but in fully 32bit storage. The reason we chose to store a 32 bit IP address in a 64 bit integer (bigint) column is because there is not an unsigned integer type in MS SQL Server at this time. However, using a technique mentioned by Charles Bretana here, we can still store an IP address in a 32 bit column. This reduces the bytes required for storing IP addresses 50%.
The method simply involves taking a 32bit unsigned (positive only) integer and subtracting 2,147,483,648 to ensure that you are within a 32 bit signed integer range.
The scripts below are modified using the method described above.
Function 1: Converting an IP Address to an IP Number
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: NovCon Solutions
-- Create date: 1.10.2010
-- Description: Get IP Number from IP Address
-- =============================================
CREATE FUNCTION [dbo].[numFromIP] (
@ip VARCHAR(15)
) RETURNS INT
AS
BEGIN
DECLARE @rv INT,
@rvTemp BIGINT,
@o1 BIGINT,
@o2 BIGINT,
@o3 BIGINT,
@o4 BIGINT
SELECT
@o1 = CONVERT(BIGINT, PARSENAME(@ip, 4)),
@o2 = CONVERT(BIGINT, PARSENAME(@ip, 3)),
@o3 = CONVERT(BIGINT, PARSENAME(@ip, 2)),
@o4 = CONVERT(BIGINT, PARSENAME(@ip, 1))
IF (@o1 BETWEEN 0 AND 255)
AND (@o2 BETWEEN 0 AND 255)
AND (@o3 BETWEEN 0 AND 255)
AND (@o4 BETWEEN 0 AND 255)
BEGIN
SET @rvTemp = (@o1 * 16777216) +
(@o2 * 65536) +
(@o3 * 256) +
(@o4)
Set @rvTemp = @rvTemp - 2147483648
set @rv = @rvTemp
END
ELSE
SET @rv = -1
RETURN @rv
END
GO
Function 2: Reversing The Process
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: NovCon Solutions
-- Create date: 1.10.2010
-- Description: Get IP Address from IP Number
-- =============================================
CREATE FUNCTION [dbo].[ipFromNum]
(
@ipnumIn int
)
RETURNS varchar(32)
AS
BEGIN
Declare @ipNum bigint
DECLARE @ipAddr varchar(15)
DECLARE @binString varchar(32)
DECLARE @counter tinyint
set @ipNum = @ipnumIn + 2147483648
set @counter=32
set @binstring = ''
while (@counter > 0)
BEGIN
select @binstring = convert(char(1),@ipnum % 2) + @binstring
select @ipnum = convert(int,(@ipnum/2)), @counter=@counter - 1
END
Select @ipAddr=dbo.decFromOctet(subString(@binstring,0,9)) + '.' +
dbo.decFromOctet(subString(@binstring,9,17)) + '.' +
dbo.decFromOctet(subString(@binstring,17,25)) + '.' +
dbo.decFromOctet(subString(@binstring,25,33))
RETURN @ipAddr
END
GO
Function 3: Converting an Octet into its Decimal Value
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: NovCon Solutions
-- Create date: 1.10.2010
-- Description: Convert binary octet to decimal value
-- =============================================
CREATE FUNCTION [dbo].[decFromOctet]
(
@octet varchar(8)
)
RETURNS varchar(3)
AS
BEGIN
DECLARE @decValue int
declare @powerChars char(2)
declare @index smallint;
set @decValue = 0
select @powerChars = '01',@index = 0
while(@index < 8)
BEGIN
select @decValue = @decValue + Power(2,@index) *
(CHARINDEX (SUBSTRING(@octet, 8 - @index, 1)
, @powerChars) - 1
), @index = @index + 1
END
RETURN convert(varchar(3),@decValue)
END
GO
|
|
Last Updated on Wednesday, 13 January 2010 20:41 |
|
Written by Dave Smith
|
|
Monday, 11 January 2010 22:03 |
|
While using the GeoIP tables from MaxMind, we found it useful to create a few SQL functions. To use the data, you have to convert an IP address into and IP number that you check against a list of ranges to determine a location code. The query and algorithm used to generate the ip number from an ip address is somewhat well documented. The primary example is on MaxMind's own website here.
While working with the data, we thought about how storing ip addresses in this way would both save space and optimize indexing and search queries. To store an IP address in a sql table, you would normally need 15 bytes for the 15 possible characters. This is both a lot of space, as well as a variable length field which is not desirable for best practices in table optimization.
At novcon, we store the ipnumber ranges in bigint columns, taking up just 8 bytes of storage each, instead of 15. While this sounds like a great way to store every ip address in every SQL table we have, the problem comes when you want to reverse the process and convert the network number to an ip address.
The same algorithm that was used to create the ip number from the ip address is not able to be easily reversed. We were unable to find any other examples of reversing the number back to an ip address in the searches we did.
So like any good hacker, we wrote our own....
We are including the three functions we use for the entire process below.
Function 1: Converting an IP Address to an IP Number
This process is fairly well documented, and the function below is merely our version of the MaxMind function, with very little modification.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: NovCon Solutions
-- Create date: 1.10.2010
-- Description: Get IP Number from IP Address
-- =============================================
CREATE FUNCTION [dbo].[numFromIP] (
@ip VARCHAR(15)
) RETURNS BIGINT
AS
BEGIN
DECLARE @rv BIGINT,
@o1 BIGINT,
@o2 BIGINT,
@o3 BIGINT,
@o4 BIGINT
SELECT
@o1 = CONVERT(BIGINT, PARSENAME(@ip, 4)),
@o2 = CONVERT(BIGINT, PARSENAME(@ip, 3)),
@o3 = CONVERT(BIGINT, PARSENAME(@ip, 2)),
@o4 = CONVERT(BIGINT, PARSENAME(@ip, 1))
IF (@o1 BETWEEN 0 AND 255)
AND (@o2 BETWEEN 0 AND 255)
AND (@o3 BETWEEN 0 AND 255)
AND (@o4 BETWEEN 0 AND 255)
BEGIN
SET @rv = (@o1 * 16777216) +
(@o2 * 65536) +
(@o3 * 256) +
(@o4)
END
ELSE
SET @rv = -1
RETURN @rv
END
GO
Function 2: Reversing The Process
This function is responsible for converting an IP number back into an IP address. The process starts by translating the bigint value into a string of 32 binary digits. These digits are broken up into the 4 octets of an IP address. Each set of 8 digits is sent to another function we wrote (below) to convert the octet from base 2 to decimal.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: NovCon Solutions
-- Create date: 1.10.2010
-- Description: Get IP Address from IP Number
-- =============================================
CREATE FUNCTION [dbo].[ipFromNum]
(
@ipnum bigint
)
RETURNS varchar(32)
AS
BEGIN
DECLARE @ipAddr varchar(15)
DECLARE @binString varchar(32)
DECLARE @counter tinyint
set @counter=32
set @binstring = ''
while (@counter > 0)
BEGIN
select @binstring = convert(char(1),@ipnum % 2) + @binstring
select @ipnum = convert(int,(@ipnum/2)), @counter=@counter - 1
END
Select @ipAddr=dbo.decFromOctet(subString(@binstring,0,9)) + '.' +
dbo.decFromOctet(subString(@binstring,9,17)) + '.' +
dbo.decFromOctet(subString(@binstring,17,25)) + '.' +
dbo.decFromOctet(subString(@binstring,25,33))
RETURN @ipAddr
END
GO
Function 3: Converting an Octet into its Decimal Value
This function is based on a baseN conversion function written by D. Patrick Caldwell It's purpose is simply to convert the string of 8 binary digits to its decimal representation.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: NovCon Solutions
-- Create date: 1.10.2010
-- Description: Convert binary octet to decimal value
-- =============================================
CREATE FUNCTION [dbo].[decFromOctet]
(
@octet varchar(8)
)
RETURNS varchar(3)
AS
BEGIN
DECLARE @decValue int
declare @powerChars char(2)
declare @index smallint;
set @decValue = 0
select @powerChars = '01',@index = 0
while(@index < 8)
BEGIN
select @decValue = @decValue + Power(2,@index) *
(CHARINDEX (SUBSTRING(@octet, 8 - @index, 1)
, @powerChars) - 1
), @index = @index + 1
END
RETURN convert(varchar(3),@decValue)
END
GO
We think these functions make it possible to store all IP address information as a consistent and standard decimal representation, saving both space and time. We hope you find them useful. We would like to thank MaxMind and D. Patrick Caldwell for their existing work that is the basis for these functions.
NovCon Solutions is available for SQL Optimization Consulting. For more information please call 1.877.887.4041 or email
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
.
|
|
Last Updated on Wednesday, 13 January 2010 19:12 |
|
Written by Robert Clowser
|
|
Wednesday, 30 December 2009 17:00 |
|
SSL And You by Robert Clowser (
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
) and David Smith (
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
)
What is SSL?
SSL, Secure Socket Layering, is the most common way of encrypting and verifying traffic on the internet. SSL can be used to secure websites (HTTPS), email (SMTP), chat (XMPP), and others. In this post, we will try to explain SSL (both pros and cons) in an attempt to help people understand the mysteries of the internet.
The most important thing to know about SSL is that SSL is based on trust.... The user must trust that the Certificate Authority (company that gives out the certificate) is legitiamet and responsible. Anyone can create a certificate authority (CA), it's nothing special, but modern browsers are set to trust only certain CA's by default, these include Verisign, Thawte and others to name a few.
What happens?
When you browse to a website using a SSL certificate, the most obvious change is the protocol changes to HTTPS from HTTP and you will see a yellow padlock somewhere in the browser. But what is going on behind the scenes is slightly more complex. Firstly, your internet browser makes a request for an encrypted encrypted connection. The server responds with the highest common encryption protocol (think "we can both speak this language"). The server then transmits it's digitial certificate to the client, (think "this is who I am"). The client computer then checks with the CA to make sure they haven't revoked the certificate (think "is this still valid"). If this check is successful and the other information in the certificate matches. A secure connection is established using random numbers to encrypt the traffic. What's bad about it?
As stated, SSL is about trusting the Certificate Authority (CA), if they are not trustworthy then you can create a encrypted connection to a malicious computer without knowning it. With that said, even having trusted Certificate Authority's doesn't solve all the problems with SSL. SSL that uses short encryption keys or outdated algorithms (MD2/MD5) are succeptable to brute force attacks (think "short passwords are bad"). What should I do?
Any security (encryption) is better than no encryption. Use HTTPS (SSL) whenever possible when browsing websites. If the browser alerts you to a certificate mismatch, pay attention to what it's saying (don't just click ok!). If your bank or sensitive information does not have SSL, request it from them! Above all else, use common sense (just like the real world.)
|
|