Transcript Powerpoint - Particle Physics Group

What to trust on the Net?
or
o
smisfrom
LLosBnkwn'm
nosomr
Andrew McNab
Outline
●
●
●
●
●
●
4 April 2006
IP - the Network itself
DNS - names like “lloyds.com/”
Web - http://vvv.lloyds.com/e-banking/
Signed objects – like signed emails
“Provenance” and authority
Social Engineering
Andrew McNab – Trust on the Net
IP Addresses
• Internet Protocol (IP) is the standard for moving
packets of data around the Internet
• Each node has its own address, like 192.168.0.9, and
addresses are grouped into subnets, like 192.168.0.*
• Subnets generally correspond to a particular local
network, so 192.168.0.* might be your network at
home, or the network for one building.
• Each packet has its source and destination addresses
written in its header.
4 April 2006
Andrew McNab – Trust on the Net
IP security
• The limitation with IP is that there is no authentication or
authorization built into the system:
– If you're physically on the network, you can send
packets
• Some sites (including us) put limits on what you can do
based on IP address (eg access local web pages.)
• However, an attacker can defeat this if:
– they can get on the local network (eg with a notebook,
or by getting on a wireless part of network)
– find a vulnerability in the router(s) which pass IP
packets on to the right internal or external subnets.
4 April 2006
Andrew McNab – Trust on the Net
IP solutions
• Strong physical security – eg in a machine room
• Use WPA encryption of wireless access
• Limit access to network cards with one of a list of
valid hardware MAC addresses, set in the factory
– numbers like 00:45:8F:4D:92:AB
– every device has one, but some allow users to
change the MAC in software
• Push the security problem to a higher layer...
– IPSec – IP over an encrypted channel
– Secure the protocols that run on top of IP
4 April 2006
Andrew McNab – Trust on the Net
DNS
• The Domain Name System (DNS) maps human friendly
names like www.amazon.com to the IP numbers the
network really uses.
• Can use DNS names and domains to limit access to services
– “Only machines in *.cern.ch can see this page.”
– But this has the same problems as IP based restrictions
like 192.168.0.*
• Furthermore, users contact DNS servers to find services
which they trust: so attacking DNS servers is a problem.
4 April 2006
Andrew McNab – Trust on the Net
DNS server attacks
• For example, to make www.lloyds-bank.com point to my
notebook rather than their server
• Most DNS servers use the same program, BIND, and
vulnerabilities in this are regularly found
– so maybe I can hack the user's local DNS server, and
make it lie about www.lloyds-bank.com
• It's possible to misconfigure DNS servers to allow attackers
to inject fake data (ie pretending to know the truth about
where www.lloyds-bank.com is)
4 April 2006
Andrew McNab – Trust on the Net
DNS solutions
• Use DNS-Sec
– Provides a way of using digital cryptography to sign
responses from DNS servers
– Not at all universally deployed, which is necessary
for it to work for “random” sites
– Can help with securing local “friendly” DNS servers
against data injection attacks, but requires
manually setting up private keys
• Push the security problem up to a higher level...
4 April 2006
Andrew McNab – Trust on the Net
Public/Private Keys
• Public Key Cryptography is a crypographic technique which
uses the products of large prime numbers
– since it is a hard problem to factorise such products, we
can publish the product without immediately revealing
the prime factors
• Using that asymmetry, it's possible to build systems where
I sign (~ “encrypt then hash”) a message using my private
key, and where you can verify the signature using my
public key (which you know) but you can't sign it “as me”
just with my public key
4 April 2006
Andrew McNab – Trust on the Net
ssh
• Secure Shell (ssh) allows you to get command line access
to your account on another Unix machine
• The “secure” part comes from using digital cryptography
to establish trust (and encrypt the messages.)
• An ssh server creates a public and private key pair
– when you ssh to a machine, you're told it's public key
and get the “The authenticity of host can't be established. Are you
sure you want to continue connecting (yes/no)?” message
– If you're feeling trusting today, you say yes.
– ssh warns you if the public key change in the future
4 April 2006
Andrew McNab – Trust on the Net
ssh problems
• First problem how to decide whether to trust a new
machine
– how do you know?
– sometimes machines are reinstalled, the keys are not
saved and new ones are generated
– or has the box been unplugged and replaced with a
notebook today?
• Secondly, ssh allows user keys instead of passwords too
– great, no more passwords to steal
– not so great, can now steal ssh keys out of $HOME/.ssh
– if I can do that at CERN, I can get into lots other sites
4 April 2006
Andrew McNab – Trust on the Net
too
The Web
• We all know what this is!
• Web servers host pages/files; identified by DNS names
– so the same DNS and IP problems as before
– HTTP protocol is used to request pages/files
• “how do I know I'm really talking to Lloyds Bank?”
– If the URL is like http://www.lloyds-bank.com/
then you don't!
– If the URL is like https://www.lloyds-bank.com/
and your browser has the “padlock” icon showing,
then you probably do.
4 April 2006
Andrew McNab – Trust on the Net
HTTPS
• HTTPS is in effect “HTTP over ssh”
– In fact the SSL layer used by ssh was originally
developed for HTTPS
• Requests and responses are encrypted
– so harder for eavesdroppers to steal your credit
card number
• Like ssh, uses public/private keys to establish the
authenticity of the web server
– but unlike ssh, they're not created by the web
server
4 April 2006
Andrew McNab – Trust on the Net
Certificates
• Public Key Cryptography allows us to sign “things”, in a
way that other people can verify
– This means a trusted third party (TTP) can sign a
server's public key
– The TTP can vouch for the authenticity of any name
associated with the public key
– In practice, Certification Authorities issue signed public
keys (“certificates”) with DNS names
– By trusting a few CAs, I can trust 1000s of certificates
• CAs exist both commercially (Verisign, BT etc) and in
research projects (UK e-Science CA)
4 April 2006
Andrew McNab – Trust on the Net
HTTPS + certificates
• Certificates make HTTPS one of the most reliable security
systems in production on the Net.
– So they're the basis of authentication on the Grid too
– Can also be used to identify users to servers: signed user
certificate instead of private ssh key
• But the certificates still just authenticate: they don't tell
you whether you can trust www.LL0YDS-BANK.com, just
that the server is run by the owner of ll0yds-bank.com.
• So we push the problem up a level again, and manually
squint at URLs to see if they're faked...
4 April 2006
Andrew McNab – Trust on the Net
Virtual Organisations
• There isn't really a solution for this in the Web world yet
– people have to rely on “brand image”
– look carefully for odd spellings (“0” not “O” etc)
• Within the Grid, we've faced the problem of how services
authorized users
– not user who a user is, but are they really a current
member of ATLAS?
– this offers some solutions: we give users short-lived
Attribute Certificates saying they're in ATLAS and what
roles and groups they're in
• The UK FSA could do the same for UK Banking websites...
4 April 2006
Andrew McNab – Trust on the Net
Email
• In terms of security, email really is a mess!
– it was designed to operate on a private Internet run by
universities and labs
• Spam is largely a result of the unaccountability of sending
email, since it can be very hard to determine who sent it
• Lots of solutions have been proposed
– they either involve putting limits on who can send email
– or don't have much effect until everyone adopts them
• Digital Certificates could play a part in this, but that would
require most people to go and buy a commercial certificate
4 April 2006
Andrew McNab – Trust on the Net
PGP and S/MIME
• PGP is a Public Key Cryptography system that can be used
for emails, and in practice it works more like ssh keys than
certificates
– need to establish bilateral trust between you and your
friends (or friends of friends)
– so not very scalable
• S/MIME is IETF standard for signing emails with certificates
– the same kind of certificates used for WWW and Grid
– but UK e-Science CA certificates can't be used this way,
since they don't contain the users email address
4 April 2006
Andrew McNab – Trust on the Net
Other signing
• Signing can also be used for programs you might download
and install
– this again is widely implemented, like S/MIME, put not
widely deployed in practice
• It's use is limited because of the cost associated with being
checked out to get a signing certificate
– also works against Open Source software projects
– and smaller software companies
• There's no reason why you can't sign really important
software/emails, and let people check them manually
4 April 2006
Andrew McNab – Trust on the Net
Phishing
• One major abuse of email's lack of security is Phishing
• This involves sending unsolicited email claiming to be an
official notification from the user's bank, PayPal, eBay etc.
– Huge numbers of these are sent out: if everyone gets an
email from Lloyd's Bank, it will be right for 15% of
people
• The email often tries to scare the user into following a link
embedded in the email: “Account closure notice” etc etc
– the link goes to the attacker's site, using one of the
techniques mentioned already
– the fake site invites the user to reenter their
password...
4 April 2006
Andrew McNab – Trust on the Net
Social Engineering
• Phishing is an automated form of the “ancient” hacker
technique of “Social Engineering”
– ie talking people into doing things that let you break in
– The “ph” comes from Phone Phreaking – which involved
hacking ATT's telephone network, and often required
pretending to be a telephone engineer
• One of the problems of network security is the tendency to
“push the problem up to a higher level”.
• Eventually, The Highest Level is a human, and we're much
worse at following security procedures than computers
4 April 2006
Andrew McNab – Trust on the Net
SE examples
• “The Art of Deception” by Kevin Mitnick features a
collection of social engineering stories, and ways to
counteract them
• These are especially a problem in big organisations,
because you're used to dealing with strangers who are
nevertheless members
– so CERN, visiting other institutes, dealing with the
University administration here
• Basic technique is to use publicly available details to
create confidence, and extract more sensitive information
– Never give out “numbers”
to strangers...
Andrew McNab – Trust on the Net
4 April 2006
The Network Outage
• (Phone calls adapted from Mitnick's book)
• Attacker: “Hey, Tom, this is Eddie Martin on the Help Desk. We're
trying to troubleshoot a network problem. Have you seen any
problems today?”
• Tom: “Uh, not that I know of.”
• Attacker: “Ok, but call if it does.”
• Tom: “You better believe it!”
• Attacker: “Sounds like it would be a problem. Call me on my cell
phone 555-567-7890 if it happens. What's your network socket
number, just in case...”
4 April 2006
Andrew McNab – Trust on the Net
Network Outage (2)
• (The Next Day – call to the network operations room)
• Attacker: “Hi, this is Bob, I'm in Tom DeLay's office in
Bookkeeping. We're trying to troubleshoot a cabling problem. I
need you to disable his network socket, number 6-47, for a few
minutes...”
• (The attacker then gets a call from Tom on his mobile...)
• Tom: “Help Eddie, my network just went down, like you said.”
• Attacker: “Ok, I'll see if I can get it back online. Try again in a
few minutes...”
• Tom: “Thanks, I really appreciate that, Eddie.”
4 April 2006
Andrew McNab – Trust on the Net
Network Outage (3)
• Attacker: “Hi again Tom. Is it working now?”
• Tom: “Yes, thanks, I was really worried. But it's ok now.”
• Attacker: “Ok, if you want to make sure it doesn't happen again,
you need to make sure your computer is fully up to date.”
• Tom: “Uh, ok. Up to date like what?”
• Attacker: “I'll send you an email with instructions. Just click on
the link in the email to http://www.M1CRS0FT.COM/ and
download the updates.”
• (So now Tom's computer is running some horrible Trojan program
which allows the attacker to control it remotely, read his files
etc)
4 April 2006
Andrew McNab – Trust on the Net
Summary
• You can trust HTTPS websites IF you make sure they've got
sensible names
– you can minimise the risk of Phishing attacks by using Google
to find sites, and not trusting URLs in emails
• ssh is great once you've made contact with a site and accepted
its public key
• Everything else shouldn't be taken at face value
– especially helpful people who ask you about employment
numbers, network numbers, addresses, office numbers,
“what Professor X's secretary's first name is” etc that could
be used to build confidence in an attacker...
4 April 2006
Andrew McNab – Trust on the Net