Showing posts with label torrents. Show all posts
Showing posts with label torrents. Show all posts

Friday, July 22, 2016 criminal complaint shows a conection with Silk Road case in HSI agent Jared Der-Yeghiayan

Until the site went offline some 35 hours ago, torrent distribution site Kickass Torrents was widely believed to be the most popular torrent site on the internet, having surpassed the long-troubled Pirate Bay in traffic years ago. Kickass Torrents was taken offline after the arrest of Ukrainian Artem Vaulin in Poland, who law enforcement are accusing of using the site to profit from copyright infringement. Copies of a US Federacriminal complaint brought against Vaulin in the Northern District of Illinois reveal an interesting connection with another incredibly controversial investigation: the case brought against Ross Ulbricht for the now-famous Silk Road website.

The connection between the Kickass Torrents investigation and the Silk Road investigation comes in the form of a single individual: Homeland Security Investigator Jared Der-Yeghiayan. The Kickass Torrents criminal complaint is entirely based on a sworn affidavit provided by Der-Yeghiayan to the court on July 8th. The affidavit is lengthy, and claims that Der-Yeghiayan has evidence linking Vaulin to Kickass Torrents social media accounts and bitcoin exchanges linked to Kickass Torrents. The affidavit relies largely on information provided to Der-Yeghiayan by third parties such as Apple, who Der-Yeghiayan claims confirmed Der-Yeghiayan's iPhone was linked to IP addresses identified by Homeland Security. There is very little in the way of a smoking gun in the Kickass Torrents criminal complaint that I have seen yet.

Jared Der-Yeghiayan was also heavily involved in the investigation of Ross Ulbricht for creating and managing the website Silk Road, which at one point was a forum for buying and selling drugs. Ultimately investigators would charge Ulbricht with a laundry list of offenses, that inevitably lead to a jaw-dropping life conviction for a man never formally accused of a violent crimei. 

Der-Yeghiayan played a large role in the Ulbricht trial, describing for jurors how he arranged roughly 50 "undercover" purchases of drugs using a fraudulently created account on the Silk Road marketplace. News accounts of Der-Yeghiayan's testimony made it seem as though it was a hunch on the part of Der-Yeghiayan that directed law enforcement attention to the Silk Road in the first place. In a gushing  article focused on Der-Yeghiayan titled "Homeland Security Officer: How I Busted The Web's Biggest Illegal Marketplace", Business Insider had this to say:

Jared Der-Yeghiayan, a Department of Homeland Security special agent, told jurors that he began investigating Silk Road when he noticed that many of the drug shipments coming through Chicago's O'Hare International Airport — where he worked at the time — matched up with photos, descriptions, and 'shipped from' location of the drugs advertised on Silk Road's website." 

The Silk Road investigation became the subject of harsh criticism as it became clear that investigators involved with the case - specifically DEA agent Carl Powers Secret Service Agent Shaun Bridges - agreed to sell information related to the criminal investigation focused on Ulbricht *to* Ulbricht for some $148,0000 as part of two separate transactions, agreed to an illegal deal with 20th Century Fox for movie rights to his 'story' of the investigation, and used an illegal position as a "compliance officer" for a bitcoin firm to steal $300,000 worth of the digital currency. In all, the pair were accused of illegally acquiring whether through extortion, money laundering or bribery, acquiring over $700,000 in illegal funds through theft, fraud and abuse of ofice. Powers was eventually convicted of extortion, money laundering and obstruction of justice extortion, money laundering and sentenced to 78 months in federal prison. Bridges arranged some sort of plea agreement; I'm unsure whether he did time but it looks like agreeing to testify against Powers kept him out of the pokey. 

In a depressingly common decision for our rapidly deteriorating justice system, both Powers and Bridges were allowed to testify against Ross Ulbricht during the Silk Road trial, and details of their criminal conspiracy to become millionaires through wire fraud enabled as part of their investigation of Ulbricht was kept out of the courtroom - jurors would never hear, for example, about how Powers attempted on two occasions to sell Ulbricht details of the investigation, but jurors would hear details of an accusation that Ulbricht was never formally charged for - the assassination of a middle aged administrator of the website; a scheme that was manufactured entirely by Powers and for which the only evidence existent of Ulbrichts involvement were private chat logs produced from Powers' unmonitored home computer. The Silk Road trial has widely been decried as both a miscarriage of justice and a stunning example of the hypocrisy of the Obama administration, who before, during and after the Ulbricht trial have claimed that there is "no longer a War on Drugs". Despite the vaguely technical trappings of the Ulbricht trial, there was nothing new about US courts sentencing a man to live in a cage for the rest of his life based on a questionable drug crime investigation. If there was in fact anything unusuaabout the Silk Road case, it was the Powers and Bridges - two outrageously corrupt law enforcement officers - were held accountable for their actions. 

To be clear - there is no evidence that Jared Der-Yeghiayan was involved in the criminal conspiracy undertaken by Powers and Bridges, and in fact it remains unclear what sort of relationship, if any, he had with either of them during the investigation. Der-Yeghiayan was and is a Homeland Security investigator, so he was not part of the same agency as either Powers and Bridges - however, Powers and Bridges were each part of separate law enforcement agencies themselves. I welcome feedback from those more familiar on details surrounding the Silk Road task force.

With that said, there does seem to be a theme between the two cases: both are focused on the imprisonment of a mysterious figure responsible for founding a well-known and controversial website. Both cases revolve around accusations of non-violent behavior that a large and growing number of people do not think should be crimes (both US drug policy and US intellectual property laws are extremely regressive and controversial both domestically and abroad). It is disappointing that Homeland Security has decided that it is worthwhile to have their agents devote "thousands of hours" (to quote Der-Yeghiayan) in attempts to stop file-sharing and drug-use - two activities that we can be fairly certain of are not going to go away no matter how many people are snatch off the streets of Poland. If Ulbricht and Vaulin are indeed responsible for what they have been accused of, it is unlikely that their efforts lead to more people engaging in either file sharing or drug use; it is much more likely that they - while active - reduced the danger inherent in both activities. After all, the Silk Road replaced buying drugs in the street with buying drugs on a website through an accredited and trusted third party. File sharing sites like Kickass Torrents replaced buying burned CDs and DVDs from out of the trunk of some weirdo's car. In both cases, a sketchy transaction that can easily degenerate into outright theft, violence or imprisonment is replaced with an instant transaction that could be performed in the safety of a customer's home.

Whatever your views on the morality of sharing files and sharing joints might be, perhaps the time of Mr Der-Yeghiayan and his colleagues would be better spent investigating violent criminals.

Thursday, April 28, 2016

Torrent data transfer problem: Description & workaround

    Several days ago I noticed that several Comcast / Xfinity residential internet connections throughout the Southeastern US were unable to download or upload torrents. I have a hunch that Comcast implemented a new manner of filtering for customers in my area with the intent of stamping out P2P traffic, however I am not certain if this is the case yet, so I am holding off on a tirade about the friendly neighborhood corporatist internet monopoly for now. I'm interested to know if any other P2P users have encountered similar issues - if so, I hope this post can help.
     The torrent client used for file sharing on these connections was qbittorrent, and listened for incoming connections using a random TCP port assignment that changed each time the client was restarted. Outbound connections used something in the high range on the local side (e.g. TCP port 59999) while on the remote side the port would also be random. It was possible to establish a connection to remote hosts using these same port numbers using the same Xfinity IP, router, etc. and using telnet on the local end and, say, SSH assigned to listed to a custom port number on the remote end.
    Qbittorrent has a few somewhat unique routing features. For example, the client has an "Anonymous" mode that strips user agent and Peer ID identifiers from qbittorrent connections. When anonymous mode is enabled, qbittorrent ceases to accept any incoming connections that are not received through a SOCKS5 or l2p proxy and will only establish outbound connections to trackers using some form of proxy. Its cool stuff, particularly when used with l2p, however many trackers fail to meet its connection criteria which can make downloading torrents using those trackers impossible. Anonymous mode was not enabled on these clients. Furthermore, l2p or onion routing was not part of the equation. Many of the torrent connections were encrypted, however.
    Other routing settings varied based on location; so for example some locations used port forwarding and others did not. All hosts consistently showed a "green" connection status, no errors or failures of any kind were reported. Seeds and peers would be counted as available for each torrent, however no transfer could be initiated. From the client, it looked like people were seeding but that their available upload slots or throughput was exhausted. This went on for days.
    Before I get to the fix, I should note something that was very strange that occurred immediately before torrents ceased downloading. I was online when this occurred, with the qbittorrent client open. Suddenly, the number of seeds and peers for every torrent listed in the client began increasing very fast - faster than I had ever seen, and much faster than made any kind of sense. 

In reality these torrents have < 5 Peers each
    My first thought after seeing this behavior was that a torrent client developer had screwed up. Maybe a very popular tracker was broken. Remember, this behavior occurred on multiple computers on multiple locations with different settings, with different torrents and different trackers. Every torrent was impacted, and these are not popular torrents we are talking about. As mentioned at the beginning, these clients weren't downloading music or movies. Torrents that had less than 5 Peers increased to 400 Peers in under a minute. 
    I went into the settings and applied a quota of 0kbps on downloads and uploads; I also applied this quota to transport overhead. I wasn't sure what was happening to the torrent distribution network, but I didn't want my client to have anything to do with it. I then shut off the client and went to sleep. The next day, I rebooted and started the client back up. The seed and peer listings remained consistent (they in fact remain consistent to this day). I risked letting my client talk to the network again by resetting the quotas and restarting the client. All transfer had stopped up and down, regardless of quota. Over the next few days I identified the same issue at several other locations. 
    After a few days of continuous failure, I decided to visit a web page that claimed to test whether an ISP is filtering bittorrent traffic from your internet connection. This was the site I used:
It was more of a lark than anything; it wasn't clear exactly what this website did; here is what the website claimed:

When you click "START BitTorrent TEST", a BitTorrent-like transfer between your machine and our server is created and we determine whether or not your ISP is limiting such traffic. The test is designed to detect whether your ISP is using any of the following techniques. Throttling all BitTorrent traffic, Throttling all traffic at well-known BitTorrent ports and Throttling BitTorrent traffic only at well-known BitTorrent ports.

    Based on this I operated on the assumption the site just opened a bunch of connections using high-numbered and known BT ports. As I mentioned at the top of the article, I knew I could use these ports to connect to other services. I was interested to see if web-based calls to the same ports were also successful and if not, which ports reported failures. 
    What I didn't expect was for my bittorrent traffic to be immediately restored during the port scan performed by the website. But that is what happened. After nearly a week of complete P2P downtime, qbittorrent immediately resumed transferring files (both up & down) at normal speeds.
    I'll be frank: I have no explanation for why this restored the service. My hunch is that Comcast implemented a P2P filtering doo-dad, and that establishing connections to bittorrent ports by way of a web service convinced that doo-dad of two things. First thing: that the qbittorrent connections were related to the connections established to the web service. And second thing: that since the initial connections were to a web service, these related connections were to a web service also. However, this explanation leaves out why the Peer list grew exponentially right before the initial service failure. Qbittorrent doesn't have very good logging functionality, and while the source code for the client is available via Github, I don't have much time to mess with it ATM. 
    Continuing on the theme of not having much time to mess with things: I just stumbled upon this fix. I don't know, for example, if the fix will remain consistent or if I will have to continue to repeat the portscan after so many days or so many days offline or so much time after no connection has been established on P2P-related ports. As always, I welcome feedback from readers - but this time in particular, given the weirdness of the situation.
    I'd just like to reiterate that, although my hunch is Comcast is behind this, I do not have conclusive evidence that proves that. While I have worked with Comcast, I have never been involved with anything outside of their commercial and data center operations divisions, and that was some time ago. It's been even longer since I directly handled ISP routing - I'm talking dsl and frame relay. The point is, the current guts of Comcast's residential network infrastructure is a mystery to me. Theres plenty of good karma to be earned for any of you techs over there who would enlighten us plebs on the subject.

Thursday, July 23, 2015

Cryptome torrents draw concerns

Those following Cryptome on Twitter saw some messages that were a little nerve-wracking yesterday.

A similar warning was posted to the front page of Cryptome's website:

Cryptome josh wieder torrent warning

The link in Cryptome's message led me to a Kickass Torrents user account that had been opened ~3 weeks previously under the name Cryptome. The account uses the Cryptome website logo. Similar accounts were created on Monova and Lime Torrents.

Cryptome Josh Wieder kickasstorrents user

Putting together an archive for a website you aren't affiliated with, whose content is already free and widely available and has been for many years, isn't necessarily unheard of (?). But doing so while ostensibly posing as that website is ... fishy.

Cryptome Joshua Wieder cool guy torrents
The person circulating these files very likely looks like this.
I decided to check it out. Starting at Kickass Torrents, I looked through the list of uploads; the user had posted somewhere in the neighborhood of 146 files. The torrents had been generated over time, with the most recent one posted only about 20 minutes ago. I thought I might luck out and identify the source of the torrent; 20 minutes wasn't long enough for the torrent to be widely distributed, especially since this isn't exactly a cracked copy of Computer Dinosaurs 4, Talking Yellow Sex Toys 4, Elderly Former Governor Pretending to be a Naked Robot 5, Male Stripper 2 or Fifty-Year-Old Comic Book Characters that Never Should Have Been a Movie 12.

I am fairly certain that I was successful in tracking down the uploader. Somewhat.

The vast majority of IPs that seed torrents can be broken down into three groups:

- Residential and corporate ISPs
- Data center netblocks hosting VPN services
- Tor

First, there are just standard corporate and residential ISPs. These are the poor suckers you see on the receiving end of RIAA lawsuits. They also encompass the s***heads at work who make sure your office internet is consistently garbage. Every once in a while, it also includes the teenagers stealing wifi from their neighbors.

The second and third groups include 133t h@xx0rs (obviously). Some VPN companies and the good people of Tor will banhammer you if hey find you sharing internet pornography with your peers, but that doesn't mean the traffic isn't there.

Of the dozens of trackers I looked at, there were 8 connections. Of those connections, one stood straight out from all the others. This connection was coming from a Leaseweb data center, on a server that did not look even remotely like a VPN server according to nmap:


21/tcp    open     ftp          Pure-FTPd
25/tcp    filtered smtp
80/tcp    open     http         Apache httpd 2.4.10 ((Red Hat) mpm-itk/2.4.7-02 OpenSSL/1.0.1e-fips mod_fastcgi/mod_fastcgi-SNAP-0910052141)
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
443/tcp   open     ssl/http     Apache httpd 2.4.10 ((Red Hat) mpm-itk/2.4.7-02 OpenSSL/1.0.1e-fips mod_fastcgi/mod_fastcgi-SNAP-0910052141)
445/tcp   filtered microsoft-ds
1031/tcp  open     http         nginx 1.0.15
2702/tcp  open     sms-xfer?
16012/tcp open     ssh          OpenSSH 5.3 (protocol 2.0)
16080/tcp open     ssl/http     Apache httpd 2.4.10 ((Red Hat) mpm-itk/2.4.7-02 OpenSSL/1.0.1e-fips mod_fastcgi/mod_fastcgi-SNAP-0910052141)
18040/tcp open     ssl/http     Apache httpd 2.4.10 ((Red Hat) mpm-itk/2.4.7-02 OpenSSL/1.0.1e-fips mod_fastcgi/mod_fastcgi-SNAP-0910052141)

The presence of mpm-itk (which allows an admin to segment vhosts to processor cores), the confluence of Microsoft services and OpenSSH all reeks of VPS. Sure enough, connecting to this IP address using a browser provided some very straight-forward information:

So we have a VPS hosting company, and we have an account associated with the IP address under the name Continental title `jeromelitaud`. There are a few forward DNS entries associated with the IP also - and

UPDATE: I received an anonymous email pointing me in the direction of an online profile for a person whose government name resembles the username. I find it very unlikely that whoever went through the trouble of hosting a VPS to seed these files would use his or her actual name for their (very public) username. If `jeromelitaud` represents an actual name and not merely a pseudo-random nomme de guerre, it is almost certainly because someone by that name has had their identity stolen, not because they are part of some conspiracy to track Cryptome users. So please, I would greatly appreciate it readers would leave people whose name resembles that username alone.

I reached out to the VPS hosting company, the Essex-based Seedboxes (a d/b/a for Cylo Tech Ltd). To their credit, I received a response from an actual human being. Unlike a lot of abuse@ types of contacts, this issue was very much in the immediate self interest of the hosting company to deal with. After all, it very much appeared to be the case that their resources were being stolen by a user whose account had been terminated. Seedboxes manually deleted the VPS account; a software glitch had allowed it to survive an automated account termination process. Such problems are common.

Within an hour or two of the server being taken offline, the phony Cryptome account on Kickass Torrents also appears to have been disabled. This is what a Kickass Torrents user account page typically looks like:

That is what the phony Cryptome account's page looked like when I started looking into this. Here is what the phony account page looks like now:

Im not sure if this change is due to whoever is behind the account attempting to cancel the account, of if Kickass Torrents received a complaint and terminated it. I haven't spoken to anyone at Kickass Torrents regarding this issue. Accounts using the same name circulating the same files remain active on Monova and Lime Torrent.

Cryptome suspected that this may have been an attempt to circulate malicious software among their users. I was not able to download all of the torrents that were being circulated. Of the few I was able to retrieve, I did not identify any malware. However, the files I retrieved were merely flat text files. Other torrents containing PDF files would be much more likely to contain malicious scripts. The only difference I identifies between the index files I retrieved and the current copies of the same files directly on the Cryptome website was the use of non-SSL URLs for the torrents. Thats a lot of effort to go through for the remote hope of getting people to use a non-SSL version of Cryptome; particularly when non-SSL versions of Cryptome are regularly indexed in Google, and Cryptome does not redirect to SSL pages:

If someone reading this retrieved these files and is no longer seeding them, contact me! I would be very interested in reviewing the files.

Why publish this if no malware was identified? The posting of Cryptome's concerns on their website and social media is bound to draw concerns from users. Those users deserve to have the most comprehensive information available. Given the sorts of files Cryptome distributes, the threat of tracking software being used to infect their readers should not be considered outlandish. For the time being, we don't have enough information to draw many conclusions about this event quite yet.

If you are reading this, and you created these torrents, I encourage you to come forward. What did you hope to accomplish with these torrents? Let us know.

UPDATE: Some 36 hours after I had the compromised host noted above taken offline, the Kickass Torrents fake Cryptome account was re-activated and uploaded new files, as shown below. I have contacted Kickass Torrents on email and Twitter.

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...