The NSA ShadowBrokers exploit leak included a tool known as “BenignCertain” which triggers an information leak which may result in credential and private key disclosure to unauthenticated parties. Cisco IOS routers, PIX and ASA firewalls with VPN IKE IPSec enabled may be affected.

The NSA toolkit's bc-genpkt, bc-id and bc-parser binaries can be used to generate vulnerability triggering packets, send the packet and store the response, and parse the information leak to reveal VPN credentials such as username and password. Alternatively, the Metasploit Framework contains a module to scan for and trigger this vulnerability known as cisco_ike_benigncertain.

Example:

The device appears to leak RAM contents when the fault is triggered:

0000   00 00 00 00 00 00 00 02 00 00 00 00 00 00 2e e0
0010   00 00 2e e0 12 a1 fb 48 00 00 00 00 00 00 00 00
0020   00 00 09 ec 00 00 09 d0 00 00 00 01 01 00 00 0e
0030   00 00 09 c4 00 00 00 01 00 00 00 01 0b 83 d4 d4
... [ snip ] ...
0470   0f ff ff ff 0f ff ff ff 00 00 00 00 00 00 00 00
0480   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0490   00 00 00 00 00 00 00 06 A1 44 93 40 00 00 00 00

When conducting subsequent tests, the memory bytes disclosed appear to change which indicates that this is likely vulnerable. Non-Cisco IPSec devices to not dump excessive bytes when responding to the vulnerability trigger (e.g. 10 bytes vs 2500+ bytes for vulnerable devices device).
However, it is important to note that the usable exploit only affects Cisco PIX devices. This device may be vulnerable but due to slightly different implementation may be leaking less valuable information to an attacker or requires tweaking using the NSA bc-genpkt tool.
Recommendation:
​Ensure the latest patched IOS firmware is installed. If the firmware is confirmed as vulnerable, the preshared VPN keys should also be changed and private keys on the device should be regenerated.
Risk:
High.

Introduction:
At some point you may be required to audit the configuration of a SonicWALL device.
If you have physical/admin access to the management interface, then this is probably the easiest method - drill down every option and check for misconfiguration.

If not, obtain a configuration export file (file name is generally 'sonicwall-name-date.exp') such as sonicwall-SydneyDC-20100607.exp.

You will notice the file is a single line of Base64 encoding.
​
Method:
Either use software such as nipper (a tool to automatically decode multi-vendor firewall, router, switch etc.. configurations then analyse the settings and make recommendations in a pretty report) or Base64 decode it yourself and read the variables.

Linux: 'base64 -d file'
Windows (if you have ActiveState Perl): 'c:\bin\decode-base64.bat file'
​
Recommendation:
Often issues such as SSH v1 and SNMP will be present. Also check the firmware as SonicWALL is notorious for format string bugs.

Recently, a client of ours requested some information regarding security considerations should a corporation permit employees to use social media such as Facebook, YouTube, Twitter and other sites.

It is a common problem. There are a few issues here which need to be considered;

1) Yes there are cross-site scripting issues with the websites. But the vulnerabilities are in the websites themselves, so youtube.com, facebook.com and twitter.com are managed by internal staff - if they are vulnerable then everybody is. It is really out of your control. The worms use to propagate, such as the recent Facebook worm which was posting adult images, abuse the [zero-day] vulnerability in the website... eventually the sysadmins discover the worm and close the gap.

2) The web browsers also play a part in exploitability. Internet Explorer 8+ has some mitigations for XSS. Chrome and Firefox also have some anti-XSS measures, but still lack complete protection. NoScript add-ons can be used for Firefox and Chrome to further mitigate attacks. Earlier browsers such as IE6 and older releases of Firefox interpret HTML and JavaScript differently, as well as Content-Type / Content-Disposition which may make a user of IE6 vulnerable to a facebook worm but not say IE7. So up-to-date SOE browsers are a good idea depending on what your patching is like.

3) When using XSS attacks the attacker or worm often needs a location to store their malicious JavaScript. NoScript will deny external locations unless explicitly permitted. But regardless, attackers sometimes use what would be considered trusted websites... so it is possible for someone to obtain a Google Sites account, upload JavaScript, then the browser will fetch the content from *.google.com ... instead of a suspect .cn domain etc.

4) There is the crossdomain.xml policy - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html. This is dependent on the website.

5) Researchers occasionally uncover browser vulnerabilities which breach the internal browser cross-domain security policy... so the result may be a vulnerability despite proactive protections and hardened configuration.

6) Antivirus vendors such as TrendMicro provide browser add-ons which check and report all URLs accessed by clients world-wide. The Trend Micro Threat Intelligence cloud and other reputable AV companies will notice the worm after a handful of end-users report the malicious action of a site. In this case, a few users will be infected but after the cloud picks up on this, the URL will be blacklisted globally until the threat is eliminated, thus protecting end-users providing you're not the first few visitors to be infected.

7) Obviously if you have a HTTP AV / Content Filter proxy then this may detect some worms.

So to summarise, there are many different preventative measures you can take to avoid infection. Implementing all of the above may significantly reduce your risk, but after all is said and done, if the youtube.com / facebook.com / twitter.com domains are vulnerable, you are waiting on them to provide a fix.

If there is a known, unpatched worm spreading and the media has alerted users like the recent facebook adult photos and dead animals worm, you could temporarily ban access to those sites on the firewall until the worm is cleared to try and protect staff.

Another matter worth considering is whether there is a risk of staff seeing objectionable material such as pornography from the worm and the staff going on stress leave, workers compensation or suing for psychological damages etc etc.
Some organisations try to minimise law suits by implementing strict policies about what to do when someone sends you pornographic material and you unexpectedly open it. There is paper work to complete including who sent the email (they are permanently added to a blacklist), listing all who received the email, any 3rd parties that saw it on your screen, ensuring that email archive / data backup staff store the offending email if needed for court on tape, and email admin staff forcibly deleting copies from staff inboxes by conducting email audits.
​
Hopefully this gives you some insight into corporate considerations prior to blanket access of social media websites for staff.

Introduction
If a PPTP service has been detected, as part of the protocol the software (and/or hardware) vendor is meant to disclose this information. Generally the server hostname is also revealed, which may aid in an attack.
​
Method
There are many ways to determine this, but a simple scenario would be to create a new "dial-up" connection within Windows with a connection type of VPN -> PPTP and connect whilst running a Wireshark packet capture.
By following the captured stream within Wireshark and looking at the protocol dissector, the vendor and hostname will be disclosed.