A vast majority of research focuses on
automated and/or botnet exploits, which makes sense when considering the
number of victims affected. However, a research team from Google and
the University of California, San Diego chose a different path, looking
at "manual account hacking." Exploits that are rare -- less than nine
incidents for every one million people who use Google daily. "However,
the damage manual hijackers incur is far more severe and distressing to
users and can result in significant financial loss," the researchers
mention in their paper Handcrafted fraud and extortion: Manual account hijacking in the wild. "These needle-in-a-haystack attacks are very challenging and represent an ongoing threat to internet users.
Types of account hijacking
To start, there are two types of account hijacks: ●
Automated account hijacking: Attacks that try to compromise user
accounts via botnets or spam networks. This attack uses automated tools,
attempting to maximize the attacker's ROI by scamming a small amount of
money from thousands of victims. ● Manual account hijacking: The
bad guys hijack accounts looking for ways to steal money, ransom
applications or data, leverage contact information for future attacks,
or use sensitive personal data against the victim. To explain the
difference between automated exploits and manual attacks, the paper
mentions, "Manual hijackers spend significant non-automated effort on
profiling victims and maximizing the profit -- or damage -- they can
extract from a single credential."
Image: Google
The
graph to the right depicts the relationship between number of accounts
hijacked and the "depth of exploitation." It seems we can be thankful
the more prevalent automated exploits are less exploitative.
Steal email credentials and profile the victim
The
first step is stealing a victim's account login information. The paper
mentions the most sought-after account is email followed by online
financial accounts. For this discussion, the focus will be limited to
email-account hijacking. Once attackers have the login
information, they decide quickly whether the account is worth further
effort. The paper explains, "If the brief account value exploration
yields promising results, the hijackers spend an additional 15 to 20
minutes per account sifting through emails, and finding ways to monetize
the account." The hijackers are hoping to find emails holding
financial or personal data they can use on the current victim or improve
their chances of exploiting the victim's contacts by making the scam
email supposedly from the victim seem more realistic. The
profiling portion of the attack was of special interest to the
researchers. They mention, "This systematic assessment phase and the
fact that certain accounts are not exploited suggest that manual
hijackers are 'professional' and follow a well-established playbook
designed to maximize profits." The researchers offer more evidence that well-organized groups are behind manual account hijacks: ●
The individuals seemed to work according to a tight daily schedule.
They started around the same time every day, and had a synchronized,
one-hour lunch break. They were inactive over the weekends. ● All
individuals followed the same daily time table, defining when to
process the gathered password lists, and how to divide time between
ongoing scams and new victims. ● They were operating from
different IPs, on different victims, and in parallel with each other,
but the tools and utilities they used were the same. They also shared
certain resources such as phone numbers. More validation for experts who contend online-crime syndicates are run with business-like precision.
Exploiting the victim's contacts
Most
individuals, at one time or another, have received an email where
someone is in trouble and needs money. Almost at once the scam is
dismissed because the email -- an automated account hijacking attempt --
makes little sense. However, manual account hijacks are different.
Being non-automated, attackers can inject material to personalizing the
scam email. The research team mentions there is a distinct pattern to most of the scam emails. They all tend to have: ● A story with credible details to limit the victim suspicion. ● Words or phrases that evoke sympathy and aim to persuade. ●
An appearance of limited financial risk for the plea recipient as
financial requests are requests for a loan with concrete promises of
speedy repayment. ● Language that discourages the plea recipient
from trying to verify the story by contacting the victim through another
means of communication, often through claims that the victim's phone
was stolen. ● An untraceable, fast, and hard-to-revoke yet safe-looking money transfer mechanism.
Defense strategies
The
research paper then describes what email providers can do to prevent
manual account hacking. Sadly, there are precious few for-sure user
defenses other than second-factor authentication -- if it is available
use it. Two-factor authentication will thwart the bad guys.
This module queries the FrontPage Server Extensions and determines whether anonymous access is allowed. use auxiliary/scanner/http/frontpage_login
set rhosts IP_Address
set rport 80
run [*] http://IP_Address/ may not support FrontPage Server Extensions
[*] Scanned 1 of 1 hosts (100% complete)
CASE 2:
This module identifies the existence of possible copies of a specific file in a given path use auxiliary/scanner/http/backup_file
set rhosts IP_Address
run
CASE 3:
use auxiliary/scanner/http/http_version
set rhosts IP_Address
run [*] IP_Address:80 Microsoft-IIS/8.0 ( Powered by ASP.NET )
[*] Scanned 1 of 1 hosts (100% complete)
CASE 4:
Discover active pcAnywhere services through TCP use auxiliary/scanner/pcanywhere/pcanywhere_udp
set rhosts IP_Address
run
CASE 5:
This module is based on et’s HTTP Directory Scanner module,
with one exception.Where authentication is required, it
attempts to bypass authentication using the WebDAV IIS6
Unicode vulnerability discovered by Kingcope. use auxiliary/scanner/http/dir_webdav_unicode_bypass
set rhosts IP_Address
run [*] Using code ’404′ as not found.
[*] Found protected folder http://IP_Address:80/Rpc/ 401 (IP_Address)
[*] Testing for unicode bypass in IIS6 with WebDAV enabled using PROPFIND request.
CASE 6:
This module identifies the existence of files in a given
directory path named as the same name of the directory. use auxiliary/scanner/http/file_same_name_dir
set rhosts IP_Address
run [-] Blank or default PATH set.
CASE 7:
This module attempts to authenticate to an HTTP service. use auxiliary/scanner/http/http_login
set rhosts IP_Address
run [-] http://IP_Address:80 No URI found that asks for HTTP authentication
CASE 8:
Collect any leaked internal IPs by requesting commonly redirected locs from IIS. use auxiliary/scanner/http/iis_internal_ip
set rhosts IP_Address
run
CASE 9:
Simplified version of MS09-020 IIS6 WebDAV Unicode Auth
Bypass scanner. It attempts to bypass authentication using
the WebDAV IIS6 Unicode vulnerability discovered by Kingcope. use auxiliary/scanner/http/ms09_020_webdav_unicode_bypass
set rhosts IP_Address
run
CASE 10:
Checks if an HTTP proxy is open. False positive are avoided
verifing the HTTP return code and matching a pattern. use auxiliary/scanner/http/open_proxy
set rhosts IP_Address
run
CASE 11:
Display available HTTP options for each system use auxiliary/scanner/http/options
set rhosts IP_Address
run [*] IP_Address allows OPTIONS, TRACE, GET, HEAD, POST methods
[*] IP_Address:80 – TRACE method allowed.
[*] Scanned 1 of 1 hosts (100% complete)
CASE 12:
This module identifies files in the first parent directory
with same name as the given directory path.
Example: Test /backup/files/ will look for the following files /backup/files.ext . use auxiliary/scanner/http/prev_dir_same_name_file
set rhosts IP_Address
run [-] Blank or default PATH set.
[*] Scanned 1 of 1 hosts (100% complete)
CASE 13:
This module identifies the existence of additional files by
modifying the extension of an existing file. use auxiliary/scanner/http/replace_ext
set rhosts IP_Address
run [*] Using code ’404′ as not found for .bak files.
[*] Using code ’404′ as not found for .txt files.
[*] Using code ’404′ as not found for .tmp files.
[*] Using code ’404′ as not found for .old files.
[*] Using code ’404′ as not found for .htm files.
[*] Using code ’404′ as not found for .ini files.
[*] Using code ’404′ as not found for .cfg files.
[*] Using code ’404′ as not found for .html files.
[*] Using code ’404′ as not found for .php files.
[*] Using code ’404′ as not found for .temp files.
[*] Using code ’404′ as not found for .tmp files.
[*] Using code ’404′ as not found for .java files.
[*] Using code ’404′ as not found for .doc files.
[*] Using code ’404′ as not found for .log files.
[*] Using code ’404′ as not found for .xml files.
[*] Scanned 1 of 1 hosts (100% complete)
CASE 14:
Scrap defined data from a specific web page based on a
regular expresion. use auxiliary/scanner/http/scraper
set rhosts IP_Address
run [*] [IP Address] / [Microsoft Internet Information Services 8]
[*] Scanned 1 of 1 hosts (100% complete)
CASE 15:
This module launch a sqlmap session. sqlmap is an automatic SQL
injection tool developed in Python. Its goal is to detect and
take advantage of SQL injection vulnerabilities on web applications.
Once it detects one or more SQL injections on the target host,
the user can choose among a variety of options to perform an
extensive back-end database management system fingerprint,
retrieve DBMS session user and database, enumerate users,
password hashes, privileges, databases, dump entire or
user specific DBMS tables/columns, run his own SQL SELECT
statement, read specific files on the file system and much more. use auxiliary/scanner/http/sqlmap
set rhosts IP_Address
run
CASE 16:
This module test for authentication bypass using different HTTP verbs. use auxiliary/scanner/http/verb_auth_bypass
set rhosts IP_Address
run [*] [IP_Address] Authentication not required. / 200
[*] Scanned 1 of 1 hosts (100% complete)
CASE 17:
Identify valid users through the finger service using a
variety of tricks. use auxiliary/scanner/finger/finger_users
set rhosts IP_Address
run [*] IP_Address:79 No users found.
[*] Scanned 1 of 1 hosts (100% complete)
CASE 18:
Detect anonymous (read/write) FTP server access. use auxiliary/scanner/ftp/anonymous
set rhosts IP_Address
run [*] IP_Address:21 Anonymous READ (220 Microsoft FTP Service)
[*] Scanned 1 of 1 hosts (100% complete)
CASE 19:
This module will test FTP logins on a range of machines and
report successful logins. If you have loaded a database plugin
and connected to a database this module will record successful
logins and hosts so you can track your access. use auxiliary/scanner/ftp/ftp_login
set rhosts IP_Address
run [*] IP_Address:21 – Starting FTP login sweep
[*] Connecting to FTP server IP_Address:21…
[*] Connected to target FTP server.
[*] IP_Address:21 – FTP Banner: ’220 Microsoft FTP Service\x0d\x0a’
[*] IP_Address:21 FTP – Attempting FTP login for ‘anonymous’:’IEUser@’
[+] IP_Address:21 – Successful FTP login for ‘anonymous’:’IEUser@’
[*] IP_Address:21 – User ‘anonymous’ has READ access
[*] Successful authentication with read access on IP_Address will not be reported
[*] Scanned 1 of 1 hosts (100% complete)
CASE 20:
auxiliary/scanner/http/webdav_scanner
set rhosts IP_Address
run [*] IP_Address (Microsoft-IIS/8.0) WebDAV disabled.
[*] Scanned 1 of 1 hosts (100% complete)
CASE 21:
use auxiliary/scanner/http/webdav_internal_ip
set rhosts IP_Address
run
CASE 22:
use auxiliary/scanner/http/webdav_website_content
set rhosts IP_Address
run
use auxiliary/scanner/http/dir_scanner
set rhosts IP_Address
run [*] Detecting error code
[*] Using code ’404′ as not found for IP_Address
[*] Found http://IP_Address:80/Rpc/ 404 (IP_Address)
[*] Found http://IP_Address:80/aspnet_client/ 404 (IP_Address)
[*] Found http://IP_Address:80/rpc/ 404 (IP_Address)
[*] Scanned 1 of 1 hosts (100% complete)
CASE 25:
use auxiliary/scanner/http/ssl
set rhosts IP_Address
run [*] IP_Address:443 Subject: /CN=WIN8SERVER
[*] IP_Address:443 Issuer: /CN=WIN8SERVER
[*] IP_Address:443 Signature Alg: sha1WithRSAEncryption
[+] Certificate contains no CA Issuers extension… possible self signed certificate
[+] Certificate Subject and Issuer match… possible self signed certificate
[*] IP_Address:443 has common name WIN8SERVER
[*] Scanned 1 of 1 hosts (100% complete)
CASE 26:
The “mssql_ping” module queries a host or range of hosts on
UDP port 1434 to determine the listening TCP port of any
MSSQL server, if available. MSSQL randomizes the TCP port
that it listens on so this is a very valuable module in
the Framework. use auxiliary/scanner/mssql/mssql_ping
set rhosts IP_Address
run
CASE 27:
The SMTP Enumeration module will connect to a given mail server and
use a wordlist to enumerate users that are present on the remote system. use auxiliary/scanner/smtp/smtp_enum
set rhosts IP_Address
run
CASE 28:
use auxiliary/scanner/smtp/smtp_version
set rhosts IP_Address
run
CASE 29:
The “snmp_enum” module performs detailed enumeration of a
host or range of hosts via SNMP similar to the
standalone tools snmpenum and snmpcheck. use auxiliary/scanner/snmp/snmp_enum
set rhosts IP_Address
run
CASE 30:
The endpoint_mapper module queries the EndPoint Mapper
service of a remote system to determine what services are
available. In the information gathering stage, this can
provide some very valuable information. use auxiliary/scanner/dcerpc/endpoint_mapper
set rhosts IP-Address
set THREADS 55
run [*] Connecting to the endpoint mapper service… [*] b85afe70-a6d5-4259-822e-2c84da1ddb0d v1.0 TCP (49152) IP-Address [*] a500d4c6-0dd1-4543-bc0c-d5f93486eaf8 v1.0 LRPC (LRPC-c9b26c881cadc33e19) [*] 87f226c3-ec14-4325-8a99-6a46348418af v1.0 LRPC (WMsgKRpc01E39F1E2) [*] 12e65dd8-887f-41ef-91bf-8d816c42c2e7 v1.0 LRPC (WMsgKRpc01E39F1E2) [Secure Desktop LRPC interface] [*] 541b0ce0-c70b-1067-b317-00dd010662da v1.0 LRPC (LRPC-f46a818864cada72bb) [*] 541b0ce0-c70b-1067-b317-00dd010662da v1.0 LRPC (LRPC-f46a818864cada72bb)
CASE 31:
The dcerpc/hidden scanner connects to a given range of IP
addresses and try to locate any RPC services that are not
listed in the Endpoint Mapper and determine if
anonymous access to the service is allowed. use auxiliary/scanner/dcerpc/hidden
set rhosts IP_Address
run ============================================================
The primary aim of the OWASP Application Security Verification Standard
(ASVS) is to normalize the range in the coverage and level of rigor
available in the market when it comes to performing web application
security verification. The ASVS standard provides a basis for verifying application technical security controls,
as well as any technical security controls in the environment that are
relied on to protect against vulnerabilities such as Cross-Site
Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. It
is composed of 13 categories containing 168 check points to validate in
your application. Of course not all are applicable but the global
method is wide enough to cover most of web applications.
As a member of OWASP and regularly performing Security oriented
Code-Review in various languages, the Application Security Verification
Standard became the basis on which I rely to deliver security reports to
my customers and a proper way to measure the confidence you can put in
the application. This article is not about presenting ASVS which I trust
you can discover by yourself on the website of OWASP, but it is only to
share a worksheet I have been using along with the document written by OWASP. This spreadsheet takes the shape of a checklist you can browse
in order to assess the level of confidence of the application. In this
article I will enclose this spreasheet and explain how I am using it.
You can directly download the cheatsheet at the end of the post. Basically the spreadsheet is really simple but I have never seen it
elsewhere. You have one tab sheet for each category of the ASVS. For
each category the criteria is documented with its ASVS Level and
description in full text. Then your job will be to fill in the rest of
the field as follow:
Valid (Valid/ Non valid / Not Applicable)
Source Code Reference (If the code is not valid, insert the reference to the files/lines which lack of security)
Comment (Field to comment the vulnerability and keep track of changes with developers)
Tool used (If the vulnerability was found using a tool , you can
include the name of the tool / version and sometimes the output)
Once you’ve done that, do not forget to tag the irrelevant critieria with Non Applicable,
and the report located in the first tab sheet will be automatically
generated as well as the radar graph, you can directly enclose in your
analysis document or report. Ideally this assessment should be done before any major release of
your software, especially if you work with Agile methodology. It should
be part of your recipy before shipping to validate this worksheet. Along
the security analysis you can share this document with developers to
keep tracks of change and also keep the graph at each release to see the
evolution of security of your application through time. LibreOffice Version ASVS-2-0.ods Excel Version ASVS-2-0.xls (I built this spreasheet using LibreOffice, I’m sorry if it looks
broken in Excel… You can kickstart to offer me a MSOffice license :P)
On the market exist lot of good scanners and all of them are excellent, but unfortunately most of available scanners are paid and this relevant fact hinder some students of understanding how to analyze and invade remote machines . Nonetheless, a good free scanner exists and using it allow you find out any possible flaws : OpenVAS. In fact, OpenVAS is so good like Nessus, Retina or any other famous scanner, and learn it is an easy mission. Whereas there're some details about OpenVAS configuration,it follows a quick start procedure to configure OpenVAS and use it a.s.a.p. on Kali Linux.
root@hacker:~#openvas-mkcert -f root@hacker:~#openvas-mkcert-client -n om -i
(The next command is going to require you enter a New password) root@hacker:~#openvasad -c 'add_user'-n admin_linuxmagazine -r Admin
(These next two steps could take a long time) root@hacker:~#openvas-nvt-sync root@hacker:~#openvassd
Networking is an expansive and overwhelming topic for many budding
system administrators. There are various layers, protocols, and
interfaces, and many tools and utilities that must be mastered to
understand them.
This guide will cover the concept of "ports" and will demonstrate how the nmap program can be used to get information about the state of a machine's ports on a network. Note:This tutorial covers IPv4 security. In
Linux, IPv6 security is maintained separately from IPv4. For example,
"nmap" scans IPv4 addresses by default but can also scan IPv6 addresses
if the proper option is specified (nmap -6). If your VPS is configured for IPv6, please remember to secure
both your IPv4 and IPv6 network interfaces with the appropriate tools.
For more information about IPv6 tools, refer to this guide: How To Configure Tools to Use IPv6 on a Linux VPS
What Are Ports?
There are many layers in the OSI networking model. The transport layer is the layer primarily concerned with the communication between different services and applications.
This layer is the main layer that ports are associated with.
Port Terminology
Some knowledge of terminology is needed to understand port
configuration. Here are some terms that will help you understand the
discussion that will follow:
Port: An addressable network location
implemented inside of the operating system that helps distinguish
traffic destined for different applications or services.
Internet Sockets: A file descriptor that
specifies an IP address and an associated port number, as well as the
transfer protocol that will be used to handle the data.
Binding: The process that takes place when an
application or service uses an internet socket to handle the data it is
inputting and outputting.
Listening: A service is said to be "listening" on a
port when it is binding to a port/protocol/IP address combination in
order to wait for requests from clients of the service.
Upon receiving a request, it then establishes a connection with the
client (when appropriate) using the same port it has been listening on.
Because the internet sockets used are associated with a specific client
IP address, this does not prevent the server from listening for and
serving requests to other clients simultaneously.
Port Scanning: Port scanning is the process of
attempting to connect to a number of sequential ports, for the purpose
of acquiring information about which are open and what services and
operating system are behind them.
Common Ports
Ports are specified by a number ranging from 1 to 65535.
Many ports below 1024 are associated with services that Linux and
Unix-like operating systems consider critical to essential network
functions, so you must have root privileges to assign services to them.
Ports between 1024 and 49151 are considered "registered". This
means that they can be "reserved" (in a very loose sense of the word)
for certain services by issuing a request to the IANA (Internet Assigned
Numbers Authority). They are not strictly enforced, but they can give a
clue as to the possible services running on a certain port.
Ports between 49152 and 65535 cannot be registered and are suggested for private use.
Because of the vast number of available ports, you won't ever have to
be concerned with the majority of the services that tend to bind to
specific ports.
However, there are some ports that are worth knowing due to their ubiquity. The following is only a very incomplete list:
20: FTP data
21: FTP control port
22: SSH
23: Telnet <= Insecure, not recommended for most uses
25: SMTP
43: WHOIS protocol
53: DNS services
67: DHCP server port
68: DHCP client port
80: HTTP traffic <= Normal web traffic
110: POP3 mail port
113: Ident authentication services on IRC networks
143: IMAP mail port
161: SNMP
194: IRC
389: LDAP port
443: HTTPS <= Secure web traffic
587: SMTP <= message submission port
631: CUPS printing daemon port
666: DOOM <= This legacy FPS game actually has its own special port
These are just a few of the services commonly associated with ports.
You should be able to find the appropriate ports for the applications
you are trying to configure within their respective documentation.
Most services can be configured to use ports other than the default,
but you must ensure that both the client and server are configured to
use a non-standard port.
You can get a short list of some common ports by typing:
less /etc/services
It will give you a list of common ports and their associated services:
We will see in the section about nmap how to get a more complete list.
How To Check Your Own Open Ports
There are a number of tools that can be used to scan for open ports.
One that is installed by default on most Linux distributions is netstat.
You can quickly discover which services you are running by issuing the command with the following parameters:
sudo netstat -plunt
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 785/sshd
tcp6 0 0 :::22 :::* LISTEN 785/sshd
This shows the port and listening socket associated with the service and lists both UDP and TCP protocols.
How To Scan Ports with Nmap
Nmap can reveal a lot of information about a host. It can also make
system administrators of the target system think that someone has
malicious intent. For this reason, only test it on servers that you own
or in situations where you've notified the owners.
The nmap creators actually provide a test server located at:
scanme.nmap.org
This, or your own VPS instances are good targets for practicing nmap.
Here are some common operations that can be performed with nmap. We
will run them all with sudo privileges to avoid returning partial
results for some queries. Some commands may take a long while to
complete:
Scan for the host operating system:
sudo nmap -O remote_host
Skip network discovery portion and assume the host is online. This
is useful if you get a reply that says "Note: Host seems down" in your
other tests. Add this to the other options:
sudo nmap -PN remote_host
Specify a range with "-" or "/24" to scan a number of hosts at once:
sudo nmap -PN xxx.xxx.xxx.xxx-yyy
Scan a network range for available services:
sudo nmap -sP network_address_range
Scan without preforming a reverse DNS lookup on the IP address specified. This should speed up your results in most cases:
sudo nmap -n remote_host
Scan a specific port instead of all common ports:
sudo nmap -p port_numberremote_host
To scan for TCP connections, nmap can perform a 3-way handshake
(explained below), with the targeted port. Execute it like this:
sudo nmap -sT remote_host
To scan for UDP connections, type:
sudo nmap -sU remote_host
Scan for every TCP and UDP open port:
sudo nmap -n -PN -sT -sU -p- remote_host
A TCP "SYN" scan exploits the way that TCP establishes a connection.
To start a TCP connection, the requesting end sends a "synchronize
request" packet to the server. The server then sends a "synchronize
acknowledgment" packet back. The original sender then sends back an
"acknowledgment" packet back to the server, and a connection is
established.
A "SYN" scan, however, drops the connection when the first packet is
returned from the server. This is called a "half-open" scan and used to
be promoted as a way to surreptitiously scan for ports, since the
application associated with that port would not receive the traffic,
because the connection is never completed.
This is no longer considered stealthy with the adoption of more
advanced firewalls and the flagging of incomplete SYN request in many
configurations.
To perform a SYN scan, execute:
sudo nmap -sS remote_host
A more stealthy approach is sending invalid TCP headers, which, if
the host conforms to the TCP specifications, should send a packet back
if that port is closed. This will work on non-Windows based servers.
You can use the "-sF", "-sX", or "-sN" flags. They all will produce the response we are looking for:
sudo nmap -PN -p port_number -sN remote_host
To see what version of a service is running on the host, you can try
this command. It tries to determine the service and version by testing
different responses from the server:
sudo nmap -PN -p port_number -sV remote_host
There are many other command combinations that you can use, but this
should get you started on exploring your networking vulnerabilities.
Conclusion
Understanding port configuration and how to discover what the attack
vectors are on your server is only one step to securing your information
and your VPS. It is an essentail skill, however.
Discovering which ports are open and what information can be obtained
from the services accepting connections on those ports gives you the
information that you need to lock down your server. Any extraneous
information leaked out of your machine can be used by a malicious user
to try to exploit known vulnerabilities or develop new ones. The less
they can figure out, the better.
Posts
