Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Thursday, July 28, 2016

Google labels wikileaks.org a dangerous website

Five days ago someone on Hacker News pointed out that Google's Safe Browsing system labeled Wikileaks.org a "dangerous site".

At some point the Google warning was rescinded, however Google continues to (accurately) point out that pages within Wikileaks.org will "install malware on visitors' computers".

I've been contacted by many companies over the years who have discovered their web server was compromised after receiving a warning from Google's Safe Browsing system. What I have never seen before is Google labeling a website safe while that website continues to host malware. Has anyone else seen this before? Does anyone at Google confirm this was algorithmically determined behavior and not manual intervention on the part of Google? What possible justification could there be for labeling a website safe that hosts malware?

When I first found malware in content hosted by Wikileaks last year, one of the most frequent negative responses I received was that it is not Wikileaks responsibility to inform their users they host malware and that users should just know to take extreme security measures when reviewing Wikileaks files. Here's another question: if your bank's website hosted malware would you find this same excuse acceptable? If you think we should give Wikileaks a pass but not a bank, what reasoning is this based on? Wikileaks users, volunteers, independent activists and journalists run real risks when reviewing Wikileaks file dumps. Why do we demand more effort be put into making sure some kid doesn't zap a few hundred bucks out of our checking accounts than making sure a reporter isn't imprisoned?

Wikileaks should make some effort to identify malicious software within their filedumps, label infected files, and take more proactive steps to inform users of the risks of handling these files. I would be happy to volunteer to assist with any of these tasks, as I am sure hundreds of other competent infosec professionals. Meanwhile, organizations like Google should stop giving Wikileaks' retrograde operational security a pass. It is exactly because the work that Wikileaks performs is valuable that its worth making the site safe for users.

Sunday, November 30, 2014

Trust

When UNIX co-progenitor and super-smarty-pants Ken Ritchie was given a Turing Award, he provided a warning to those within ear shot. Admins and developers often find it satisfactory to review the source code of applications to determine maliciousness. And to a certain extent, this works out all right. Over time we have built a series of expectations of where to expect naughty code based on our experience. We have also chosen to trust other types of tools that we use during this process. We discriminate.

But there's no reason that bad stuff *has* to be in the applications that we expect to find it in. Yes, the clever among us know that compilers can be bad. But we check the source of our compilers and find no bad stuff, and so we assume we are safe.

We do, though, compile the compiler, don't we?

Well, alright then some megalomaniac at Intel or somewhere far upstream decided to embed badness in the embedded distro compilation software. We can still look at the binary of compiled programs to determine What Is Really Going On.

We do, though, tend to use applications to help make machine code human readable, though, don't we?

The point to the thought experiment isn't to stop the unbelievable interchange of ideas and applications that has brought us to where we are today in modern computing. It would be impossible to manually read the machine code of all of the applications that we use and still function in the workplace and our other communities as we are expected to.

Rather, we should be aware of the trust that we place in our tools. We should be aware that when we set out to solve or review problems, we take certain things for granted.

The point is not, that we should never trust. The point is that we should make trust decisions willfully and based on reasonable deductions and facts; not impulse or ease of use.

I came across Ritchie's chat today in a CS class, and its still as relevant today as it ever was. You can read the whole thing here.

Wednesday, October 22, 2014

Palo Alto Networks Firewalls Leaking Usernames and Password Hashes

A significant number Palo Alto Networks (PAN) firewalls are leaking critical information onto the open internet. Its vital to immediately qualify that statement. The leaks result from firewall administrators enabling Client Probing and Host Probing within the User-ID settings without explicitly limiting such probes to a trusted "zone" or subnet. Username, domain name and password hash are provided to those initiating a properly formatted SMB connection to impacted firewalls. 

HD Moore, Chief Research Officer of Rapid7 and founder of MetaSploit, is responsible for the initial publication of the vulnerability.

Enabling such a configuration on a production firewall appliance, with its resulting leaks, results in a somewhat unusual situation where responsibility for the resulting vulnerability ought to be shared between security administrators and PAN developers. SMB probing should be filtered to trusted subnets; this is obvious. That said, such a setting should not be essentially encouraged through the user interface. It would be trivial to produce and error or warning message when saving of a configuration that allows SMB probing to the WAN. Clearly there was an oversight on the part of PAN here. 

To their credit, PAN has released an advisory to their customers, and has done so promptly. Even more to their credit, they cited Moore's original post in their own. Honesty and transparency of this nature is rare and should be applauded. Its tough to own up when you screw up, but PAN appears to have done just that.

Its a simple problem with a simple solution, admins. Disable Probing on your PAN appliance, or ensure that SMB probes are filtered to a secure subnet. An explicit how-to on that task is available here.

Sunday, October 12, 2014

NSA Targets Systems Administrators with no Relations to Extremism

The Details

This is a bit of an old story, but I've found to my unpleasant surprise that the issues surrounding the story are not widely understood or known. Here's the gist: leaks from the US intelligence service have explicilty confirmed that the NSA targets systems administrators that have no ties to terrorism or extremist politics. If you are responsible for building and maintaining networks, the NSA will place you under surveillance both personally or professionally; they will hack your email, social network accounts and cell phone. The thinking behind this alarming strategy is that compromising a sysadmin provides root-level access to systems that enable further surveillance; hack an extremist's computer, and you track just that extremist. Hack a sysadmin's computer, and you can track thousands of users who may include extremists among them (its a strategy that is remarkably similar to the targeting of doctors in war zones).

Five years ago such a lead paragraph would be among the most wild-eyed of conspiracy theories. Now, after the Snowden leaks and the work of other sources within the US Intelligence community, the sysadmin targeting scheme has been proven conclusively through supporting documents circulated through a "wiki" style system within the NSA and explained and reported by Ryan Gallagher and Peter Maas of The Intercept. The name of the scheme is I hunt sys admins. The entire document outlining the goals and methods of the I hunt sys admins scheme is available on The Intercept (While I typically publish source documents directly on this website for ease of use, publishing these documents present unique legal concerns that The Intercept is better equipped to handle - I apologize to users for the inconvenience of having to visit a second site to confirm sources but I assure you it is well worth the effort).

There are a few excerpts worth noting explicitly. First and foremost, the document describes that the surveillance typically begins by acquiring the administrator's webmail or Facebook account username. The NSA agent then uses an Agency tool called QUANTUM to inject malware into the admin's account pages. The Intercept has put together a video outlining the QUANTUM tool's capabilities that is worth watching. The existence and capabilities of the tool are themselves also confirmed through extensive NSA documentation. QUANTUM uses a Man-On-The-Side attack to hijack user sessions and redirect traffic to one of the NSA's Tailored Access Operations (TAO) Servers. In this case, the application server used is called FOXACID. The same application is used to compromise Firefox and Tor users (a related program in place at Britain's GCHQ called FLYING PIG offers similar functionality even while using SSL).

QUANTUM has a variety of different uses besides the one outlined above. QUANTUM has a series of plugins that allows NSA agents to take control or IRC networks, compromise DNS queries, run denial of service attacks, corrupt file downloads and replace legitimate file downloads with malware payloads.

The methodology is important as it demonstrates the importance of maintaining operational security even during personal time. These are not attacks that target political or military organizations; they do not even target corporations. They explicitly target individual system administrators.

And there's more.

NSA Agents use the tool Discoroute to retrieve router configurations from passive telnet sessions. NSA documents outline how, rather than use sysadmins to target the corporations they work for, NSA is interested in doing the reverse - using corporate router configurations to target individual sysadmins. For example, using Discoroute, a surveillance agent retrieves the access-list ruleset associated with the router. Using that access-list can reveal home IP addresses that admins use to login to systems remotely. While this may seem to be an egregious security oversight, the access-lists in question are not necessarily for core routers. The access-list could just as easily be retrieved from a PIX; an IP used to allow access to an intranet website.

The I hunt sys admins documents continue by outlining some methods to identify and surveil malicious users. The author of I hunt sys admins references the NSA's access to massive untargeted recordings of SSH sessions. Perhaps we can take some security in that the author apparently does not take it for granted that the NSA can easily decrypt SSH session data. However, quite a bit can be accomplished by analyzing encrypted data. In this instance, I hunt sys admins recommends reviewing the size of SSH login attempts to determine which are successful and which are failed. IP addresses which are recorded failing multiple attempts to large numbers of IPs can safely be identified as belonging to brute force attempters.

Why You Should Care About NSA Surveillance Even if You Do Not Care About NSA Surveillance

This is a website about technology; not politics. Whatever your opinions are about the legitimacy or warrantless surveillance, the actions of the NSA and the other Five Eyes surveillance agencies are having a significant and deleterious impact on the internet and those who build and support it. Additional leaks have demonstrated that NSA provided security firm RSA with $10 million to use the flawed Dual_EC_DRBG random number generator in its unfortunately-named BSAFE cryptographic library, providing a back door to all applications relying on BSAFE. Even more disturbing are confirmations that the NSA has obtained copies of root CA certificates and used them to compromise SSL implemented by major internet services.

But why should we care? I'm not guilty and so I have nothing to hide, as the oft-used rationalization goes. Warrantless surveillance by governments is only one consequence of the actions outlined above. Chief among concerns for the admins targeted by these policies that are unconcerned with government surveillance is that actors other than the Five Eyes nations can easily engage in the same practices as explained in the I hunt sys admins documents; frankly, few if any of the I hunt sys admins guidelines were actually invented by NSA. These are techniques designed by criminals, and criminals have massive incentives to continue innovating those techniques. To protect our privacy from criminals we must follow security best practices, and by following best practices we necessarily protect ourselves against government surveillance as well.

The fact remains that sysadmins will remain a desirable target for those seeking to break into protected systems. Protecting those systems and the users who depend on them is part of our mandate as administrators. Now that we know the extent to which the security environment has changed, the question becomes whether we continue to adapt to the new environment to best protect our applications and users, or whether we disregard our mandate.

Sunday, October 28, 2012

Google and Facebook Store and Leak Old Login Information

Shocking, I know.

Barracuda Labs has a good catch up on their blog. Apparently, Facebook and Google save old passwords, and can leak them under certain circumstances during login attempts.

Check out their entire post here. Why is this information being saved?

Tuesday, September 18, 2012

Disable Display_Errors in Production

Its a simple message, but worth repeating.

Yesterday I came across the website of a major internet security firm making a few first-day-on-the-job mistakes. While I am not going to "out" them before contacting them directly, what they did is silly enough that it warrants a bit of discussion in the abstract.

Display_errors was enabled in their web server's php.ini. As a result, a few helpful messages were displayed briefly at the top of several of pages on the site

1. The name of the database
2. The name of the table in use by that page
3. A list of every column in that table
4. An error indicating that the table is exceeding its maximum allowable size of 4GB

The site collects information about its users - IP address, browser info, referrer, etc, and stores that information to a table in a MySQL database - we know from the error itself that database is running on a server using a 32 bit operating system. With the structure of the database, we have everything we need for SQL injection.

That said, there was one additional level of security. The internet security company is masking database queries in URLs - clicking around the site, it became clear that calls to the database are encoded using an encrypted hash. Unfortunately for the internet security company, this technique obscures rather than protects. Because the hashing is not applied consistently across all requests, it actually helps to draw attention to pages that require further scrutiny from an attacker. And of course, since we already have the structure of a database, we can use php's md5 and sha-1 functions to encode our own injection attempts. I will give the internet security company bonus points for not using base64 encoding for the masking - its surprising how often base64 is used for this purpose when it is trivial to decode and under normal circumstances does not provide any performance benefit. If anyone knows of some good reasons to use base64, please shoot me an email or leave a comment.

In summary - I hope this post helps to illustrate how displaying error information, a very common mistake, can lead to the compromise of an otherwise secure site. I left out a lot of information as it was not my intention to create a "how to" guide on SQL injection. That said I hope I found a good balance between providing a practical example without encouraging nasty behavior. Always remember to disable remote error reporting and debugging features on production servers. When debugging is needed, enable it just long enough to resolve the issue and then turn it back off. Do not attempt to use verbosity settings as a way of securely displaying error information - it only takes one poorly worded error message to compromise a site.

RAT Bastard

Earlier this week, several servers I maintain were targeted by automated attempts to upload a remote access trojan (RAT). The RAT is a simpl...