[Snort-sigs] Signature for credit card numbers

Cove Schneider cove at ...1957...
Fri Oct 10 10:17:09 EDT 2003


On Thursday, October 9, 2003, at 08:58 PM, Paul Tinsley wrote:

> Cove Schneider wrote:
>
>>
>> On Thursday, October 9, 2003, at 02:47 PM, Sean Perry wrote:
>>
>>> Cove Schneider wrote:
>>>
>>>> Hello,
>>>> Has anyone attempted to make any signatures to try and catch credit  
>>>> card numbers? e.g. someone sending a CC number in an email, via  
>>>> FTP, P2P etc... Sending them insecurely, or even malicious  
>>>> intent... I'm interested in verifying that this isn't going on, of  
>>>> course.
>>>> Anyone have any thoughts on this?
>>>
> What you are trying to do IMHO is WAY too intensive, CC numbers are  
> not all the same length or in the same ranges, and lets

I'm using a 1.2Ghz PIII, RedHat 9, with a somewhat limited rule set,  
traffic ranges from 500-18000 pkts/sec and the load is always under  
1.0. Maybe regex matches would kill it, I don't know. There is also  
PCRE, which I've heard is supposed to be quite fast. See:  
http://www.pcre.org/

>  not even get into the fact that trying to find it in web based  
> traffic as alot of people split out the parts of the CC if they know  
> you are entering a MasterCard or Visa.  So you would have to look for  
> var1=4451&var2=2033&var3=0111&var4=0000 to find a MasterCard  
> transmitted from a split entry form... Not very feasible.  So lets  
> forget the split type and worry just about the one text field style  
> websites, will the user enter it as 4451 2033 0111 0000 or  
> 4451203301110000 or some variation in between?

Good point. I'm really looking to just catch dumb stuff so I can head  
off potential problems before someone with malicious intentions could  
take advantage of it. If the data is encrypted, then it's probably  
legit. Though sending a/many CC number(s) in clear-text, for example,  
seems pretty suspicious to me. I suppose a malicious hacker with enough  
wits about her would encrypt her CC number transfers when stealing  
them, though depending on the exploit used this may also not be an  
option. Hard to say...

> Don't get me wrong I think it would be neat to have such matching  
> inside of snort but to do it right would probably take snort to it's  
> knees (not implying another software IDS would do better.)  Hey...  
> there you go get somebody to cook you up a credit card recognition  
> ASIC :)
>

They may exists actually. ;-)

>>>
>>> Well, let's see.
>>>
>>> A credit card number is 16 digits long (at least here in the US,  
>>> maybe not elsewhere).  The first number is 3 (amex),4 (visa),5  
>>> (master) or 6 (discover).
>>
> Just for an idea of the types that Business::CreditCard  
> (http://www.cpan.org/authors/id/I/IV/IVAN/Business-CreditCard- 
> 0.27.readme) is aware of:
>    return "VISA card" if $number =~ /^4\d{12}(\d{3})?$/o;
>    return "MasterCard" if $number =~ /^5[1-5]\d{14}$/o;
>    return "Discover card" if $number =~ /^6011\d{12}$/o;
>    return "American Express card" if $number =~ /^3[47]\d{13}$/o;
>    return "Diner's Club/Carte Blanche"
>      if $number =~ /^3(0[0-5]|[68]\d)\d{11}$/o;
>    return "enRoute" if $number =~ /^2(014|149)\d{11}$/o;
>    return "JCB" if $number =~ /^(3\d{4}|2131|1800)\d{11}$/o;
>    return "BankCard" if $number =~ /^56(10\d\d|022[1-5])\d{10}$/o
>

Cool. Thanks.

>>>
>>> So you need something that matches (in perl style regex):  
>>> '[3456]\d{15}' or '[3456]\d{3}(?:-\d{4}){3}'.  This covers the  
>>> dashed notation as well as the all scrunched style.  If they do  
>>> '3456 5678 ...' it won't catch them.  The second regex could be  
>>> replicated for this though.
>>>
>>> That is a good start.  You could get fancy is you knew the algorithm  
>>> used to make the card numbers.  Also, American Express may not be 16  
>>> digits, I forget.  I know the other 3 always are.
>>
> http://www.beachnet.com/~hstiles/cardtype.html
>
>>>
>>
>> Thanks for the info. I haven't read up enough on snort rules, does it  
>> support regex?
>>
>>
>> Cove
>
> P.S. - Don't try that credit card # at home kids, it doesn't pass the  
> LUHN check.
> P.P.S - Brian the link in your reply is 404
>





More information about the Snort-sigs mailing list