Nessus Port Scan Engine

Port Scanning
Whether you are doing a network penetration testing or a web application audit, port scanning is always effective. Port Scanning helps us find which services are running on the well-known and not so well known ports (i.e. which ports are available). Essentially, a port scan involves sending a message to all of the ports, one at a time. The response received indicates if the port is open or not and if open, and then determine which service it is running.

NMAP is the tool of choice for Port Scanning, but even when scanning a network with Nessus, some testers still rely on NMAP to cross-verify with the Port Scanning results of Nessus.

Then there's also the myth that Nessus uses NMAP port scanning engine.
By default Nessus has never included or used NMAP for port scanning, though prior to 2.2 versions of Nessus used some NMAP code in the port scanning plugin. Nessus has its own port scanning engine, with various features and functions.

There are three different port scanners in the Nessus Port scanner system.

TCP Scanner :-

It initiates a full TCP connect with the target hosts, by sending a sequence of packets, thus completing the three way handshake everytime. The TCP port scanner tunes it's speed using logic as the scan progresses.
The TCP Port scan does not work on Windows and Mac OS, but only on Linux OS. It is a feature rich scanner, capable of handling different complex situations.

TCP Scanner Settings :-

Automatic (normal) - This is the default option, where it can identify a firewall located between the scanner and the target.

Disabled (softer) - For hosts that you know are not firewalled, this option can be used. If the ports are taking more time to respond, the scanner assumes it as a sign of network congestion.

Do not detect RST rate limitation (soft) - To increase reliability on slow networks, this options can be used. It disables the ability to monitor how often resets are sent.

Ignore closed ports (aggressive) - Whever a scan runs for more than 40 minutes, this options is turned on by Nessus. If any packet filter sends an ICMP unreachable in return, in which case TCP connect() scanner can't distinguish it from a RST, of course this is not a probelm for a SYN scanner.

2) SYN Scanner - Fully supported on Windows, MAC OS and Linux, the SYN Scanner behaves a bit differently, than the TCP scanner. It simplifies the process by sending packets and waiting for a response, but not initiating the full three-way handshake. It does not open sockets, but generates raw packets using low-level libraries. The SYN scanner has logic to compute the rate of packets to be sent and the amount of time to wait for a response. It will constantly recompute the optimal throughput as it scans periodically, so the calculations are happening several times throughout the scan to maximize the scan’s efficiency. The SYN scanner tends to be slower, but more reliable. The rate of packets for the SYN Scanner can now be controlled in Nessus 4.
The same options that are available for the TCP scanner also apply to the SYN scanner.

3) UDP Scanner - There’s not much you can do to make this one go faster (you can cheer it on, but that just helps pass the time) as the UDP scanner will generate UDP packets and send them to the target. Some operating systems respond with ICMP messages, others may crash and some just silently ignore the request. The big problem is that there is no reliable way to know if a port is open because a UDP-based listening service usually won't respond to a probe and also will not respond if the port is closed. Another problem is when ICMP messages are received from a target in response to the UDP probe. Certain operating systems respond slowly and rate limit the response to 1 packet per second for each response. This means a scan of all ports may take as long as 65,535 seconds to complete (approximately 19 hours).


Conclusion

Using the port scanners options in Nessus can be of great benefit in tuning your scans. Knowing which situations the SYN or TCP scanner are best utilized in will result in more accurate and faster vulnerability scans. You can refer to the Nessus product documentation for more information about the port scanner settings.

References :-
http://www.nessus.org/plugins/index.php?view=all&family=Port+scanners
http://blog.tenablesecurity.com
http://blog.tenablesecurity.com/2011/01/nessus-mythbusters-edition.html

DOM Based XSS Attacks

Coming Soon....

How SSL works ?

Secure Socket Layer (SSL)

The Secure Sockets Layer (SSL) is a protocol that provides secure communication between client and server.  Here the client is your browser and server is the web site you're communicating with. Secure communication has three main goals: privacy, message integrity, and authentication.

Example for SSL Usage :-
Alice -> Client
Bob -> Server


Alice intends to trnasmit sensitive information to Bob. Alice wants to make sure that the information she sends to Bob is kept confidential (privacy), and cannot be altered along the way (message integrity). She also wants to make sure that she's really sending the information to Bob and not an imposter (authentication).

Privacy:- Using Cryptography plaintext message is encrypted into ciphertext.

Public Key Cryptography
The information used to turn a plaintext message into an encrypted ciphertext message is a key. Public key cryptography makes use of a pair of keys, one is public, and the other is private.

Alice wants to send Bob private information, so Bob says, "Here Alice, use this public key to encrypt your message before sending it to me. When I receive your encrypted message I will use my private key to decrypt your message." It's okay for anyone to have a copy of the public key, but only Bob should have a copy of his private key. A plaintext message encrypted with the public key can only be decrypted with corresponding private key.

Message Integrity :-
When Alice sends the message to Bob, some data could get lost or corrupted. Message integrity is achieved by sending a message digest along with the encrypted message. A message digest is a fixed-length representation of a message.

Alice says to Bob, "I'm going to send you an encrypted message. So that you know my message to you hasn't been intercepted and altered along the way, I'm also sending a fingerprint of my original message. Please check the fingerprint to see if it matches when you receive my message."

Authentication
How does Alice know that she is really sending the message to Bob? Alice needs to authenticate Bob, to make sure he's really Bob and not someone else. Authentication is achieved by Digital Certificates.

Digital SSL Certificates
A digital certificate is an electronic document. Inside that certificate is a copy of sender's public key and information about its owner (domain name, organization name, location).

Why Should Alice Trust the Information ?

Because the SSL certificate is verified or "signed" by a trusted third party Certificate Authority, such as GeoTrust. The trusted Certificate Authority's job is to verify Bob's application for a digital SSL certificate. The authentication process can range from verifying that Bob has authoritative control of his domain (for GeoTrust QuickSSL), to requiring Bob to submit legal documents that verify Bob's business or organization (for GeoTrust True BusinessID). Once Bob's identity has been verified he will be issued a digital SSL certificate.

All of these concepts- privacy by encryption, integrity by message digests (fingerprinting), and authentication by digital SSL certificates- are integrated into the SSL protocol to allow Alice and Bob to communicate securely.

Why SSL exists ?

For 2 basic purposes
Encryption - Converting plain text to cipher text.
Identification - Need to trust the computer on the other end as the computer you think it is.

ENCRYPTION - How ?

1. Computers agree on how to encrypt data between them.
2. Server sends Certificate which containing Public Key.
3. Client computer says 'Start Encrypting'.
4. The Server says 'Start Encryting'
5. All messages are now encrypted.

1. Computers agree on how to encrypt
In the first part of the SSL Handshake computers agree on how to encrypt.
i) Client send 'Hello' to Server.
It contains the foll :-
Key exchange methods such as RSA, Deffie-Hellman, DSA.
Ciphers (way of encrypting data) - RC4, Triple DES, AES.
HASH (Used to generate Message Authentication code which is sent along to ensure integrity of the messages) - HMAC-MD5, HMAC-SHA.
Also sent is SSL Version (eg: 3.3 for TLS)
And a random number which is used to compute a master secret which is then used to calculate encryption keys.

ii) The server picks one of the methods from each of the various sent by the client. And they are ready for the next stage.

2. Server sends Certificate
Certificate contains info about who the server belongs to, validity, various Serial No's, and importantly the Public Key. So, server sends the Certificate to the client.

3. Your computer says 'Start Encrypting'Three messages accomplish this.
i) Client Key Exchange - Once this is sent, both computers can calculate a master Secret code. So, from now on, the Master Secret Code is used to encrypt all of the data communication between.
ii) Change Cipher Specification - Client asks, to change to the cipher spec previously agreed on.
iii) Lets Start - Start Encrypting

4. The server says 'Start Encryting'
i) Change Cipher Spec - It gives the cipher specification.
ii) Finished - Lets Go. So, the FINISH message is completly encrypted by the server and sent to the client.


5. All messages are now encrypted.Now all messages are encrypted.


IDENTIFICATION - How ?

Who to Trust ?
1. Company asks CA for Certificate. (CA is the Certification Authority like VeriSign or Thwate.)
2. CA creates certificate. (CA will first verify the details of the org, and crptographically sign it in a way that cannot be forged.)
3. Certificate installed in Server. (Then they send the Certificate back to the Organization, who then installs it on their web server.)
4. Browser issued with root certificates.
5. Browser trusts only correctly signed Certificates.(Client's browser will trust correctly signed certificates, but it will not trust incorrectly signed certificates.)


1. Company asks CA for Certificate.In order to do this the company has to give a whole lot of information, like
The Web Server.
What the company is ?
Where is it located ?
Certificate Authority checks correctness and authenticity of the organization. (It uses Puublic Records and
various other methods.) 


2. CA creates certificate.  
It creates the certificate and signs it.
Certificate Info :-
Version
Serial Number
Algorithm ID
Issuer
Validity
Company Details
Subject Public Key Info
    Algorithm
    Key
Identifier for Issuer
Identifier for Company
Signature Algorithm
Signature

Signature is created by condensing all details into a number through a Hash Function.
So, all the info before Signature Algorithm will be condensed into a single number.
Then CA encrypts that number with the private key. So, anyone holding a public key can verify it.
Thats a signature.

3. Certificate is installed on the Server.
Now that Certificate is given to the Organization, who installs it on the Server.
The Organization will run a Webserver. (Apache, Tomcat etc.)
The Certificate is installed into this server.
The Webserver is configured to use the certificate.
From then on the Certificate is going to be used in the Handshake process of the SSL.

4. Browser issued with root certificates.
Any Browser ships with out of the box Certificates from CAs all around the world called the Root Certificates, and that enables it to check the authenticity of any Certificates.

5. Browser trusts only correctly signed Certificates .
The Root Certificates installed on the browser has the public key of that CA in it. So, when it recieves a Certificate from a site, it is able to verify if the signature is absolutly correct.