Encryption and Authentication

DESCRIPTION

Privacy protection using DES (symmetric algorithm) involves the use of two secret keys. Each party must share their secret key with others. This makes this sort of encryption difficult to use in web technologies.

RSA public key encryption (asymmetric) solves this problem. RSA uses matched pairs of encryption and decryption keys. Each key performs a one-way transformation of the data to encrpty. The public key is shared with others while the private key is kept to yourself. You encrypt your document with your private key and others can decrypt it with your public key. This also provides the basis for a digital signature (if they can unscramble a message with your public key then you must have been the person that encrypted it with your private key).

A digital signature is created by running the message through a hashing algorithm. This produces a message digest which is then encrypted using the private key of the sender. The recipient then decrypts the digital signature (the encrypted message digest) and makes their own calculation on the message digest. If their calculation matches the calculation sent then you are assured that the message has not been tampered with.

Typically you send your public key with encrypted documents so the recipient can decrypt the message. Digital IDs further ensure the sender is who they say they are. A digital ID is a public key that has been digitally signed by a trusted third party. This trusted third party has verified that the person is who they say they are. When a person receives a message from you, they use the digital id to verify the public key is valid. Then they can use the public key to decrypt while being certain that you are who you say you are. Digital IDs are needed because of the fact that anyone could go out and get a public and private key pair and then use them while claiming they are *you*.

SSL (Secure Sockets Layer) is used to protect communications. Digital Certificates encrypt data using SSL. SSL provides data encryption, server authentication, message integrity, and even client authentication. It is currently included in all major browsers and is turned on simply by installing a digital certificate. Note that authentication in this sense simply means validating of the user’s identity.

Note that a asymmetric protocol can be further used to exchange private keys (symmetric). Then the private key can be used to encrypt the data communication using a symmetric protocol (such as DES or RC4). These symettric protocols have the advantage of being more efficient. The asymmetric protocol can be used by both parties to exchange a private key (which is encrypted using the senders private key and decrypted using the senders public key).

One other item can be introducted into all of this – MAC (Message Authentication Code). This is the same as the message digest discussed above. A private key pair can be used with some data to produce a MAC. This assures the message has not been tampered with during transmission.

AUTHENTICATION AND NONREPUDIATION

Here’s how a digital signature works. The message text is first run through a hashing algorith to create a ‘message digest’. This message digest is then encrypted with the person’s private key which means it can then only be decrypted using the individuals public key. When the recipient receives the message they can decrypt it using the person’s public key (ensuring that it was indeed sent by that person) and then calculate their own message digest by running it through a hashing algorithm. If their message digest results match the original message digest results (calculated by the sender) then you can assure that the message was not tampered with.

The only questionable method here is the public key. How can you be assured that the person is really who they say they are? A Cerfitication Authority (such as verisign) verifies the persons identity and gives them a digital ID. A digital ID is a public key that has been signed by the certification authority (using the CA’s private key so that only their public key can be used to decrypt it). Digital IDs usually follow the X.509 standard. These digital signatures offer nonrepudiation too. Secure digital signatures cannot be repudiated – the signer of the document cannot later disown it by claiming that the signature was forged.

Note also that the privacy of the message is not ensured using the above method. To ensure privacy, i.e. ensure that only the recipient can read the message, the sender should encrypt the message using the recipients public key. This makes sure that only the recipient can read the message by decrypting it with his private key.

Note that documents exchanged can also be time stamped. This lets you assure that the document’s security was valid even after the digital ID has expired or after the digital id has been comprised by someone. A digital time stamp service (DTS) is used to send out these time stamps. A message digest is sent to the DTS who issues a time stamp based on the message digest.

Once you receive a digital ID, you can use the setup in your email client or web client so that all of these processes occur transparently.

SSL

Secure Sockets Layer (SSL) was originally developed by Netscape. It is built into all major web servers and web browsers so to implement it you simply need to obtain and install a digital certificate or Server ID to enable it. SSL provides authentication which confirms a web server’s identify (the client software automatically does this by checking that the server’s cerificate and public id are valid and issed by a CA).

URLs will begin with https instead of http. The server will automcatilly send the client the site’s digital certificate. The web browser will generate a unique session key to encrypt all communications with the site. This session key will be encrypted with the server’s public key so that only that server can read the session key. A secure session is now established. The 40-bit and 128-bit references refer to the length of the session key.

S/MIME

S/MIME was originally developed by RSA Data Security, Inc. It is based on the PKCS #7 data format for the messages, and the X.509v3 format for certificates. MIME is a spec for formatting non-ASCII messages over the internet. Browsers and such support the MIME types and know how to display their specific content. S/MIME is a spec for securing electronic email. S/MIME does use digital cerfications (X.509 format)

PGP/MIME

PGP/MIME is based on PGP, which was developed by many individuals, some of whom have now joined together as PGP, Inc. The message and certificate formats were created from scratch, and use simple binary encoding. OpenPGP is also based on PGP.

X.509

The X.509 standard defines what information can go into a certificate and describes how to write it down. It is currently up to version 3 (1996). SSL and S/MIME use the X.509 spec. It’s based on X.500 which defines directory services. See RFC 2511 for more information.

SERVER CERTIFICATES

Server certificates take advantage of SSL to work seamlessly between your site and your visitors’ web browsers. When you obtain a server certificate, you receive a unique public and private key pair. Only the server knows the private key. The public key is freely available along with the certificate.

Here’s how the process works:

(1) A customer contacts your site, accessing a secured URL (indicated by a URL that begins with "https:" instead of just "http:" or by a message from the browser).

(2) Your server responds, automatically sending the customer your site’s digital certificate, which authenticates your site. The server’s public key is included in this certificate.

(3) Your customer’s web browser generates a unique "session key" to encrypt all communications with the site.

(4) The user’s browser encrypts the session key itself with the site’s public key so only the site can read the session key. The site will now use this session key for all subsequent communications.

(5) A secure session is now established. It all takes only seconds and requires no action by the user. Depending on the browser, the user may see a key icon becoming whole or a padlock closing, indicating that the session is secure.

CLIENT CERTIFICATES

These work in the same way as server certificates but serve to validate the client side of the transmission. You can obtain a client certificate (or personal certificate) from VeriSign or setup your own public key infrastructure to issue and manage these certificates. When a user accesses a site that requests a personal certificate, the user is prompted for which certificate they wish to use, the certificate is sent to the server which then authenticates the user’s identity, and then sets up the secured channel of communication. The server must have been configured to restrict access to clients with digital certificates (and to use SSL).

Note that client certificates also contain personal information which is transmitted to the server. This allows the server to gather information for marketing purposes – a disadvantage of client side certificates.

A certificate is a special text file that contains two sections: a clear text (readable by humans) section containing the information about the owner, issuer, and so on, and an encrypted (not readable by humans) section that contains the digital signature and public key of the certification authority. The text file is given the .cer extension so that when you open it the operating system uses whatever certificate utility it has to view the file.

VULNERABILITIES

Common ports for trojans include: BackOrifice UDP port 31337, Netbus 1.x TCP port 12345, Netbus 2.x TCP port 20034.

SERVER SECURITY SETTINGS IN IIS

IIS has Web permissions such as Read and Write. NTFS also has its own permissions, such as Read or Write. Not surprisingly, this can get confusing. The key to understanding the difference between the two is this: Web permissions really control which HTTP verbs are allowed to be executed for HTTP resources. NTFS permissions control which user accounts have what type of access to resources on the hard disk.

HTTP verbs are commands that are sent in headers from browsers requesting actions on resources. For example, a user may say, "I want to Read (GET) this Web page." The header that is sent will specify the resource, and where it is located in cyberspace. Additionally, it will send the GET verb. This verb tells IIS that the requestor wants to "Read" the resource. The FTP world is more familiar with writing to a server, but you can also do this over an HTTP connection.

This is what the Read and Write check boxes on the Web Site tab in IIS are all about. They control which HTTP verbs are allowed for the resources. They do not control the NTFS file system permissions for the resources.

Note that Challenge/Response security is good for a intranet but not for a secure extranet – it doesn’t work over a proxy server or firewall. Also, remember that the only browser that supports challenge/response is IE 2.0 or greater.

For an extranet, basic authentication is used although the username/password is transmitted in clear text. You can use SSL to get by this but remember that SSL uses more server resources so be sure the pages are kept simple and graphics to a minimum. To setup basic authentication with SSL you need to (1) get a server certificate (2) Require Secure Channel (3) use only Basic Authentication (turn off Anonymous and Challenge/Response) (4) tell visitors to use https to call up pages.

IIS can also be configured to use client certificates as a means of authentication.

KERBEROS SECURITY

This is the new security schema used in Windows 2000. It will replace NTLM (NT Lan Manager) as the security method of choice for new NT installations. Note that stand-alone NT installations will still use NTLM.

Kerberos is made up of 3 sub protocols – AS (Authentication Service Exchange) where the KDS (Kerberos Key Distribution Center) gives the client a session key and a TGT (Ticket Granting Ticket). TGS (Ticket Granting Service Exchange) is the subprotocol where the KDC gives out a service session key and ticket when the client requests access to a specific service. CS (Client Server Exchange) is the subprotocol where the client pesents its session ticket for admission to a service.

Typically, here’s how a Kerberos session would happen:

AS Exchange

Each client runs a Kerberos client on their machine. When they log in, this Kerberos client takes their password and converts it to an excryption key and saves these resulte in a cache known as the credentials cache. Then this information is send to the KDC along wih some sort of preauthentication data that proves that the user knows their password (the server also has a copy of the user’s long-term key which it can use to decrypt this preauthentication data). The preauthentication data is usually a timestamp which can further be used to filter out any replication type hack attacks. The server will take this data, look up the cleints long term key, and decrpty the preauthentication data. It will then check this data (timestamp) and verify it is correct. If so then the server is assured that this client does indeed know this client’s long term key.

Next, the KDC will create a session key and encrypt this key with the client’s long term key (so that only the specific client can decrypt the session key that the KDC has generated). It will then create a TGT (Ticket Granting Ticket) which contains an embedded copy of this session key along with other information about the client. The TGT is encrypted with the server’s long term key (which ensures that the client cannot decrypt the ticket). The client will take this data and decrypt the session key (it was encrypted with the client’s long term key). It will save this decrypted session key and the TGT in the credendials cache.

TGS Exchange

When the client wants access to a specific service, it will send the KDC a ‘ticket granting service request’. This message will include request information that has been encrypted with the clients session key and also the TGT that it received earlier (that is encrypted with the server’s long term key). The KDC will decrypt the TGT (that’s encrypted with its long term key). Remember that the TGT was built by the KDC earlier and contains a copy of the client’s session key. The KDC takes this embedded session key and uses it to decrypt the remaining information in the request. In affect we’ve sent an encrypted message that contains an embedded copy of the very key needed to decrypt the message.

If the data passes the test then the KDC will create another session key, this time it will be used solely for the client to communicate with the requested service. This new session key is encrypted twice – it is encrypted with the client’s session key (so that only the client can read it) and then again in another ticket. This ticket consists of the new session key and some authentication information about the requesting client. This new ticket is encrypted with the long term key of the service that the client is requesting access to. Remember that the service would most likely be resources on another server or access to someone else’s machine.

When the client receives this reply from the KDC, it will use its session key to decrypt the new session key. This new session key is stored in the credentials cache. The new ticket is also stored in the credentials cache.

CS Exchange

After the TGS exchange, the client can request the service from the service provider by sending it a message containing (1) authentication information (timestamp) that has been encrypted with the session key (the session key specifically generated by the KDC for the service request), (2) the ticket obtained in the TGS exchange, and (3) a flag indicating whether or not the client wants mutual authentication (this is a Kerberos configuration option, the user/client never is aware of this).

When the service receives this information, it decrypts the packet to get the session key. The session key is then used to decrypt the authentication information (timestamp) which is validated. If it is valid then the ‘mutual authentication’ flag is checked. If this flag is set then the service encrypts a timestamp using the session key, and returns it to the client.

Assuming the mutual authentication flag was set, upon receiving the return packet from the service, the client will decrypt the information using the session key. It will check the timestamp with the time that the client originally sent. If the times match then the client knows that the service is genuine.

Now the session is established. The client and the service can exchange data that is encrypted using the session key or they can mutually choose to share another key that will be used to encrypt the data exchanged.

STEPS IN HACKING A NT SERVER (from ComputerWorld)

User Internic to determine admin phone numbers, IP addresses, etc. Browse the companies web site to determine a general architecture of the system. Telnet to the web site and issue a HEAD stream to determine the machine type. Scan ports to see what is open.

Establish a null session (a Microsoft utility that allows services to communicate with one another withouth a user identification). I actually downloaded nullsess.exe code and added the NetGetUserInfo function to pull user information using a null session connection (connection w/o a password). The NetGetUserInfo api call returns probing type information about users, can weed out valid user logins, last time account was logged into, etc.

Easiest way is to weed out valid accounts and use easy to guess passwords. Once in, copy user files, password files, etc. Use L0phcrack or John the Ripper to crack passwords. Then you can gain access.

17 Things to Do after you’ve hacked admin:

Disable auditing

Grab password file

Create and "adminkit"

Enumerate server information

Enumerate secrets of LSA

Dump Registry info

Use Nltest

Pilfer the box

Add an administrator account

Grab a remote command shell

Hijack the GUI

Disable Passprop

Install a back door

Install Trojan horses and sniffers

Repeat

Hid the adminkit

Enable auditing

COMMON MAIL SERVER COMMANDS

LIST, QUIT, RETR %d, DELE %d, USER <%s>, PASS <%s>, VRFY <%s>, EXPN, HELO <myhost>, MAIL From:<%s>, RCPT To:<%s>, DATA. End with CR/LF combination (two to terminate DATA message stream).

CREATING A NULL SESSION ON A WINDOWS BOX

net use \\192.168.202.33\IPC$ "" /u:""

This opens a null session using the anon user and no password. A registry setting (policy on Win2K) can be changed to require specific authorization. In NT 4.0 HKLM\SYSTEM\CurrentControlSet\Control\LSA – add value RestrictAnonymous (REG_DWORD) with a value of 1 (1 or 2 on Win2K). In Win2K use \Local Policies\Security Options node within the Security Settings MMC snap-in, set Additional Restrictions for Anonymous Conneections policy to ‘No access without explicit anonymous permissions). These settings don’t restrict the connection but prohibit most of the information from leaking across the null session connection.

GRABBING THE SAM DATABASE

You can run serveral utilities against the SAM database to extract username/password combinations (lophtcrack, pwdump). Grabbing the SAM DB is difficult since the system locks the file. To get a copy, create a bootable floppy (format floppy and issue SYS C: A:). Copy files you may need and download a copy of ntfsdos from sysinternals.com. This utility lets you mount a NTFS volume from DOS. Run ntfsdos from the floppy and change to the \WINNT\SYSTEM32\CONFIG directory. You’ll now be able to copy the SAM file to the floppy.

KICKING OFF JOBS UNDER SYSTEM

I’ve heard of two ways to do this. One is to schedule a command such as:

at 11:32 /interactive "regedt32.exe". This would launch regedit under the system account (assuming AT is set to run that way). Another would be to take one of the screen savers (*.scn) and set them to go off. Make a copy of the screen saver for a backup. Then take command.com and copy it to that same directory and give it the same name as the screen saver. When the screen saver kicks off the comman prompt will open under the system account.

ORACLE LOGS

During an Oracle install on NT, Oracle’s SPOOLMAIN.LOG file records database passwords in clear text. Need to make sure this is removed from the server after installations. Note that patch logs files also record many db username/passwords in clear text.

GENERAL SECURITY NOTES ON WEB APPLICATION DESIGN

Several things need to change in our current web design. Money is part of the problem since to do it right would require another server and certainly a lot of time to implement these properly. Since we’ve obtained access to Oracle we currently issue ODBC type calls to retrieve data. We do direct reads and use packages to update data. This is close but not quite where we want to be. All ‘reads’ should be placed in package calls and not be done via direct reads to the database. Currently we only do database updates in that manner. The default UIMSMGR account should not be used as the account to access the database. AR indicated he wanted us to go ahead and use this but I’d much rather have this policy changed. Ideally we’d have a web account that only had permissions to access the custom developed packages used for data access – no tables could be accessed directly. Custom developed views could be an exception to this rule. This account would have very little permissions. If possible it should be logged/audited heavily and have limitiations on connect rates, cpu usage, etc.

The tnpe.com machine needs more horsepower, needs DNS off of it, and needs to be placed in the dmz. We need to begin using MTS or some other mechanism to house business logic. It’s fairly unsafe to be making direct calls to the database (2 tier). A 3 tier archietecture – ASP calls via MTS which calls the database – would be much safer and add an added layer of security.

It’s quite possible that a third database server, possibly NT based or even linux based, should be housed in the dmz. We could use this to store web gathered data. It could also be used to house replicated production data. A nightly job could be run to export and import, into the dmz based database, all tables used in the Internet applications. Anytime a new table is added then we simply add it to the export/import job. This way no access would be allowed to our production database. Not quite as flashy as real-time, live access to the customer information but certainly much safer.

Get all Access applications off of the servers, especially the critical ones. Tough call as to whether housing temporary type data in a MS Access database is a better choice than using production Oracle. Ideally we’d have a separate, smaller Oracle instance that we could utilized on a separate server.

IDS systems should be installed and closely monitored.

We’ve got a pretty good start and have secured where time and money permits. Our biggest problem is taking shortcuts to save time during development. More web developers would solve this. I think NS is sloppy on their implementations too.

New .Net encryption notes

Secret key (symmetric) encryption – transforms the data using a single shared, secret key to encrypt and decrypt. Must faster than public key algorithms. Secret key algorithms are called block ciphers. They transform an input block into an output block of encrypted bytes. Block ciphers available in .Net – RC2, DES, TripleDES, Rigndael (AES)). Information from the previous block is mixed into the process of encrypting the next block. The first block uses and IV to encrypt it. The larger the key used the longer it takes to break. Public key encryption is often used to encrypt the key and IV if the data needs to be encrypted by one party and decrypted by another party.

Rigndael (pronounced rain doll) is faster than TripleDes and more secure. Triple Des is not bad either though. DES it outdated and breakable hence the introduction of Triple Des (which uses 3 different keys to make 3 passes through the data encryption process).

DES, 64 bit, known vulnerabilities

RC2, 40-128 bit, known vulnerabilities

Rijndael, 128, 192, or 256 bit, no known vulnerabilities

Triple DES, 128 or 192 bit, no known vulnerabilities

Note that you can select different cipher modes in .Net. This dictates how the previous block is used when encrypting the current block.

Public key (asymmetric) encryption – transforms the data using a public/private key pare to encrypt and decrypt. Uses a fixed buffer size whereas secret-key encryption uses a variable length buffer. Public key algorightms can’t be used to chain data together in streams the way secret key algorigthms do because only small amounts of data can be encrypted. Hence, public and secret key encryption uses different streaming models. Public key encryption is less susceptible to exhaustive attackes trying every possible key. It can also be used to create digital signatures to verify the identity of the sender. It is very slow though and hence, it’s usually used just to encrypt the small key and IV for a secret key encryption process. .Net provides – DSA and RSA.

Cryptographic signing – Helps verify the data originates from a specific party by creating a digital signature unique to that party. Public key algorithms used. DSA and RSA provided in .Net.

Cryptographic hashes – Maps data from any length to a fixed length byte sequence. Hash algorithms map binary values of arbitrary length to small binary values of a fixed length called the hash value. Message authentication code (MAC) hash functions are used with digital signatures to sign data while message detection code (MDC) hash functions are used for data integrity. .Net provides HMACSHA1, MACTripleDES, MD5, SHA1, SHA256, SHA384, and SHA512.

A salt is a unique string added to every unencrypted string before hashing it. It scrambles the unencrypted data up a bit more before it is hashed.

The determination of which hash provider to use depends on how fast you need it to run and how secure the hash value must be. The following lists the hast method, length in bits, security, and speed. these are ranked from the fastest, least secure methods to the slowest, most secure methods.

CRC32, 32, low, fast

SHA1, 160, moderate, medium

SHA256, 256, high, slow

SHA384, 384, high, slow

SHA512, 512, extreme, slow

MD5, 128, moderate, medium

Securing Cookies

The following are tips to securing cookies in order to keep them from being sniffed or stored and used later.

Set the path argument. Setting it to / means every request will get the cookie while /forums/ would limit the cookie to just that path.

Don’t share the cookie with subdomains. The domain option should be specified as www.test.com. .test.com would allow a match against any subdomain.

Require a SSL connection by using the secure option. The secure options tells the client to only send cookies over SSL connections. This means the cookie will not be available to any part of the site that is not secure (and makes it much less likely that you’ll accidentally send the cookies as cleartext.

Protect against XSS exploits.

This HttpOnly flag tells the browser that it shoudl not allow javascript to access the contents of the cookie. This is primarily a defense against cross site scripting as it would prevent the attacker from being able to retrieve and use the session through such an attack. Note that as of early 2010, this is only supported by a few browsers though so it is not failproof.

Also, in .net there is a httpCookies element you can place in the web.config and add parameters such as httpOnlyCookies, domain, or requireSSL.

Blocking an entire country from a web site

With Apache you can modify the htaccess file. Something like this:

order allow,deny

<Limit GET POST>

allow from all

# specific IP address

deny from 123.123.123.123

# deny a range: 123.123.0.0 – 123.123.255.255

deny from 123.123.0.0/16

# the whole class: 123.0.0.0 – 123.255.255.255

deny from 123.0.0.0/8

# shorthand for previous

deny from 123

</Limit>

You can also use the firewall to block access. You can block off IP ranges of whole regions such as Apnic, Ripe, Afrinic, and Lacnic. A lot of the time you can block using /8 and save time but sometimes you have to block /24 so it can get tedious.

GeoSniper and GeoBlock are IIS plugins. GeoSniper filters all traffic from the client to your web-server based on locations that you select. You can even block locations all the way down to the state and city level.

I found a site that dumps ip address ranges by countries. Dumped the ranges for China and there were 843 ip ranges that would need to be blocked to block China.