Information Security News
by Cyrus Farivar
The United States Department of Justice wants to broaden its ability to hack criminal suspects’ computers according to a new legal proposal that was first published by the Wall Street Journal on Thursday.
If passed as currently drafted, federal authorities would gain an expanded ability to conduct “remote access” under a warrant against a target computer whose location is unknown or outside of a given judicial district. It would also apply in cases where that computer is part of a larger network of computers spread across multiple judicial districts. In the United States, federal warrants are issued by judges who serve one of the 94 federal judicial districts and are typically only valid for that particular jurisdiction.
The 402-page document entitled “Advisory Committee on Criminal Rules" is scheduled to be discussed at an upcoming Department of Justice (DOJ) meeting next month in New Orleans.
ISC user Craig Cox wrote in alerting us of a fairly sophisticated phishing campaign that is currently in progress. The website appleidconfirm.net has a seemingly realistic Apple login page that is being sent out by email.
Upon submitting what it considers valid credentials, you're redirected to the /?2 page of the site which contains another form which appears to be Apple's site:
At this stage the site is collecting personal details about the account holder which may aid them in making changes to the account or stealing the victim's identity. After submitting precious personal information, it's now time to give them your credit card information:
Only after supplying a valid Visa, Mastercard, American Express or Discover card number are you forwarded to the /?3 "Success" page.
Finally, after a just a couple of seconds on this page (before you have a chance to click one of the links which are actually a screenshot image of the real Apple site without any functional links) you are redirected to the real apple.com. At this point the attacker would have obtained all the necessary information to exploit the victim, and the victim would have absolutely no idea how this happened. Clever!
We're able to observe or infer several things through a quick analysis.
First of all, we can observe that the site is running on PHP:
In the phishing emails, they have /e=6256734589233312746396443f323368 appended to the URL. It's not clear what this parameter does, and may just be some form of tracking identifier. (If you have better ideas as to what this might be, please share in the comments.)
We can also see that the site is hosted by Lycos with a domain registered just a day ago via Tucows.
Looking at the front-end of the site, we can see that the phishers didn't actually replicate the full HTML/CSS page but rather overlayed screenshots of the real apple.com with forms. This is how they manage to so accurately mimic the appearence of the target site without affording much effort into the front-end development. The background screenshot of apple.com used on their main page can be seen at http://www.appleidconfirm.net/img/main.png
Lastly, we can see that the site is not using HTTPS. This is a key differentiator from the true apple.com login page which does utilize HTTPS. Yet another reason to pay close attention to the URL bar in your browser.
Obviously it's not very difficult to craft a successful phishing campaign, but from a technological standpoint it's difficult to thwart them. So, what can we do? We should invest in awareness through education. That means reconsidering the amount of time and budgeting you set aside to train the less less-technical staff about phishing and social engineering. Informally, it may be time to sit down with that friend or family member who keeps sending you ads for weight loss because they have fallen victim to the latest phish. Knowledge is power.
Finally, when you see a phish in progress take the time to write a few abuse emails to the relevant providers. (and forward the phish to us!)(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Internet-connected TVs manufactured by Philips running the latest firmware update are wide open to browser cookie theft and other serious attacks by hackers within radio range, a security researcher has warned.
The hacks work against Philips Smart televisions that have a feature known as Miracast enabled, Luigi Auriemma, a researcher with Malta-based ReVuln (Twitter handle @revuln), told Ars. Miracast allows TVs to act as Wi-Fi access points that nearby computers and smartphones can connect to so their screen output can be displayed on the larger set. The hacking vulnerability is the result of a recent firmware update that allows anyone within range to connect to the TV, as long as they know the hard-coded authentication password "Miracast."
Once someone has connected to the Miracast-enabled Wi-Fi network, they can use publicly available software to download any personal files that may be contained on USB drives plugged in to the Philips Smart TV. More troubling, connected devices can steal the highly sensitive browser cookies that many websites rely on to authenticate users when they access their private accounts.
One of the best ways to create a random yet memorable password is to use "Diceware." This involves literally rolling dice and matching the resulting numbers to a list containing 7,776 English words, each identified by a five-digit number. Five Diceware words has long been thought to provide enough security for the average user.
A five-word Dice password could be something like "boseenricoglennlardheath" or "mastkeithhaagquirttulip."But five words is no longer enough, Diceware creator Arnold Reinhold wrote earlier this month. Since creating Diceware in 1995 Reinhold had recommended at least six random words for people "with more stringent requirements and where the passphrase was being used directly to form a cryptographic key," but for average users he had said that five would do.
Now, for average users he recommends "a passphrase with six Diceware words, or five words with one extra character chosen and placed at random."
In writing web applications PHP developers often find themselves repeatedly calling the
htmlentities function, or the
htmlspecialchars function. These will encode the special characters of a string to their HTML entities, ensuring that output can safely avoid being executed by browser parsing engines.
The problem with this is a human one. Humans do make mistakes, and even those well aware of the consequences and solutions will eventually suffer from an oversight that results in an XSS vulnerability. How can we limit the possibility of creating vulnerabilities in such a situation?
We’ve seen a very fair share of approaches to mitigating XSS in PHP but one in particular seems to fly under the radar. PHP has a couple of configuration directives in php.ini which will automagically filter input by various sanitization and/or validation flags of your choosing. So, can we make it work like
In your (recent) default php.ini file you will find the following:
[filter] ; http://php.net/filter.default ;filter.default = unsafe_raw ; http://php.net/filter.default-flags ;filter.default_flags =
Modify these as follows:
[filter] ; http://php.net/filter.default filter.default = full_special_chars ; http://php.net/filter.default-flags filter.default_flags = 0
This will encode all $_GET, $_POST, $_COOKIE, $_REQUEST and $_SERVER values. (The original data can be accessed through the filter_input() function.)
As a quick proof of concept I built a simple login form that does no sanitization or encoding. The first (Username) field is pre-filled with the data you submitted if an error occurs, such as not providing any password. To exploit the first form field, I entered
"><script>alert("XSS");</script> with no password at all.
Without the php.ini configuration changes:
Now, with the php.ini configuration changes:
The input data is safely output into the form field as content instead of code, thereby mitigating the XSS vulnerability.
urlencodefunction upon outputting a URL which contains user input.
if(ini_get('filter.default')!=='full_special_chars'||ini_get('filter.default_flags')!=='0') die('Missing and/or incorrect filter.default and/or filter.default_flags directives in php.ini');
While this approach can simplify output encoding and limit the risk of developer oversight, it should not be considered an end-all solution. You may have input data sources in your application other than PHP's superglobals. You should still consider the results of a SQL query or cURL request, for example, as potentially malicious. Finally, you should continue performing penetration testing and code reviews to catch that inevitable XSS vulnerability before they do.(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Kaspersky and McAfee shun Infosec silverback contest
CRN - UK
Neither McAfee nor Kaspersky will have stands at the annual chest-beating contest that is Infosec this year, as the two industry giants look to splash their marketing moolah in a more targeted manner. Taking place from 29 to 31 April at Earls Court ...
Report: VA Needs to Improve InfoSec
The Department of Veterans Affairs has a list of long-standing information security issues that need to be addressed, including those related to the protection of veteran's health information, according to a new report issued by the Government ...
Posted by InfoSec News on Mar 27Forwarded from: security curmudgeon <jericho (at) attrition.org>
Posted by InfoSec News on Mar 27http://mayportmirror.jacksonville.com/military/mayport-mirror/2014-03-26/story/4th-flt-passes-cyber-security-inspection-first-attempt
Posted by InfoSec News on Mar 27http://blog.osvdb.org/2014/03/26/the-death-and-re-birth-of-the-full-disclosure-mail-list/
Posted by InfoSec News on Mar 27http://www.networkworld.com/news/2014/032614-fbi-secret-service-breach-280126.html
Posted by InfoSec News on Mar 27http://metromag.co.nz/current-affairs/the-good-hacker-barnaby-jack/
Infosec seen as a grudge purchase
Infosec seen as a grudge purchase. Published on 26 March 2014. Infosec seen as a grudge purchase. So says Maiendra Moodley, divisional head GM for financial systems and processes at the State IT Agency (SITA). Moodley, who has trained and consulted ...