shortcuts:- Shift+R - New Scan

Shift +F- New Folder

Policy:- Set of Configuration options related to Vulnerability Scan timeouts,
number of hosts, type of port scanner.
RC4 cipher :- A typical stream cipher encrypts plaintext one byte at a time,
although a stream cipher may be
designed to operate on one bit at a time or on units larger than a byte at a time
A pseudorandom stream is one that is generated by an algorithm but is
unpredictable without
knowledge of the input key. The output of the generator, called a keystream, is
combined one
byte at a time with the plaintext stream using the bitwise exclusive-OR (XOR)
operation.
SSL/TLS uses RC4
The RC4 is vulnerable , therefore go with TLS 1.2 and AES-GCM .
The best such attack is due to Itsik Mantin and Adi Shamir who showed that the
second output byte of the cipher was biased toward zero with probability 1/128
(instead of 1/256).
Souradyuti Paul and Bart Preneel of COSIC showed that the first and the second
bytes of the RC4 were also biased. The number of required samples to detect this
bias is 225 bytes.
Like all stream ciphers, RC4 takes a short (e.g., 128-bit) key and stretches it into
a long string of pseudo-random bytes. These bytes are XORed with the message
you want to encrypt, resulting in what should be a pretty opaque (and randomlooking) ciphertext.
The problem with RC4 is that the above statement is not quite true. The bytes
come out of the RC4 aren't quite random looking they have small biases. A few
of these biases have been known for years, but weren't considered useful.
However, recent academic work has uncovered many small but significant
additional biases running throughout the first 256 bytes of RC4 output. This new
work has systematically identified many more.

There are certain common elements that your browser tends to send at
the beginning of every HTTP(S) connection. One of these values is
a cookie -- typically a fixed string that identifies you to a website. These
cookies are what let you log into Gmail without typing your password
every time.
If you use HTTPS (which is enforced in many sites by default), then your
cookies should be safe. After all, they'll always be sent over an encrypted
connection to the website.
Unfortunately, if your connection is encrypted using RC4 (as is the case
with Gmail), then each time you make a fresh connection to the Gmail

site, you're sending a new encrypted copy of the same cookie. If the
session is renegotiated (i.e., uses a different key) between those
connections, then the attacker can build up the list of ciphertexts he
needs.
To make this happen quickly, an attacker can send you a piece of
Javascript that your browser will run -- possibly on a non-HTTPS tab. This
Javascript can then send many HTTPS requests to Google, ensuring that
an eavesdropper will quickly build up thousands (or millions) of requests
to analyze.
Ghost vulnerability :- The GHOST vulnerability is a serious weakness in the Linux glibc
library. It allows attackers to remotely take complete control of the victim system without
having any prior knowledge of system credentials. CVE-2015-0235 has been assigned
to this issue.
Qualys published a blog highlighting a new vulnerability in the Linux GNU C Library (glibc).
The GNU glibc CVE-2015-0235 Remote Heap Buffer Overflow Vulnerability(CVE-20150235) is a buffer overflow in the __nss_hostname_digits_dots() function used
by gethostbyname() function calls and it allows arbitrary code execution from
unauthenticated users. The vulnerability was first introduced in November 2000 and has
been fixed in source code since May 2013. However, most stable and long-term-support
distributions of Linux were left exposed until the major Linux distributors released a patch for
the vulnerability on January 27, 2015.