No, I Am Not A Spy (Nor A Cop, ad infinitum)

Given the continued side channel queries regarding my identity, and specifically whether I one of “them” (presumably an intelligence agent, asset, or perhaps even as abstract as a law enforcment agent) I feel it necessary to again reiterate that I am not in the employ of the United States government – or any government for that matter. I am merely a hacker – a network engineer who has seen the tentacles of the government spying aparatus up close and thus has felt the need to speak out against this culture of the average citizen surrendering their privacy for some abstract notion of improved security against as yet undisclosed and shadowy threats (fundamental Islamism? the communists? what exactly?). So here goes, and I imagine I will be compelled to do this semi-frequently as the more conspiratorial of my readers will likely ask the same questions again in several months time:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I - the writer of this blog, identified by the pseudonym Mike The Crypto Goat and PGP key ID 6054D4D2 (and B7A04065 following the aforementioned key's expiry in December) state, under penalty of perjury, that I am categorically not in the employment of the United States government, nor do I perform any task for the aforementioned entity in any capacity. Furthermore I state that I am not an agent, employee or intelligent asset of any government. As of this day I have not received an order under FISA or any other secret (or otherwise) court and am under no duress as I write this statement to this effect. While I understand that the mentioned law, while abhorrent and unconstitutonal (and thus invalid) can effectively be used to 'gag' the free expression of this individual, I will not and shall not sign such a declaration if any information contained within it is not truthful, or where the information within it may be misleading. I will comply with this even if it ultimately results in the contravention of a court (an illegal and unconstitional one at that) order.

As I write this declaration it is 10:25 UTC on Wednesday Jan 29 2014, and the DOW sits at 15,928.56 and the NASDAQ at 4,097.96. The current headlines on reuters.com include "U.N. envoy urges action on Yemen, Security Council to draft resolution", "Thailand to deploy 10,000 police in capital to secure voting" and "Obama warns divided Congress that he will act alone".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (MingW32)

iQIcBAEBAgAGBQJS6NtdAAoJEGu3nNBgVNTSbEoP/i4X8x1PQ5ln9zI1SxQIsBhn
ztOVh+4+iD2/iKyILidoIuKQUxkhMLB5lpWgrUYV5FCDnIvnF3HxcPpErJn8tTYH
wZULClAuAPrf0apDOV3W9lscFMvkwNMm9qIqj/WXd1hkSBNvbgiBC3dQBnjowxXt
r3t9zG+2rYnIhlmoOAP3LRiq3tYqv3ij0Gzsfn9CgMvuFtvotUgUH4LL7In4l5zW
OiqORuiNKD8dmeuEWDMF9ziLNxeLkXBgAUOi5Qo5VYTi6Hw4+HjVvM+f4oTTyynz
+I1RQVZk+TZ0OWLDzOd+QZTyc5paz2romLesHIoDodzLMPQSoA0CKTMeqeTmf4mU
7qXci/52FMGxulgHEYf+4NusJhjfqwsAila67QPb/vJDiMEe6ewx69/J2lL5HmTH
J7sCtvckowsNtcove+PIUjv6bxBmtbGbNDIuCWKzTJFZktg8FcGrbN33Ng8qSZTp
HqIJdvi3G8vaXpIF2SrN2J8T1JkahL26Zx8rIuMc4jkTk/AKRBHj+4wYhTD3zO2G
KGbPF0Ko9Mdg/KDS+/J47NNLK/wvR5QKzrItw8HHPT/GDX42AjkUwq6dphvdOeFg
jF5n5aw7JU6KGT8OrICq+XYZWPN1giigtPPgdmJcCPIkAPIN8v8caYVNKklFS8nm
GFIKKWJmV5s7nc0ixrL1
=KiJ7
-----END PGP SIGNATURE-----

Mainstream Media Reports On NSA Using “Leaky” Apps To Spy On Smartphone Users

I feel a sense of deja vu. The mainstream media today is awash with this story (cnet, guardian, FOXnews) that the NSA and their allied counterparts overseas are utilizing the data leaked from apps like Google Maps (which sends map queries in clear text, or at least used to prior to the brouhaha) or with so called “free” apps that send all kinds of information. Obviously even the least intrusive of the “free” applications with in-app advertising send uniquely identifiable device information in each ad request. Now why do I feel a sense of deja vu? Because this is old news. We heard about this NSA program months ago (hell, I even blogged on it, as did Schneier and others) but I guess the media is either slow to catch up or didn’t realize the implications of such an intelligence program when the “Five Eyes” countries pretty much own every pipe in and out of the Western world.

The solution is pretty simple. If app developers don’t want their apps to die a slow death then they should extricate themselves from these advertising networks (who themselves should be sending any requests via SSL to protect their users from government spying – ironic seeing as they themselves are spying commercially) and cull down unnecessary permissions on their apps.

Android 4.4 made a horrible backwards step when they removed AppOps – which actually gave users some (albeit limited) control over app activity. The conspiratorial of you may suggest that AppOps was slipped in as a feature but quickly nixed by the Google talking heads once they realized that their “revenue partners” could be damaged by users potentially being able to disable app functionality.

I, personally, have had enough talking about the NSA. They have taken the Constitution, ripped it into pieces and used it to wipe their ass. They have screwed not only the American people but every freedom loving person in this world that assumed that they had some kind of right to a semblance of privacy. The NSA are the shit on the heel of Washington and it is a shame that the agency should be shut down and the shameful employees who call themselves public servants – those who mindlessly followed orders to invade the privacy of those both home and abroad that represented no risk to the country – belong not in the unemployment line but in a federal prison somewhere.

Link

The Huffington Post today hosted an article entitled “Independent Review Board Says NSA Phone Data Program Is Illegal And Should End”. Yeah. We here agree but sincerely doubt that the program will end.

Link

A report on Tom’s Guide discusses an attack against the game “League of Legends” by sending spoofed queries to the game server’s NTP service which effectively creates an amplification of the bandwidth used making the attack viable even from an attacker with a constrained pipe. There is nothing inherently sneaky here nor are DDoS attacks against NTP daemons “new” however this has appeared on every security blog from Bruce Schneier’s onward. So I guess I will contribute to this phenomenon which I attribute to a vacuum of truly interesting security related news with this post.

Syslog: an archaic concept with real utility

The basic syslog daemon included in most modern UNIX like operating systems (Linux, *BSD, to some extent Sun Solaris) is quite simple and is designed to get important information from running processes. Even the most basic implementations of syslogd now allow the system administrator to fine tune the system to the extent of which logs or log levels end up in which log file.

The various implementations of the stock syslogd was always designed to be internetworkable and log messages were transferred via UDP on port 514.

There are modernized alternative syslog daemons to choose from including (but not limited to) the excellent syslog-ng which has a number of quite essential improvements that may not be critical for hosts sending their logs but are crucial for the log server itself. That said, if you can run syslog-ng on your hosts too there are certain benefits to this configuration. The most important one is that it allows transmission of log data via TCP. This of course means that you can wrap it around a SSLized tunnel, not to mention the obvious benefits of using TCP – especially where the log host and log server are geographically dispersed and unfortunately the slightest connection delay or issue will cause potentially critical log information to be lost.

Modernized syslogd alternatives like syslog-ng allow for the log to be kept in an alternative format to a flat file and instead in a SQL database. This makes a lot of sense especially on large networks where log volume can be so large.

Many well meaning system administrators  log to a centralized server and keep this in a database as a way of coping with the deluge of log information (I should note that disabling debugging and otherwise useless log entries goes a hell of a long way to making sense of it all), however this results in unencrypted UDP (and with alternatives like syslog-ng unencrypted TCP) packets flying around your network and you may be surprised what they contain.

If you have a spare fifteen minutes find a spare switch port and configure it as a “monitor” port (most managed switches will let you define a port as a monitor or mirror port and will mirror all packets from the switch into your port. Obviously this single port may exceed the throughput of all the switch users and you may get some dropping) and plug a network analyzer into it. Back in the days of hubs this kind of eavesdropping was easy as every port saw the traffic of the other ports. In fact this was often used as a metric to improve performance and reduce collisions.

If you don’t have a network analyzer grab yourself a laptop and acquire the excellent wireshark (formerly known as ethereal) which does a darn good job at converting a cheap PC into something that can replace a piece of kit that costs thousands. Refine your search to UDP/514 and just sit and wait. If you are in a typical large network you will see all sorts of goodies being logged, from imapd reporting logins of users to a radius daemon reporting successful authentication but includes the username, challenge and response instead. You could potentially build a nice bit of intelligence from log data alone.

Perhaps the crux of this article is in this single paragraph. If you have any sort of operation where you have a heap of systems then logging to an external host is a great idea, but consider the security implications and ensure that the logging traffic is tunnelled or otherwise corralled to prevent trivial recovery of log data.

If you use an IDS, then you have likely established that you are a “target”. Whatever the reason these IDS systems can push their findings via syslog to a remote host. What is important is that the integrity of your logs are maintained. I recall a survey of self confessed script kiddies and almost all of them said that machines that were in an almost default state and only logging locally were an easy target – what’s better, they can rootkit the machine and sanitize the logs so it appears that they were never there. When these folks discover external logging on a host they have obtained a root shell on they direct their focus on the log server and generally the log server is the same OS and the exploit that gained then access to the first host was just effective there.

The earliest machines had paper log printers. While incredibly wasteful any tampering with the log would be obvious.

At the very minimum acquire some 1GB WORM SD cards on eBay or Amazon. These were made by Sandisk at the request of a police department in Asia who was concerned about photographic evidence from cameras taken to the crime scene being altered. Unfortunately the program appears to have been unsuccessful and these SD cards are popping up everywhere for sale. How you use the SD is entirely up to you. Obviously you could just start writing to the block device without even using a filesystem and just continue appending until you ran out of space. By queuing two SD cards in the host an email could be sent to the admin notifying him the card is full while the secondary card is now used until full when hopefully the administrator has placed a blank device in the slot. The advantage of this method is speed – the data is very quickly appended to the WORM device and should an exploit be found that allowed access to the log server then there would be nothing they could do remotely to sanitize the logs.

Instead of this approach others may wish to put a basic filesystem on the media (such as FAT32) and instead export log data at an interval they are comfortable, compress it and then add it to the WORM. While you could argue that this is much more economical than the former suggestion, remember that there would be nothing stopping them from piping their data through gzip or a similar archiver before committing it to the volume.

I have spoken in detail on schneier.com about my solution for key storage and this actual real world implemented solution would also be ideal for logging. My device uses an AVR with two FIFOs to implement a crude RS232 data diode. By building something similar so that data may only pass through the serial port. We implemented a proxy on each side in the AVR so that data could be resent with out the host seeing the other host. Imagine a hardened down BSD machine running as a log “aggregator” that collects logs, builds the database (that can be replicated elsewhere). Logs of a level above a defined threshold are shot down the serial port to a second machine that is isolated and kept offline deliberately. The machine would only have utility after an attack where log modification is suspected.

Indeed a much cheaper way of doing what is described above involves setting up a host that has the sole purpose of archiving log data sent to it. By simply cutting the TX lines of the Ethernet cable you can make a primitive data diode. The host you connect it to, let’s pretend it is the second network interface on your main log server, will not negotiate ARP or anything fancy due to the lack of a response from the host with the cut TX lines. The easiest way to get your data into the quarantined box is to send it as a broadcast. On the box that has been quarantined you could use a number of methods to capture your data but the easiest way is to run tcpdump on the interface and pipe its results into a FIFO which is where your script listens, converts the received broadcast frames back into log file entries and archives them in an internal database. Some basic watchdog script would ensure everything continued to run. Given this machine doesn’t have access to the network by design it would be unable to tell us of its performance. Perhaps my RS232 data diode could be put to use, pushing out only statistics that could be graphed with cacti or nagios and information on its internal state (HDD SMART status, etc) into perhaps a Raspberry Pi or a similar cheap tiny embedded board which can then contain code to listen to the serial input, process it and then shoot it out as SNMP.

Anyway I have not slept in over thirty hours as a consequence of a long flight and the insomnia that followed, so please excuse me if this article isn’t in my normal style and is perhaps too verbose and wordy.

Ultimately remote logging is a very worthwhile feature. Ensure that any machines that are spread about geographically are not just sending UDP log packets across the notoriously insecure Internet. Even if you have a VPN between locations or you have a single office you should consider moving to a syslogd that allows sending with TCP and is configurable enough to allow you to use stunnel to encapsulate your connections. The overhead on modern hardware is negligible.

So, perhaps it’s time to start taking syslog seriously. There is even a piece of Windows software that pegged the Windows Event Log and send updates using syslog. Something like this would be ideal for a shop with many *NIX machines and only a few Windows boxes. I recall the software had a functioning SNMP client they claimed was superior to the vendor offering. “Why” you may ask.

“Because it actually works and doesn’t crash on its first trap”

Ugh.

How The NSA Has Changed The Game

Bruce Schneier wrote an excellent piece on how the NSA has actually threatened national security rather than strengthened it. I agree with Bruce on this one – they have most assuredly changed the game, and you can be sure that other nations are going to alter the way they conduct their intelligence gathering and counterintelligence activities. For those of you who don’t follow Schneier’s excellent blog, I made the following comment, which I think is pertinent enough to mirror on this blog.

The NSA have essentially changed the game, so to speak. The Internet was founded upon collaboration and just being friendly to the extent that for much of its early life some of the most critical infrastructure relied on unencrypted protocols like plain snmp or telnet, or BGP without any authentication extensions.

Well, the game has most definitely been changed. I think in the next twelve to thirty six months we will see:

  • any site that processes user information in the form of a submitted form, no matter how mundane will be compelled to use TLS to protect that data. Moreover, sites that typically wouldn’t have a need for TLS will start offering a mirrored version of their site on https for privacy concerned users. Some may make it their default.
  • a complete review into the completely broken certification authority model which our browsers are programmed to implicitly trust. It is broken. Root certs are in the hands of those who you just can’t trust and the game is over. It is time for a better solution. Hell, even an openssh style solution where the browser keeps a cache of site information and alerts on a change would be an improvement. Personally I think that with a little initiative a crowdsourced distributed “web of trust” could be created. The more entrepreneurial could probably see a way to bind this to a cryptocurrency in the form of a bond, ie: “XXX industries puts up XXX BTC to assure that YYY LLC is who they say they are.”
  • an open revolt against advertisers and conglomerates like Google from mining our personal data, identifying us through browser profiling, etc.

Just thinking…

Link

LeakSource has made available an almost complete catalog of products and services clearly intended as an internal resource to other agents and bodies within the NSA. The (formerly) uber-secret TAO or “Tailored Access Operations Unit” is charged with generating exploits, finding flaws that would allow remote access and/or privilege escalation on hosts they already have some limited access to amongst other tasks. I will be elaborating on some of these services and how they affect you and your constitutional rights.