Shared posts

04 Feb 21:37

Sega’s AI Computer Embraces The Artificial Intelligence Revolution

by Maya Posch

Recently a little-known Sega computer system called the Sega AI Computer was discovered for sale in Japan, including a lot of the accompanying software. Although this may not really raise eyebrows, what’s interesting is that this was Sega’s 1986 attempt to cash in on Artificial Intelligence (AI) hype, with a home computer that could handle natural language. Based on the available software and documentation, it looked to be mostly targeted at younger children, with plans to launch it in the US later on, but ultimately it was quietly shelved by the end of the 1980s.

Part of the Sega AI Computer's mainboard, with the V20 MPU and ROMs.
Part of the Sega AI Computer’s mainboard, with the V20 MPU and ROMs.

The computer system itself is based around the NEC v20 8088-compatible MPU with 128 kB of RAM and a total of 512 kB of ROM, across multiple chips. The latter contains not only the character set, but also a speech table for the text to speech functionality and the Prolog-based operating system ROM. It is this Prolog-based environment which enables the ‘AI’ functionality. For example, the ‘diary’ application will ask the user a few questions about their day, and writes a grammatically correct diary entry for that day based on the responses.

On the system’s touch panel overlays can be used through cartridge or tape-based application to make it easy for children to interact with the system, or a full-sized keyboard can be used instead. All together, 14 tapes and 26 cartridges (‘my cards’) had their contents dumped, along with the contents of every single ROM in the system. The manual and any further documentation and advertising material that came with the system were scanned in, which you can peruse while you boot up your very own Sega AI Computer in MAME. Mind that the MAME system is still a work in progress, so bugs are to be expected. Even so, this is a rare glimpse at one of those aspirational systems that never made it out of the 1980s.

04 Feb 21:36

Foldmation: Interactive Origami Folding

17 Mar 02:40

New Release: Tor Browser 11.0a3 (Android Only)

by sysrqb
New Release: Tor Browser 11.0a3 (Android Only) sysrqb August 05, 2021

Tor Browser 11.0a3 is now available from the Tor Browser download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable release instead.

This version updates Fenix to 91.0.0-beta.5.

Warning:
Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services later this year. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 11.0a2:

  • Android
    • Update NoScript to 11.2.11
    • Bug 40176: TBA: sometimes I only see the banner and can't tap on the address bar
    • Bug 40185: Use NimbusDisabled
    • Bug 40181: Remove V2 Deprecation banner on about:tor for Android
    • Bug 40184: Rebase fenix patches to fenix v91.0.0-beta.5
    • Bug 40063: Move custom search providers
  • Build System
    • Android
31 Jul 23:14

Why TiVo's Founders Crashed and Burned With Qplay

by timothy
Velcroman1 (1667895) writes "Michael Ramsay and Jim Barton created a revolution with TiVo, a device that challenged the notion that we had to watch TV shows when they aired. And they hoped to do it again with Qplay, a device that challenged the notion that short-form videos had to be consumed one at a time, like snacks instead of meals. Qplay streamed curated queues of short-form Internet video to your TV using a small, simple box controlled by an iPad app. So what went wrong? Unlike TiVo, the Qplay box was difficult to justify owning, and thevalue of the service itself is questionable. And as of last week, Qplay is closed."

Share on Google+

Read more of this story at Slashdot.








22 Jan 00:24

Scientists detect “spoiled onions” trying to sabotage Tor privacy network

by Dan Goodin
The structure of a three-hop Tor circuit.

Computer scientists have identified almost two dozen computers that were actively working to sabotage the Tor privacy network by carrying out attacks that can degrade encrypted connections between end users and the websites or servers they visit.

The "spoiled onions," as the researchers from Karlstad University in Sweden dubbed the bad actors, were among the 1,000 or so volunteer computers that typically made up the final nodes that exited the Tor—short for The Onion Router—network at any given time in recent months. Because these exit relays act as a bridge between the encrypted Tor network and the open Internet, the egressing traffic is decrypted as it leaves. That means operators of these servers can see traffic as it was sent by the end user. Any data the end user sent unencrypted, as well as the destinations of servers receiving or responding to data passed between an end user and server, can be monitored—and potentially modified—by malicious volunteers. Privacy advocates have long acknowledged the possibility that the National Security Agency and spy agencies across the world operate such rogue exit nodes.

The paper—titled Spoiled Onions: Exposing Malicious Tor Exit Relays—is among the first to document the existence of exit nodes deliberately working to tamper with end users' traffic (a paper with similar findings is here). Still, it remains doubtful that any of the 25 misconfigured or outright malicious servers were operated by NSA agents. Two of the 25 servers appeared to redirect traffic when end users attempted to visit pornography sites, leading the researchers to suspect they were carrying out censorship regimes required by the countries in which they operated. A third server suffered from what researchers said was a configuration error in the OpenDNS server.

Read 8 remaining paragraphs | Comments

14 Jan 02:19

I Spent Two Hours Talking With the NSA's Bigwigs. Here's What Has Them Mad

by Steven Levy
My expectations were low when I asked the National Security Agency to cooperate with my story on the impact of Edward Snowden's leaks on the tech industry. Imagine my surprise when they agreed to let me behind the fence.
    






14 Jan 02:09

New DoS attacks taking down game sites deliver crippling 100Gbps floods

by Dan Goodin
Online gamers such as these ones often stream their play in real time.

Recent denial-of-service attacks taking down League of Legends and other popular gaming services are doing more than just wielding a rarely-seen technique to vastly amplify the amount of junk traffic directed at targets. In at least some cases, their devastating effects can deprive celebrity game players of huge amounts of money.

As Ars reported last week, the attacks are abusing the Internet's Network Time Protocol (NTP), which is used to synchronize computers to within a few milliseconds of Coordinated Universal Time. A command of just 234 bytes is enough to cause some NTP servers to return a list of up to 600 machines that have previously used its time-syncing service. The dynamic creates an ideal condition for DoS attacks. Attackers send a modest-sized request to NTP servers and manipulate the commands to make them appear as if they came from one of the targeted gaming services. The NTP servers, which may be located in dozens or even hundreds of locations all over the world, in turn send the targets responses that could be tens or hundreds of times bigger than the spoofed request. The technique floods gaming servers with as much as 100Gbps, all but guaranteeing that they'll be taken down unless operators take specific precautions ahead of time.

Among the recent targets of this type of attack are game servers used by celebrity players who broadcast live video streams of their gaming prowess that are viewed as many as 50,000 times. In some cases, the massive audiences translate into tens of thousands of dollars per month, as ads are displayed beside video feeds of the players blowing away opponents in Dota 2 and other games.

Read 8 remaining paragraphs | Comments

24 Dec 03:56

Sun Not a Significant Driver of Climate Change

by Unknown Lamer
damn_registrars writes "Scientists from Edinburgh, Scotland have recently published a study based on 1,000 years of climate data. They have compared the effects of differing factors including volcanic activity, solar activity, and greenhouse gases to find which has the most profound effect on climate. They have concluded that the driving factor since 1900 has been greenhouse gases."

Share on Google+

Read more of this story at Slashdot.








14 Nov 15:00

HTTP 2.0 May Be SSL-Only

by Soulskill
An anonymous reader writes "In an email to the HTTP working group, Mark Nottingham laid out the three top proposals about how HTTP 2.0 will handle encryption. The frontrunner right now is this: 'HTTP/2 to only be used with https:// URIs on the "open" Internet. http:// URIs would continue to use HTTP/1.' This isn't set in stone yet, but Nottingham said they will 'discuss formalising this with suitable requirements to encourage interoperability.' There appears to be support from browser vendors; he says they have been 'among those most strongly advocating more use of encryption.' The big goal here is to increase the use of encryption on the open web. One big point in favor of this plan is that if it doesn't work well (i.e., if adoption is poor), then they can add support for opportunistic encryption later. Going from opportunistic to mandatory encryption would be a much harder task. Nottingham adds, 'To be clear — we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case — browsing the open Web — you'll need to use https:// URIs and if you want to use the newest version of HTTP.'"

Share on Google+

Read more of this story at Slashdot.








24 Oct 03:58

Code Names for NSA Exploit Tools

This is from a Snowden document released by Le Monde: General Term Descriptions: HIGHLANDS: Collection from Implants VAGRANT: Collection of Computer Screens MAGNETIC: Sensor Collection of Magnetic Emanations MINERALIZE: Collection from LAN Implant OCEAN: Optical Collection System for Raster-Based Computer Screens LIFESAFER: Imaging of the Hard Drive GENIE: Multi-stage operation: jumping the airgap etc. BLACKHEART: Collection from an FBI Implant...
09 Oct 22:39

The Linux Backdoor Attempt of 2003

by Unknown Lamer
Hugh Pickens DOT Com writes "Ed Felton writes about an incident, in 2003, in which someone tried to backdoor the Linux kernel. Back in 2003 Linux used BitKeeper to store the master copy of the Linux source code. If a developer wanted to propose a modification to the Linux code, they would submit their proposed change, and it would go through an organized approval process to decide whether the change would be accepted into the master code. But some people didn't like BitKeeper, so a second copy of the source code was kept in CVS. On November 5, 2003, Larry McAvoy noticed that there was a code change in the CVS copy that did not have a pointer to a record of approval. Investigation showed that the change had never been approved and, stranger yet, that this change did not appear in the primary BitKeeper repository at all. Further investigation determined that someone had apparently broken in electronically to the CVS server and inserted a small change to wait4: 'if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) ...' A casual reading makes it look like innocuous error-checking code, but a careful reader would notice that, near the end of the first line, it said '= 0' rather than '== 0' so the effect of this code is to give root privileges to any piece of software that called wait4 in a particular way that is supposed to be invalid. In other words it's a classic backdoor. We don't know who it was that made the attempt—and we probably never will. But the attempt didn't work, because the Linux team was careful enough to notice that that this code was in the CVS repository without having gone through the normal approval process. 'Could this have been an NSA attack? Maybe. But there were many others who had the skill and motivation to carry out this attack,' writes Felton. 'Unless somebody confesses, or a smoking-gun document turns up, we'll never know.'"

Share on Google+

Read more of this story at Slashdot.








03 Oct 01:39

Feds Take Down Online Fraud Bazaar ‘Silk Road’, Arrest Alleged Mastermind

by BrianKrebs

Defendant Charged With Drug Trafficking, Hacking, Money Laundering

Prosecutors in New York today said that federal agencies have taken over the Silk Road, a sprawling underground Web site that has earned infamy as the “eBay of drugs.” On Tuesday, federal agents in San Francisco arrested the Silk Road’s alleged mastermind. Prosecutors say 29-year-old Ross William Ulbricht, a.k.a “Dread Pirate Roberts” (DPR), will be charged with a range of criminal violations, including conspiracy to commit drug trafficking, and money laundering.

A screen shot of the Silk Road Web site, taken Oct. 23, 2013.

A screen shot of the Silk Road Web site, taken Oct. 2, 2013.

The Silk Road is an online black market that as late as last month was hosting nearly 13,000 sales listings for controlled substances, including marijuana, LSD, heroin, cocaine, methamphetamine and ecstasy. Much like eBay sellers, merchants on the Silk Road are evaluated by previous buyers, who are encouraged to leave feedback about the quality of the seller’s goods and services.

The Silk Road is not available via the regular Internet. Rather, it is only reachable via the Tor network, an anonymity network that bounces its users communications across a distributed network of relays run by volunteers all around the world.

That is, it was until this week, when FBI agents arrested its alleged proprietor and seized the Web servers running the site. The feds also replaced the Silk Road’s home page with a message saying that the site had been seized by the FBI, Homeland Security Department and the Drug Enforcement Administration.

According to a complaint unsealed this week, Ulbricht alone controlled the massive profits generated from the operation of the business. The government alleges that Ulbricht also controlled and oversaw all aspects of the Silk Road, including: the maintenance of the computer infrastructure and programming code underlying the Silk Road Web site; the determination of vendor and customer policies; decisions about what could be sold on the site; and managing a small staff of online administrators who assisted with the day-to-day operations.

The Silk Road didn’t just sell drugs. For example, the complaint identifies 801 for-sale listings under “digital goods,” which included banking Trojans, pirated content, and hacked accounts at Netflix and Amazon. The ”forgeries” section of the Silk Road featured 169 ads from vendors of fake driver’s licenses, passports, Social Security cards, utility bills, credit card statements, car insurance records, and other forms of identity documents.

An ad for heroin on the Silk Road. Notice this seller has 97 feedback points.

An ad for heroin on the Silk Road. Notice this seller has 97 feedback points.

Another popular section of the Silk Road included 159 listings for generic “Services,” mostly those listed by computer hackers offering such services as hijacking Twitter and Facebook accounts of the customer’s choosing. Other classified ads promised the sale of anonymous bank accounts, counterfeit bills, firearms and ammunition, and even hitmen for hire.

FBI investigators said that on or about March 29, 2013, Ulbricht contacted a Silk Road seller “Redandwhite” to see about hiring him to to take out another Silk Road user — someone going by the nickname “FriendlyChemist” — who was threatening to release the identities of thousands of users of the site.

From the government’s complaint: “Asked what sort of problem FriendlyChemist was causing him, DPR responded in a message dated March 30, 2013, ‘[H]e is threatening to expose the identities of thousands of my clients that he was able to acquire….[T]his kind of behavior is unforgivable to me. Especially here on Silk Road, anonymity is sacrosanct.’” As to the murder-for-hire job he was soliciting, DPR commented that “[i]t doesn’t have to be clean.”

Later that same day, redandwhite sent DPR a message quoting him a price of $150,000 to $300,000, “depending on how you want it done, ‘clean’ or ‘non-clean’.

On March 31, DPR began haggling over the price, responding: “Don’t want to be a pain here, but the price seems high. Not long ago, I had a clean hit done for $80k. Are the prices you quoted the best you can do? I would like this done asap as he is talking about releasing the info on Monday.”

DPR, allegedly using the nickname "altoid" seeks to hire a tech expert for the Silk Road via bitcointalk.org

DPR, allegedly using the nickname “altoid” seeks to hire a tech expert for the Silk Road via bitcointalk.org

According to investigators, the two ultimately settle on a price of $150,000, and that Ulbricht paid for the transaction using Bitcoins — an anonymous virtual currency — sending the would-be hit man 1,670 bitcoins for the arranged hit. Bitcoin currency rates fluctuate quite a bit from day to day, but historic sites that track Bitcoin rates show that one bitcoin around that date in late March 2013 was worth about USD $90, meaning investigators believe Ulbricht paid approximately $150,300 for the hit.

The government’s complaint states that the hit wasn’t carried out, but it also doesn’t seem that FriendlyChemist was the source of investigators’ break in this case. That would come on July 23, 2013, when investigators gained access to a Silk Road server and made a complete copy of the data on the machine.

Nicholas Weaver, a researcher at the International Computer Science Institute (ICSI) and at University of California San Diego, said the information contained on the server seized by investigators indicates that Ulbricht/Dread Pirate Roberts routinely failed to heed his own advice to fellow Silk Road users: Prominent on the Silk Road site were links to tutorials DPR penned which laid out the technologies and techniques that users should adopt if they want to keep off the radar of federal investigators.

“This shows me that the head of the Silk Road wasn’t using [encryption] for all his communications, because [the government] wouldn’t have all of this information otherwise, unless of course he stored his encryption key on the server that was seized,” Weaver said. “Either [the government] got his encryption key off of this server or another server that they were able to access, or he wasn’t using encryption at all.”

The complaint also suggests that in June 2013, Ulbricht accessed a server used to control the Silk Road site from an Internet cafe that was 500 feet from the hotel he was staying at in San Francisco.

“In other words, he wasn’t even using Tor to administer the Silk Road,” Weaver said. “Given that, it’s amazing that he was able to keep this site running for three years.”

Other rookie mistakes also contributed to DPR’s identification as Ross William Ulbricht. In 2011, a person using the nickname “Altoid” posted a comment to the Bitcoin Talk forum trying to get users there to visit the Silk Road. Later in the year, Altoid posted again on the Bitcoin Talk forum, this time seeking an “IT pro” in the Bitcoin community to help with Silk Road administration. In that comment, he posted his Gmail address, the contents of which were later subpoenaed by federal investigators.

Finally, DPR tripped himself up when he ordered some fake IDs from an international Silk Road vendor and had them sent to his residence. The fraudulent IDs were intercepted at the border by customs agents working with the U.S. Department of Homeland Security, which paid a visit to the address to which the documents were to be delivered. The agents noted that while Ulbricht refused to answer any questions about the alleged purchase, one of the identity documents was a California driver’s license bearing Ulbricht’s photo and true date of birth, but with a different name.

Ulbricht's LinkedIn profile, as described by the government's complaint.

Ulbricht’s LinkedIn profile, as described by the government’s complaint.

A number of folks on Twitter, Reddit and other communities are linking to several identities on social media platforms that match up with timelines in the government’s complaint, including this profile on LinkedIn, and this page at Google Plus. According to page 24 of the government’s complaint, Ulbricht graduated from the University of Texas with a bachelors degree in Physics in 2006. From 2006 to 2010, he attended graduate school at the University of Pennsylvania School of Materials Science and Engineering.

The government’s investigation into the Dread Pirate Roberts and Silk Road officially began back in November 2011, when law enforcement agents began making a series of more than 100 individual undercover purchases of controlled substances from Silk Road vendors. Now, many of those vendors — and their customers — have to be wondering how long it may be before investigators come knocking on their doors.

“If I were a seller on the Silk Road, I’d be terrified right now,” Weaver said. “Any buyer that didn’t use encryption now has their Silk Road messages seized. The FBI may have the sellers’ shipping addresses for their customers, and for the sellers, the FBI knows the Bitcoin payout addresses, so then it’s a matter of tracing the Bitcoin wallets from there.”

Weaver pointed to research by Sara Meiklejohn, a graduate student at the University of California, San Diego who’s been analyzing the role of bitcoin and anonymity on the Silk Road. Meiklejohn’s study, A Fistful of Bitcoins: Characterizing Payments Among Men with No Names –  to be released in October 2013 at the ACM Internet Measurement Conference in Barcelona, Spain — lays out different methods that could be used to tie Bitcoin wallets to specific individuals.

According to a press release sent out by the office of the U.S. Attorney for the Southern District of New York, Ulbricht will be presented in San Francisco today. He is charged with conspiracy to traffic in narcotics, computer hacking conspiracy, and money laundering.

The ICSI’s Weaver said that if convicted on the drug charges alone, Ulbricht is facing life in prison.

“The drug trafficking counts include the weights of the drugs, which makes me think that the government wants to throw the book at this guy,” Weaver said, noting that those weights carry mandatory sentences. “The drug charges alone have a 30 year mandatory minimum.”

The government notes in its complaint that most of the drug pushers on the Silk Road sold packets of drugs for individual use (for an example of this, check out the 13 packets of heroin that a cyber fraudster ordered off of the Silk Road in July and had sent to my home in a botched attempt to frame this reporter). But Weaver said the government can apparently aggregate many different individual drug charges because he acted in a role to help facilitate those sales. For example, getting busted for possessing or selling one kilogram of heroin carries a sentence of 10 years to life.

“That’s why I think those weight numbers are in the complaint against him,” Weaver said. “They’re hoping these will trigger mandatory minimum sentences.”

The government also announced today that pursuant to this action, it has seized approximately 26,000 Bitcoins worth roughly $3.6 million, in what it’s calling the largest ever seizure of Bitcoins.

A copy of the complaint is available here (PDF). Apologies for not hosting it on my site, but when I did that earlier, the mad rush from Reddit readers melted my site.

Update, 3:02 p.m. ET: An earlier version of this story incorrectly stated that Ulbricht was charged with attempted murder. While the government’s complaint lays out that alleged conspiracy, it does not state that he was charged with attempted murder….yet.

Update, 5:47 p.m. ET: As Reuters reports, the price of Bitcoin digital currency dropped today, falling to $129 per bitcoin from $140 a day before.

Update, 11:52 p.m. ET: The law blog Popehat has got a great analysis of the charges against Ulbricht, and has even dug up a separate complaint (PDF) against Ulbricht released Oct. 2 by the U.S. District Court for the District of Maryland that levies many of the same charges, including attempted murder. According to this indictment, Ulbricht allegedly ordered what appears to be a separate hit. It looks like this is the other hit job Ulbricht allegedly copped to in the transcript quoted in the main story above: Investigators produced a chat log showing Ulbricht saying a previous hit he ordered only cost $80,000, and in this Maryland complaint says Ulbricht made two payments of $40,000 for this hit job. In this case, the “hit man” Ulbricht allegedly hired was an undercover federal agent.

03 Oct 00:51

Feds shut down Silk Road, arrest alleged admin Dread Pirate Roberts

by Cyrus Farivar
Wikipedia

After nearly three years of operation, the notorious website The Silk Road has finally been shut down and its Tor-enabled domain name seized.

The Silk Road specialized in facilitating the sale of illegal drugs of all sorts via a hidden service website on Tor, conducting its business entirely in Bitcoin. Its founder, known only online via the alias “Dread Pirate Roberts,” has been identified by the Department of Justice as Ross William Ulbricht. The 29-year-old Texan was arrested in San Francisco on Tuesday.

The 39-page criminal complaint details not only charges of narcotics trafficking and money laundering, but also soliciting “a Silk Road user to execute a murder-for-hire of another Silk Road user, who was threatening to release the identities of thousands of users of the site.”

Read 4 remaining paragraphs | Comments


    






01 Oct 01:36

Data Broker Giants Hacked by ID Theft Service

by BrianKrebs

An identity theft service that sells Social Security numbers, birth records, credit and background reports on millions of Americans has infiltrated computers at some of America’s largest consumer and business data aggregators, according to a seven-month investigation by KrebsOnSecurity.

ssndobhomeThe Web site ssndob[dot]ms (hereafter referred to simply as SSNDOB) has for the past two years marketed itself on underground cybercrime forums as a reliable and affordable service that customers can use to look up SSNs, birthdays and other personal data on any U.S. resident. Prices range from 50 cents to $2.50 per record, and from $5 to $15 for credit and background checks. Customers pay for their subscriptions using largely unregulated and anonymous virtual currencies, such as Bitcoin and WebMoney.

Until very recently, the source of the data sold by SSNDOB has remained a mystery. That mystery began to unravel in March 2013, when teenage hackers allegedly associated with the hacktivist group UGNazi showed just how deeply the service’s access went. The young hackers used SSNDOB to collect data for exposed.su, a Web site that listed the SSNs, birthdays, phone numbers, current and previous addresses for dozens of top celebrities — such as performers Beyonce, Kanye West and Jay Z — as well as prominent public figures, including First Lady Michelle Obama, CIA Director John Brennan, and then-FBI Director Robert Mueller.

Earlier this summer, SSNDOB was compromised by multiple attackers, its own database plundered. A copy of the SSNDOB database was exhaustively reviewed by KrebsOnSecurity.com. The database shows that the site’s 1,300 customers have spent hundreds of thousands of dollars looking up SSNs, birthdays, drivers license records, and obtaining unauthorized credit and background reports on more than four million Americans.

Frustratingly, the SSNDOB database did not list the sources of that stolen information; it merely indicated that the data was being drawn from a number of different places designated only as “DB1,” “DB2,” and so on.

But late last month, an analysis of the networks, network activity and credentials used by SSNDOB administrators indicate that these individuals also were responsible for operating a small but very potent botnet — a collection of hacked computers that are controlled remotely by attackers. This botnet appears to have been in direct communications with internal systems at several large data brokers in the United States.  The botnet’s Web-based interface (portions of which are shown below) indicated that the miscreants behind this ID theft service controlled at least five infected systems at different U.S.-based consumer and business data aggregators.

The botnet interface used by  the miscreants who own and operate ssndob[dot]ms

The botnet interface used by the miscreants who own and operate ssndob[dot]ms

DATA-BROKER BOTNET

Two of the hacked servers were inside the networks of Atlanta, Ga.-based LexisNexis Inc., a company that according to Wikipedia maintains the world’s largest electronic database for legal and public-records related information. Contacted about the findings, LexisNexis confirmed that the two systems listed in the botnet interface were public-facing LexisNexis Web servers that had been compromised.

One of two bots connected to SSNDOB that was inside of LexisNexis.

One of two bots connected to SSNDOB that was inside of LexisNexis.

The botnet’s online dashboard for the LexisNexis systems shows that a tiny unauthorized program called “nbc.exe” was placed on the servers as far back as April 10, 2013, suggesting the intruders have had access to the company’s internal networks for at least the past five months. The program was designed to open an encrypted channel of communications from within LexisNexis’s internal systems to the botnet controller on the public Internet.

Two other compromised systems were located inside the networks of Dun & Bradstreet, a Short Hills, New Jersey data aggregator that licenses information on businesses and corporations for use in credit decisions, business-to-business marketing and supply chain management. According to the date on the files listed in the botnet administration panel, those machines were compromised at least as far back as March 27, 2013.

The fifth server compromised as part of this botnet was located at Internet addresses assigned to Kroll Background America, Inc., a company that provides employment background, drug and health screening. Kroll Background America is now part of HireRight, a background-checking firm managed by the Falls Church, Va.-based holding company Altegrity, which owns both the Kroll and HireRight properties. Files left behind by intruders into the company’s internal network suggest the HireRight breach extends back to at least June 2013.

An initial analysis of the malicious bot program installed on the hacked servers reveals that it was carefully engineered to avoid detection by antivirus tools. A review of the bot malware in early September using Virustotal.com – which scrutinizes submitted files for signs of malicious behavior by scanning them with antivirus software from nearly four dozen security firms simultaneously — gave it a clean bill of health: none of the 46 top anti-malware tools on the market today detected it as malicious (as of publication, the malware is currently detected by 6 out of 46 anti-malware tools at Virustotal).

ASSESSING THE DAMAGE

All three victim companies said they are working with federal authorities and third-party forensics firms in the early stages of determining how far the breaches extend, and whether indeed any sensitive information was accessed and exfiltrated from their networks.

For its part, LexisNexis confirmed that the compromises appear to have begun in April of this year, but said it found “no evidence that customer or consumer data were reached or retrieved,” via the hacked systems. The company indicated that it was still in the process of investigating whether other systems on its network may have been compromised by the intrusion.

“Immediately upon becoming aware of this matter, we contacted the FBI and initiated a comprehensive investigation working with a leading third party forensic investigation firm,” said Aurobindo Sundaram, vice president of information assurance and data protection at Reed Elsevier, the parent company of LexisNexis.  ”In that investigation, we have identified an intrusion targeting our data but to date have found no evidence that customer or consumer data were reached or retrieved.  Because this matter is actively being investigated by law enforcement, I can’t provide further information at this time.”

Dun & Bradstreet and Altegrity were less forthcoming about what they’d found so far. Elliot Glazer, chief technology officer at Dun & Bradstreet, said the information provided about the botnet’s interaction with the company’s internal systems had been “very helpful.”

“We are aggressively investigating the matter, take it very seriously and are in touch with the appropriate authorities,” Glazer said. “Data security is a company priority, and I can assure you that we are devoting all resources necessary to ensure that security.”

Altegrity declined to confirm or deny the apparent compromises, but through spokesman Ray Howell offered the following statement: “We consider the protection and safeguarding of our various systems of the utmost importance. We have dedicated significant information security resources to managing security and protecting the data and privacy of our customers. We have a range of incident response specialists and  teams from both inside and outside the company investigating your allegations vigorously.”

Referring to the SSNDOB compromises, FBI Spokesperson Lindsay Godwin confirmed that the FBI is “aware of and investigating this case,” but declined to comment further except to say that the investigation is ongoing.

KNOWLEDGE IS POWER

The intrusions raise major questions about how these compromises may have aided identity thieves. The prevailing wisdom suggests that the attackers were going after these firms for the massive amounts of consumer and business data that they hold. While those data stores are certainly substantial, fraud experts say the really valuable stuff is in the data that these firms hold about consumer and business habits and practices.

The botnet control panel entry for a hacked Dun & Bradstreet server

The botnet control panel entry for a hacked Dun & Bradstreet server

Avivah Litan, a fraud analyst with Gartner Inc., said most credit-granting organizations assess the likelihood that a given application for credit is valid or fraudulent largely based on how accurately an applicant answers a set of questions about their financial and consumer history.

These questions, known in industry parlance as “knowledge-based authentication” or KBA for short, have become the gold standard of authentication among nearly all credit-granting institutions, from loan providers to credit card companies, Litan said. She estimates that the KBA market is worth at least $2 billion a year.

“Let’s say you’re trying to move money via online bank transfer, or apply for a new line of credit,” Litan proposed. “There are about 100 questions and answers that companies like LexisNexis store on all of us, such as, ‘What was your previous address?’ or ‘Which company services your mortgage?’ They also have a bunch of bogus questions that they can serve up to see if you really are who you say you are.”

According to Litan, Dun and Bradstreet does roughly the same thing, except for businesses.

“Dun & Bradstreet doesn’t do KBA per se, but if you’re filling out a business loan and you want to pose as that business, having access to a company like that can help,” Litan said. “Dun & Bradstreet is like the credit bureau for businesses.”

Overall, Litan says, credit applicants fail to answer one or more of the KBA questions correctly about 10-15 percent of the time. Ironically, however, those that get the questions wrong are more often legitimate credit applicants — not the identity thieves.

“These days, the people who fail these questions are mainly those who don’t remember the answers,” Litan said. “But the criminals seem to be having no problems.”

Litan related a story she heard from one fellow fraud analyst who had an opportunity to listen in on the KBA questions that a mortgage lender was asking of a credit applicant who was later determined to have been a fraudster.

“The woman on the phone was asking the applicant, ‘Hey, what is the amount of your last mortgage payment?’, and you could hear the guy on the other line saying hold on a minute….and you could hear him clicking through page after page for the right questions,” Litan said.

The Gartner fraud analyst said she has long suspected that the major KBA providers have been compromised, and has been saying so for years.

“We could well be witnessing the death of knowledge-based authentication, and it’s as it should be,” Litan said. “The problem is that right now there are no good alternatives that are as easy to implement. There isn’t a good software-based alternative. Everybody in the industry knows that KBA is nearing its end of usefulness, but it’s not like you can instantly roll out biometric identifiers to the entire US population. We’re just not there yet. It’s years away. If ever.”

CUSTOMER SERVICE

Breakdown of ssn[dot]dob users by IP address


Breakdown of ssn[dot]dob users by IP address

A closer examination of the database for the identity theft service shows it has served more than 1.02 million unique SSNs to customers and nearly 3.1 million date of birth records since its inception in early 2012.

Thousands of background reports also have been ordered through SSNDOB. Records at the ID theft service indicate that the service was still able to order background reports via LexisNexis more than 10 days after the data aggregator disabled the infected Web servers listed in the botnet’s control panel, suggesting that the intruders still had a store of accounts that could be used to pull information from the company’s databanks.

In a written statement provided to KrebsOnSecurity, LexisNexis officials said that report was generated from a law student ID that was being misused.

“Unrelated to the intrusion you have asked about, you provided to us a LexisNexis report.  We determined that that report was generated from a law student ID that was being misused.  That ID accesses only unregulated public records information and was identified by our fraud detection tools and shut down by us before you brought it to our attention.”

The registration records for SSNDOB show that most users registered with the ID theft service using Internet addresses in the United States, the Russian Federation, and the United Kingdom, although it is likely that a large portion of these users were using hacked PCs or other proxy systems to mask their true location.

SSNDOB also appears to have licensed its system for use by at least a dozen high-volume users. There is some evidence which indicates that these users are operating third-party identity theft services. A review of the leaked site records show that several bulk buyers were given application programming interfaces (APIs) — customized communications channels that allow disparate systems to exchange data — that could permit third-party or competing online ID theft sites to conduct lookups directly and transparently through the SSNDOB Web site.

Indeed, the records from SSNDOB show that the re-sellers of its service reliably brought in more money than manual look-ups conducted by all of the site’s 1,300 individual customers combined.

I would like to thank Alex Holden of Hold Security LLC for his assistance in making sense of much of this data.

Stay tuned for Part II and Part III of this rapidly unfolding story. Update: See Part II of this series: Data Broker Hackers Also Compromised NW3C.

Update, 2:05 p.m. ET: SSNDOB appears to be down. Also, one likely reseller of the ID theft service’s data — a fraud site called bstab[dot]su, has been having trouble all morning looking up SSN data. Lookups at that service are sending paying customers into an endless loop today. See image below.

bstabssndown

06 Sep 01:22

How to handle millions of new Tor clients

by arma
James007wjs

A Litecoin pool had a user hit 2.5GH/s around the same time frame as this increase of tor clients. Most likely same person/group.

[tl;dr: if you want your Tor to be more stable, upgrade to a Tor Browser Bundle with Tor 0.2.4.x in it, and then wait for enough relays to upgrade to today's 0.2.4.17-rc release.]

Starting around August 20, we started to see a sudden spike in the number of Tor clients. By now it's unmistakable: there are millions of new Tor clients and the numbers continue to rise:

Tor users in summer 2013

Where do these new users come from? My current best answer is a botnet.

Some people have speculated that the growth in users comes from activists in Syria, Russia, the United States, or some other country that has good reason to have activists and journalists adopting Tor en masse lately. Others have speculated that it's due to massive adoption of the Pirate Browser (a Tor Browser Bundle fork that discards most of Tor's security and privacy features), but we've talked to the Pirate Browser people and the downloads they've seen can't account for this growth. The fact is, with a growth curve like this one, there's basically no way that there's a new human behind each of these new Tor clients. These Tor clients got bundled into some new software which got installed onto millions of computers pretty much overnight. Since no large software or operating system vendors have come forward to tell us they just bundled Tor with all their users, that leaves me with one conclusion: somebody out there infected millions of computers and as part of their plan they installed Tor clients on them.

It doesn't look like the new clients are using the Tor network to send traffic to external destinations (like websites). Early indications are that they're accessing hidden services — fast relays see "Received an ESTABLISH_RENDEZVOUS request" many times a second in their info-level logs, but fast exit relays don't report a significant growth in exit traffic. One plausible explanation (assuming it is indeed a botnet) is that it's running its Command and Control (C&C) point as a hidden service.

My first observation is "holy cow, the network is still working." I guess all that work we've been doing on scalability was a good idea. The second observation is that these new clients actually aren't adding that much traffic to the network. Most of the pain we're seeing is from all the new circuits they're making — Tor clients build circuits preemptively, and millions of Tor clients means millions of circuits. Each circuit requires the relays to do expensive public key operations, and many of our relays are now maxed out on CPU load.

There's a possible dangerous cycle here: when a client tries to build a circuit but it fails, it tries again. So if relays are so overwhelmed that they each drop half the requests they get, then more than half the attempted circuits will fail (since all the relays on the circuit have to succeed), generating even more circuit requests.

So, how do we survive in the face of millions of new clients?

Step one was to see if there was some simple way to distinguish them from other clients, like checking if they're using an old version of Tor, and have entry nodes refuse connections from them. Alas, it looks like they're running 0.2.3.x, which is the current recommended stable.

Step two is to get more users using the NTor circuit-level handshake, which is new in Tor 0.2.4 and offers stronger security with lower processing overhead (and thus less pain to relays). Tor 0.2.4.17-rc comes with an added twist: we prioritize NTor create cells over the old TAP create cells that 0.2.3 clients send, which a) means relays will get the cheap computations out of the way first so they're more likely to succeed, and b) means that Tor 0.2.4 users will jump the queue ahead of the botnet requests. The Tor 0.2.4.17-rc release also comes with some new log messages to help relay operators track how many of each handshake type they're handling.

(There's some tricky calculus to be done here around whether the botnet operator will upgrade his bots in response. Nobody knows for sure. But hopefully not for a while, and in any case the new handshake is a lot cheaper so it would still be a win.)

Step three is to temporarily disable some of the client-side performance features that build extra circuits. In particular, our circuit build timeout feature estimates network performance for each user individually, so we can tune which circuits we use and which we discard. First, in a world where successful circuits are rare, discarding some — even the slow ones — might be unwise. Second, to arrive at a good estimate faster, clients make a series of throwaway measurement circuits. And if the network is ever flaky enough, clients discard that estimate and go back and measure it again. These are all fine approaches in a network where most relays can handle traffic well; but they can contribute to the above vicious cycle in an overloaded network. The next step is to slow down these exploratory circuits in order to reduce the load on the network. (We would temporarily disable the circuit build timeout feature entirely, but it turns out we had a bug where things get worse in that case.)

Step four is longer-term: there remain some NTor handshake performance improvements that will make them faster still. It would be nice to get circuit handshakes on the relay side to be really cheap; but it's an open research question how close we can get to that goal while still providing strong handshake security.

Of course, the above steps aim only to get our head back above water for this particular incident. For the future we'll need to explore further options. For example, we could rate-limit circuit create requests at entry guards. Or we could learn to recognize the circuit building signature of a bot client (maybe it triggers a new hidden service rendezvous every n minutes) and refuse or tarpit connections from them. Maybe entry guards should demand that clients solve captchas before they can build more than a threshold of circuits. Maybe we rate limit TAP handshakes at the relays, so we leave more CPU available for other crypto operations like TLS and AES. Or maybe we should immediately refuse all TAP cells, effectively shutting 0.2.3 clients out of the network.

In parallel, it would be great if botnet researchers would identify the particular characteristics of the botnet and start looking at ways to shut it down (or at least get it off of Tor). Note that getting rid of the C&C point may not really help, since it's the rendezvous attempts from the bots that are hurting so much.

And finally, I still maintain that if you have a multi-million node botnet, it's silly to try to hide it behind the 4000-relay Tor network. These people should be using their botnet as a peer-to-peer anonymity system for itself. So I interpret this incident as continued exploration by botnet developers to try to figure out what resources, services, and topologies integrate well for protecting botnet communications. Another facet of solving this problem long-term is helping them to understand that Tor isn't a great answer for their problem.

22 Aug 02:47

EFF Wins Release of Secret Court Opinion: NSA Surveillance Unconstitutional

by samzenpus
mspohr writes "For over a year, EFF has been fighting the government in federal court to force the public release of an 86-page opinion of the secret Foreign Intelligence Surveillance Court (FISC). Issued in October 2011, the secret court's opinion found that surveillance conducted by the NSA under the FISA Amendments Act was unconstitutional and violated 'the spirit of' federal law."

Share on Google+

Read more of this story at Slashdot.








22 Aug 02:33

NSA collected up to 56,000 emails not connected to terrorism a year, blames error

by Brian Heater

We can't say as though we're particularly surprised to see such numbers, but, well, at least they're finally coming to light. According to The Washington Post, newly declassified court documents highlight how the NSA collected up to 56,000 e-mails per year, over a three year period. The docs detail why the collection of such "wholly domestic" information was ruled unconstitutional by a judge in the Foreign Intelligence Surveillance Court, though the NSA stated that the surveillance was unintentional, adding that it reported said information to the court. As part of the ruling, the intelligence agency was required to investigate limits to its data collection -- the NSA claims to have since addressed the problem. The newly available information was made public thanks to a recently field EFF lawsuit.

Update: Want to crawl through some of that information? The White House has begun posting key docs to Tumblr, of all places.

Filed under: Internet

Comments

Source: EFF, The Washington Post

22 Aug 00:07

Manning Senteced To 35 Years

by Unknown Lamer
An anonymous reader writes with bad, but not unexpected news: "The U.S. soldier convicted of handing a trove of secret government documents to anti-secrecy website Wikileaks has been sentenced to 35 years in prison. Pte First Class Bradley Manning, 25, was convicted in July of 20 charges against him, including espionage. Last week, he apologized for hurting the US and for "the unexpected results" of his actions.He will receive credit for three and a half years, but be dishonorably discharged from the US Army."

Share on Google+

Read more of this story at Slashdot.








20 Aug 23:13

Joining Lavabit Et Al, Groklaw Shuts Down Because of NSA Dragnet

by Unknown Lamer
An anonymous reader was the first to write with news that Groklaw is shutting down: "There is now no shield from forced exposure. Nothing in that parenthetical thought list is terrorism-related, but no one can feel protected enough from forced exposure any more to say anything the least bit like that to anyone in an email, particularly from the U.S. out or to the U.S. in, but really anywhere. You don't expect a stranger to read your private communications to a friend. And once you know they can, what is there to say? Constricted and distracted. That's it exactly. That's how I feel. So. There we are. The foundation of Groklaw is over. I can't do Groklaw without your input. I was never exaggerating about that when we won awards. It really was a collaborative effort, and there is now no private way, evidently, to collaborate."

Share on Google+

Read more of this story at Slashdot.








19 Aug 03:33

Wikileaks Releases A Massive "Insurance" File That No One Can Open

by samzenpus
An anonymous reader writes " Anti-secrecy organization WikiLeaks just released a treasure trove of files, that at least for now, you can't read. The group, which has been assisting ex-NSA contractor Edward Snowden after he leaked top-secret documents to the media, posted links for about 400 gigabytes of files on their Facebook page Saturday, and asked their fans to download and mirror them elsewhere."

Share on Google+

Read more of this story at Slashdot.








12 Jul 14:44

Exposed SSH Key Means US Emergency Alert System Can Be Hacked

by timothy
wiredmikey writes "Recently discovered security flaws in the Emergency Alerting System (EAS) which is widely used by TV and radio stations across the United States, has made the systems vulnerable to remote attack. The vulnerability stems from an SSH key that is hard-coded into DASDEC-I and DASDEC-II devices made by Monroe Electronics. Unless the default settings were altered during deployment, impacted systems are using a known key that could enable an attacker with full access if the systems are publicly faced or if they've already compromised the network. By exploiting the vulnerability, an attacker could disrupt a station's ability to transmit and/or could send out false emergency information. 'Earlier this year we were shown an example of an intrusion on the EAS when the Montana Television Network's regular programming was interrupted by news of a zombie apocalypse. Although there was no zombie apocalypse, it did highlight just how vulnerable the system is,' said Mike Davis, a principal research scientist at IOActive. The DHS issued an alert on the vulnerability, and IOActive, the firm that discovered the flaw, has published additional technical details (PDF) on the security issue."

Share on Google+

Read more of this story at Slashdot.



28 Jun 00:06

Hidden Services need some love

by asn

Hidden Services are in a peculiar situation. While they see a loyal fan-base, there are no dedicated Tor developers to take care of them. This results in a big pile of features that need to be researched, implemented and deployed to make Hidden Services more secure and effective.

The purpose of this blog post is threefold:

  1. Introduce Hidden Service operators to various shortcomings of the Hidden Service architecture.
  2. Introduce researchers to various research questions regarding Hidden Services.
  3. Introduce developers to the plethora of coding tasks left to be done in the hidden Service ecosystem.


Note that not every idea listed in the blog post is going to turn out to be a great idea. This post is more of a brain-dump than a solid fully-analyzed agenda.

In any case, let's get down to the issues:




Hidden Service Scaling


The current Hidden Services architecture does not scale well. Ideally, big websites should have the option to completely migrate to Tor Hidden Services, but this is not possible with their current architecture.

One of the main problems with a busy Hidden Service is that its Introduction Points will get hammered by clients. Since Introduction Points are regular Tor relays, they are not intended to handle such load.

Therefore, one of the first steps for improving Hidden Services scalability is increasing the durability of its Introduction Points. Currently, a Hidden Service selects the number of its Introduction Points (between one and ten) based on a self-estimation of its own popularity. Whether the formula currently used is the best such formula is an open research question.

Another problem with Hidden Services is the lack of load balancing options. While you can load-balance a Hidden Service using TCP/HTTP load balancers (like HAProxy), there is no load-balancing option similar to DNS round-robin, where load balancing happens by sending clients to different server IP addresses. Such load-balancing could be achieved by allowing a Hidden Service to have multiple "subservices". Such an architecture, although appealing, introduces multiple problems, like the intercommunication between subservices, where the long-term keypair is stored, how introduction points are assigned, etc.


Defense against Denial of Service of Introduction Points


The adversarial version of the previous section involves attackers intentionally hammering the Introduction Points of a Hidden Service to make it unreachable by honest clients. This means that an attacker can temporarily bring down a Hidden Service by DoSing a small number of Tor relays.

To defend against such attacks, Syverson and Øverlier introduced Valet nodes in their PETS 2006 paper: "Valet Services: Improving Hidden Servers with a Personal Touch". Valet nodes stand in front of Introduction Points and act as a protection layer. This allows Hidden Services to maintain a limited number of Introduction Points, but many more contact points, without clients learning the actual addresses of the Introduction Points.

Valet nodes are not implemented yet, mainly because of the big implementation and deployment effort they require.


Key Length


The long-term keypair of a Hidden Service is an RSA-1024 keypair which nowadays is considered weak. This means that in the future, Hidden Services will need to migrate to a different keysize and/or asymmetric cryptographic algorithm.

A side effect of such migration is that Hidden Services will get a different onion address, which might be troublesome for Hidden Services that have a well-established onion address. To make the transition smoother, Hidden Services should be able to use both old and new keypairs for a while to be able to point their clients to the new address.

Unfortunately, while design work has started on strengthening some parts of Tor's cryptography, there are no proposals on improving the cryptography of Hidden Services yet.


Attacks by Hidden Service Directory Servers


Hidden Services upload their descriptor to Tor nodes called Hidden Service Directory Servers (HSDirs). Clients then fetch that descriptor and use it to connect to the Hidden Service.

In the current system, HSDirs are in an interesting position which allows them to perform the following actions:

  • Learn the .onion address of a Hidden Service and connect to it
  • Evaluate the popularity of a Hidden Service by tracking the number of clients who do a lookup for that Hidden Service
  • Refuse to answer a client, and if enough HSDirs do this then the Hidden Service is temporarily unreachable

These scenarios are explored in the upcoming IEEE S&P paper titled "Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization" from Alex Biryukov, Ivan Pustogarov and Ralf-Philipp Weinmann. Be sure to check it out (once they publish it)!

Let's look at some suggested fixes for the attacks that Hidden Service Directory Servers can perform:


Defences against enumeration of onion addresses

Hidden Services use a hash ring to choose which HSDirs will host their descriptor; this means that HSDirs can just wait to get picked by Hidden Services and then collect their descriptors and onion addresses. Also, since the hash ring is rotating, HSDirs get new Hidden Service descriptors in every rotation period.

One possible solution to this issue would be to append a symmetric key to the onion address and use it to encrypt the descriptor before sending it to HSDirs (similar to how descriptor-cookie authentication works currently). A client that knows the onion address can decrypt the descriptor, but an HSDir who doesn't know the onion address can't derive the Hidden Service name. The drawback of this scheme is that the size of onion addresses will increase without increasing the security of their self-authentication property. Furthermore, HSDirs will still be able to extract the Hidden Service public key from the descriptor, which allows HSDirs to track the descriptors of specific Hidden Services.

A different solution was proposed by Robert Ransom:

Robert's scheme uses the long-term keypair of a Hidden Service to derive (in a one-way fashion) a second keypair, which is used to encrypt and sign the descriptor that is uploaded to the HSDirs. This construction allows the HSDir, without knowing the long-term keypair of the Hidden Service or the contents of its descriptor, to validate that the entity who uploaded the descriptor had possession of the long-term private key of the Hidden Service. A client who knows the long-term public key of the Hidden Service can fetch the descriptor from the HSDir and verify that it was created by the Hidden Service itself. See the relevant trac ticket for a more robust analysis of the idea.

Robert's idea increases the size of onion addresses, but also makes them more resistant to impersonation attacks (the current 80-bit security of onion addresses does not inspire confidence against impresonation attacks). Furthermore, his idea does not allow HSDirs to track Hidden Service descriptors across time.

While Robert's scheme is fairly straightforward, a proper security evaluation is in order and a Tor proposal needs to be written. For extra fun, his idea requires the long-term keypair of the Hidden Service to use a discrete-log cryptosystem, which means that a keypair migration will be needed if we want to proceed with this plan.


Block tracking of popularity of Hidden Services

HSDirs can track the number of users who do a lookup for a Hidden Service, thereby learning how popular they are. We can make it harder for HSDirs to track the popularity of a Hidden Service, by utilizing a Private Information Retrieval (PIR) protocol for Hidden Service descriptor fetches. Of course, this won't stop the Introduction Points of a Hidden Service from doing the tracking, but since the Introduction Points were picked by the Hidden Service itself, the threat is smaller.

If we wanted to block Introduction Points from tracking the popularity of Hidden Services, we could attempt hiding the identity of the Hidden Service from its Introduction Points by using a cookie scheme, similar to how the Rendezvous is currently done, or by using Robert's keypair derivation trick and signing the introduction establishment with the new keypair. A careful security evaluation of these ideas is required.


Make it harder to become an adversarial HSDir

Because of the security implications that HSDirs have for a Hidden Services, we started working on making it harder for a Tor relay to become an HSDir node.

Also, currently, an adversary can predict the identity keys it will need in the future to target a specific Hidden Service. We started thinking of ways to avoid this attack.


Performance improvements


Hidden services are slooooowwww and we don't even understand why. They might be slow because of the expensive setup process of creating a Hidden Service circuit, or because Hidden Service circuits have 6 hops, or because of something else. Many suggestions have been proposed to reduce the latency of Hidden Services, ranging from Hidden Service protocol hacks to Javascript hacks, and to radically changing how the Hidden Service circuit is formed.

Let's investigate some of these proposals:


Reducing Hidden Service Circuit Setup complexity

During PETS 2007 Syverson and Øverlier presented "Improving Efficiency and Simplicity of Tor circuit establishment and hidden services" which simplifies Hidden Service circuit establishmentby eliminating the need of a separate rendezvous connection.

They noticed that by using Valet nodes, the concept of Rendezvous Points is redundant and that a Hidden Service circuit can be formed by just using Valet nodes and Introduction Points. Karsten Loesing wrote a Tor proposal for a variant of this idea.

The reason this scheme is not implemented is that the security trade-offs introduced are not well understood, and there are also some technical obstacles (like the fact that sharing of circuits between multiple clients is not currently supported).


Analyze Hidden Service Circuit Establishment Timing With Torperf

Establishing a connection to a hidden service currently involves two Tor relays, the introduction and rendezvous point, and 10 more relays distributed over four circuits to connect to them. No one has really researched how much time Tor spends in each step of that complicated process. It wouldn't be surprising if a large amount of time is spent in an unexpected part of the process.

To investigate this properly, one should use Torperf to analyze the timing delta between the steps of the process. Unfortunately, Torperf uses controller events to distinguish between Tor protocol phases but not all steps of the Hidden Service circuit setup have controller events assigned to them. Implementing this involves adding the control port triggers to the Tor codebase, running Torperf and then collecting and analyzing the results.


Hidden Services should reuse old Introduction Points

Currently, Hidden Services stop establishing circuits to old Introduction Points after they break. While this behavior makes sense, it means that clients who have old hidden service descriptors will keep introducing themselves to the wrong introduction points. This is especially painful in roaming situations where users frequently change networks (and lose existing circuits).

A solution to this would be for Hidden Services to reestablish failed circuits to old Introduction Points (if the circuits were destroyed because of network failures). We should explore the security consequences of such a move, and also what's the exact time period that Introduction Points are considered "old" but still "worth reestablishing circuits to".


Encrypted Services


Encrypted Services is the correct way of implementing the now-defunct Exit Enclaves.

Encrypted Services allow you to run a non-anonymous Hidden Service where the server-side rendezvous circuit is only one hop. This makes sense in scenarios where the Hidden Service doesn't care about its anonymity, but still wants to allow its clients to access it anonymously (and with all the other features that self-authenticating names provide). See Roger's original proposal for more use cases and information.

On this topic, Robert Ransom proposed to implement Encrypted Services as a program separate from Tor, since it serves a quite different threat model. Furthermore, if done this way, its users won't overload the Tor network and it will also allow greater versatility and easier deployment.


Human Memorable onion addresses


Zooko's triangle characterizes onion addresses as secure and global, but not human memorable. By now a couple of schemes have been proposed to make hidden services addresses memorable, but for various reasons none of them has been particularly successful.




These were just some of the things that must be done in the Hidden Services realm. If you are interested in helping around, please read the links and trac tickets, and hit us back with proposals, patches and suggestions. Use the [tor-dev] mailing list, or our IRC channels for development-related communication.

Finally, note that this blog post only touched issues that involve Tor's codebase or the Hidden Service protocol and its cryptography. However, if we want Hidden Services to be truly successful and influential, it's also important to build a vibrant ecosystem around them. For example, we need privacy-preserving archiving systems and search engines (and technologies and rules on how they should work), we need easy-to-use publishing platforms, Internet service daemons and protocols optimized for high-latency connections, anonymous file sharing, chat systems and social networks.

Thanks go to Roger, Robert and other people for the helpful comments and suggestions on this blog post.

PS: Don't forget to use anonbib to find and download any research papers mentioned in this blog post.

11 Jun 04:58

Government Secrets and the Need for Whistle-blowers

Yesterday, we learned that the NSA received all calling records from Verizon customers for a three-month period starting in April. That's everything except the voice content: who called who, where they were, how long the call lasted -- for millions of people, both Americans and foreigners. This "metadata" allows the government to track the movements of everyone during that period,...
11 Jun 04:50

NSA WhistleBlower Outs Himself

by samzenpus
An anonymous reader writes "The individual responsible for one of the most significant leaks in US political history is Edward Snowden, a 29-year-old former technical assistant for the CIA and current employee of the defense contractor Booz Allen Hamilton. Snowden has been working at the National Security Agency for the last four years as an employee of various outside contractors, including Booz Allen and Dell. The Guardian, after several days of interviews, is revealing his identity at his request. From the moment he decided to disclose numerous top-secret documents to the public, he was determined not to opt for the protection of anonymity. 'I have no intention of hiding who I am because I know I have done nothing wrong,' he said."

Share on Google+

Read more of this story at Slashdot.