Trends from the trenches of Internet traffic. Hackers, spammers and Internet abuse. IP address database. DNS sightings. Views and opinions expressed are my own. ~ Teri Radichel @teriradichel
Tuesday, January 30, 2007
Identity Based Encryption
I recently asked Voltage Security about their IBE product to explain some of the problems they would have to overcome to create the encrypted email solution they propose on their web site. Most of their answers sound pretty good, except I still have questions about #5 noted below.
They also sent me a sample message so I could see how their product works. I received a secure message with a graphic button that was blocked by our mail scanning/security products and an attached html file. When I click the button to retrieve the message I have to create a user name and password to read the message and get the private key to read the message. I can see this working for internal organizations but when sending information to potential customers - I can imagine some of them not understanding what this is or being apprehensive about filling something like this out or clicking on an html attachment from a vendor they never heard of or have not worked with before - at least until and unless people get used to this concept. This may be a good solution for internal organizations however, if you trust the vendor of this technology of course and have had your own technical gurus look into the actual details. I am not an encryption expert. I am only looking at the process of getting the mail encrypted from A to B. I cannot say whether the encryption is not decryptable by the company selling it to you, for instance. But here's the scoop on the process:
Once the recipient of an IBE email receives a key they no longer have to get the key for future messages. What happens if they use a different computer?
When a person moves to a different machine, the key is then fetched again from the key server for future and past messages. There is no limit on how many keys one user can fetch as long as they properly authenticate each and every time.
What happens if they log on to web mail on a public computer in an Internet cafe? Is their private key downloaded there for future users of that machine to potentially exploit?
In a public web mail instance, they would be using ZDM, that only caches a stateless cookie that can be set to expire to meet your internal security policies. Also, once an end-user “logs out”, the session cookie is terminated, mitigating any security threat by reading secure email on a public machine. By default, there is a configurable 1 hour session timeout in case the user forgets to logout. Our ZDM cookie security has been fully vetted/tested and is currently in use by several large banks, health organizations and retail companies.
What if someone can steal the private key from the recipient’s machine - since authentication only happens on the first email they could basically read any email after that point if they have the key?
One key is only good for less than 1 week. They would only be able to read secure messages for that one user that fall within that one week session (it’ll most likely be less than half a week). We can utilize any authentication method – email answerback, or one email to prove who you are, is a highly usable, widely used industry standard (see Amazon, Yahoo, Microsoft, banks, etc) but not the most robust authentication standard. We support two-factor authentication, Windows Domain authentication, and different groups of users can be forced to authenticate by different means. The encryption method is tied down to one authentication method, giving you the flexibility to meet your security needs for secure communications.
How does IBE work with email addresses and accounts sending mail from a web server to another address, such as an order receipt?
If you are talking about automated emails, the messages must simply flow through our Voltage SecureMail Gateway, and it will encrypt using the designated recipients individual email address. Nothing special has to happen to encrypt this type of mail flow.
IBE encrypts mail from me to the person I am sending the mail to – what happens when they reply? Is that message sent unencrypted back to me? So if I have my mail encrypted so support people at my mail provider cannot read my outgoing mail, then the customer replies back to me – and my mail is unencrypted coming back from them – so it doesn’t really help? Or…is the mail back encrypted as well even if that person isn’t using IBE?
If they reply to a secure message using our integrated desktop client or ZDM, then you can force the reply or forwarded message to be secure (called “Secure Conversation”). If they don’t ever decrypt the message and simply reply to you, then your message is sent back still in its encrypted form.
My follow up questions to the answer above:
If they do decrypt the message and reply – then is it sent back unencrypted if they are not using IBE themselves or one of your products?
Scenario:
A person comes to our web site and requests product info. We send a secure encrypted message. They are not using any of your products or IBE. They open and read the mail, hit reply and send us back a question. They have outlook or their webmail system set to include the original message in the reply.
Is all our initial information now unencrypted in his reply as it travels back to us? Or once they go through the steps to decrypt the mail are they now using ZDM?
Also what if that ZDM cookie expires? Then when they reply to the message is it sent back unencrypted? Or do they have to log back in each time they read the message to get the cookie?
Hurricane Electric
I have been writing about hackers at Hurricane Electric since the beginning of this blog and their potential connection with a group of hackers in Alaska. More proof:
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/thisdoesnotexistahaha.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/cmd.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/portal/cmd.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/portal/cmd.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/stats/cmd.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/thisdoesnotexistahaha.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/thisdoesnotexistahaha.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/portal/cmd.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/stats/cmd.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/stats/cmd.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/cmd.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Sat Jan 27 21:52:17 PST 2007
216.218.196.210
/cmd.php
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Friday, January 26, 2007
Identity-Based Encryption
This works by authenticating the email recipient based on their email address the first time they recieve an email. They are given a key and after that they can read all emails based on that key.
My questions in this case are (still resarching):
- What if someone steals their private key? Can they read all the email?
- What if the person moves to another machine that does not have the private key - will they be unable to read their mail?
- What if someone logs in at an Internet cafe to read webmail - is the email they download encrypted and will they get a new private key? In this case will the private key potentially be stored on the Internet cafe computer for abuse by future users of that machine?
It sounds really good...but will have to try it out to see if it actually works in all reality. I'll let you know... probably some encryption and verification is better than none but not sure how foolproof this is.
Another interesting idea would be to verify that the person downloading the mail to read it is contacting a server defined in the SPF records for that domain, otherwise the server storing the mail for download is not legit. Haven't thought through how this could be implemented nor do I know if this is already part of SPF, to be honest.
Identity Based Encryption
Addendum:
I did some additional research and got answers to these and other questions in this Identity Based Encryption Post: http://randominternet.blogspot.com/2007/01/identity-based-encryption_30.html
Thursday, January 25, 2007
Storing Credit Cards
http://www.eweek.com/article2/0,1895,2085390,00.asp
There are services that have been in business for years that specialize in keeping this data safe and allow transactions on stored credit card information through PCI compliant mechanisms.
Monday, January 22, 2007
Cybercrime More Profitable than Drugs
Apparently it is true according to a white paper from MessageLabs.
I warned recently of the need for security in programming frameworks, suggesting that just because you are behind a firewall doesn't make you "safe" from all the world.
This whitepaper also hammers this point home talking about phishing attacks. If someone can weasel one piece of spam through and get one of your 800-20,000 employees to click on the wrong link...they may be able to open the floodgate to all your corporate data.
One recent article I read on top security practices suggests encrypting - everything. Hard drives, databases, etc. Plus you need a good key management system in case someone loses their password or means of encryption and needs to reverse it.
But the point here is - email is the doorway hackers are trying to crack. And just becuase you don't see it - think again. They are pretty sly. Virus programs embedded in malware so the more obvious hacks are wiped clean, monitoring logins so when you login they vamoose, using students at Universities, disguising themselves as harmless but annoying bots...
Here's the white paper regarding the latest email attacks and IT security:
http://reg.itworld.com/servlet/Frs.frs?Context=LOGENTRY&Source=eTEXT0104hm&Source_BC=7&Script=/LP/10011793/reg&code=MSGPSA0122
Sunday, January 21, 2007
Google Imposters
64.202.165.132
OrgName: Go Daddy Software
OrgID: GDS-31
Address: 14455 N Hayden Road
Address: Suite 226
City: Scottsdale
StateProv: AZ
PostalCode: 85260
Country: US
NetRange: 64.202.160.0 - 64.202.191.255
CIDR: 64.202.160.0/19
NetName: GO-DADDY-SOFTWARE-INC
72.232.194.66
NetRange: 72.232.0.0 - 72.232.255.255
CIDR: 72.232.0.0/16
NetName: LAYERED-TECH-
NetHandle: NET-72-232-0-0-1
Parent: NET-72-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.LAYEREDTECH.COM
NameServer: NS2.LAYEREDTECH.COM
Comment: Please send all abuse complaints to
Comment: abuse@layeredtech.com
RegDate: 2005-09-07
Updated: 2006-03-07
72.14.75.44
ISP Alliance, INC. ZCORUM (NET-72-14-64-0-1)
72.14.64.0 - 72.14.127.255
Millry.net MILLRY (NET-72-14-75-0-1)
72.14.75.0 - 72.14.75.255
___________________________
66.102.66.148
OrgName: Cingular Wireless
OrgID: CINW
Address: Cingular Wireless, LLC
Address: 12555 Cingular Way, Suite 4360
City: Alpharetta
StateProv: GA
PostalCode: 30004
Country: US
NetRange: 66.102.160.0 - 66.102.191.255
________________________________
66.102.186.15
OrgID: INKG
Address: 177 Wellington Street
Address: Suite 302
City: Kingston
StateProv: ON
PostalCode: K7L-3E3
Country: CA
NetRange: 66.102.64.0 - 66.102.95.255
__________________________________
217.160.230...
inetnum: 217.160.224.0 - 217.160.239.255
netname: SCHLUND-CUSTOMERSdescr: Schlund + Partner AGcountry: US
Saturday, January 20, 2007
Windows Defender - Cool Feature
Windows Defender has a feature that is pretty cool. I don't know if they added it recently or I just missed it but it really helps pinpoint the nitty gritty of your network traffic.
If you do a netstat in a command window you can see a bunch of IP addresses and ports and try to figure out which apps are generating which of those lines of traffic - and it is a pain.
Windows Defender has a section that tells you which programs and services are connected to the network, as well as the end point IPs and ports.
For example you can see a program xyz and the local IP is your local ip address connected on port 52345 and the remote IP is IP 72.34.53.232 (randomly picked this out of my head) on port 80 (which you know means you are connected over HTTP probably to a web site but possibly to something else.
Then you can look up those IPs on DNSstuff.com or in the appropriate databases: arin.net, lacnic.net, ripe.net, apnic.net, afric.net to verify that the process claiming to be the Google Toolbar update checker is really going to a Google IP address.
Pretty cool and much needed...if you've been following this blog for the life of it back to the day when I was complaining about this problem with Windows (and reporting it to a guy that I know is in contact with Bill Gates.) Could I have made a difference? Who knows...I am just happy to see it.
What would be even more useful now (maybe it is there) would be to log all this traffic because I have a feeling hackers are monitoring logins and web sites and they know, for instance, when someone is remotely connected to or logged into a machine, when an app has been updated, and then they wait for you to get off and fire up their nasties. So whenever you look on the machine - it's clean. You never see a problem real time.....so that would be the next logical step. I'll have to do some research to see if it's in there already.
Friday, January 19, 2007
Match.com Scam
So anyway her latest move was to try match.com. She met this "terrific" guy. He sent her a picture - he was a gorgeous black man - supposedly a model from California now on assignment in Africa. Nigeria, to be exact. Anyone involved in Internet security already knows where I am going with this...
He has this match.com profile which is PERFECT. I like walks on the beach, holding hands, watching the sunset...cuddling. Ahem. Ha! I'm cringing as my friend tells me the story...
Within one week my friend's friend is hooked. She thinks he is "the one" and he says he can tell she is "the one" and doesn't want her to talk to anyone else.
...and then it comes...the story...he has these money orders or something that he can't access and needs her to transfer some money...pretty much anyone up on Internet scams knows the routines...
But she is in love. She tells my friend about it and how she's wired this money etc. and how it showed up. Of course my friend is totally freaking about it and like what the hell - don't do it. But her friend is convinced this is a good guy and sure that he must be in love with her and the bank account is real so...she ends up asking someone else who confirms it is a scam and she tells the guys she knows what is going on. And last night I guess they called her twice.
Well I told them to report all of this to the FBI immediately on the Internet crime link...or should it be the CIA as it is international...or both...my friend says "well she reported it to Match.com and his account was somehow closed..." I urged them to report it with any phone numbers they have, etc.
And then my friend asks - so what can you do about these people in huts in Africa - she says she's seen TV shows where they have computers all lined up...what can we do? It's a government thing. There needs to be an international effort to crack down on this stuff. Everyone knows there are so many Internet scams coming out of Nigeria and ripped off software and stolen goods, and hackers in China doing espianage for the government and the Russian mafia stealing credit cards and hacker organizations like Gulli.com and spammers in Brazil. Everyone knows....but is anyone doing anything about it?
And if a doctor like my friend's friend can fall for such a scam....
Hopefully Match.com has some sort of automated program that analyzes content to look for scammer type material but I am not sure how this works with privacy laws. The least they can do is make a HUGE alert on their web site to anyone signing up for and using their account. Obliviously they are not doing that since this person did not see any such warning - or it needs to be more blatant.
Thursday, January 18, 2007
Preventing Zero Day Attacks
This looks promising. Symantec is using brains instead of a database to figure out if software is malicious or not. Something like this is definitely needed - over and above a database approach. It is too easy to change a file name - let's say if you know xyz.exe is a known hack - the hacker can simply post that file all over the place for the unwary user to download with countless other names. Zero day attacks need more than a known list of hacks because their goal is to get out and do damage in one day - before they get into that database. Also with an FBI representative claiming that 15% of the world's computers are hacked and/or controlled by command and control servers doing dirty work - and new hacked servers coming online every day, it is impossible to block out hackers based on IP address or other identifying information alone.
Tuesday, January 16, 2007
Open Resolvers - DNS
http://dns.measurement-factory.com/surveys/openresolvers.html
I have a new client who is coming from one of the companies on this list of known open resolvers:
http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/20060923.html
We shall see if and what problems come out of all of this.
Here is some more technical information about open resolvers:
http://condor.depaul.edu/~jkristof/slides/dns-ctinetseminar.pdf
Wednesday, January 03, 2007
Today's blocked IPs
193.110.140.148
220.181.19.187
38.98.120.70
220.181.19.187
71.13.115.117 (multiple times - reported to network but has not stopped)
220.130.191.239
206.138.130.2
64.229.220.96
88.198.43.39
62.13.25.219
220.181.19.164
216.71.96.94
206.67.139.100
38.98.120.70 (multiple)
38.100.225.5
76.215.57.44