Skip to main content

Posts

Showing posts with the label security

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 receiv

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 com

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

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 paragr

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