HomeLogin

New Tor-Ramdisk fixes CVE-2014-5117

8 August, 2014 at 1:33 pm by anonymous!
olympic_trained_babe

A new version of the Tor Ramdisk minimal Linux distribution is released. This release fixes the security flaw known as “CVE-2014-5117″.

Official story is:

I want to announce to the list that a new release of tor-ramdisk is out.
Tor-ramdisk is an i686 or x86_64 uClibc-based micro Linux distribution
whose only purpose is to host a Tor server in an environment that
maximizes security and privacy. Security is enhanced by hardening the
kernel and binaries, and privacy is enhanced by forcing logging to be
off at all levels so that even the Tor operator only has access to
minimal information. Finally, since everything runs in ephemeral memory,
no information survives a reboot, except for the Tor configuration file
and the private RSA key, which may be exported/imported by FTP or SCP.

Changelog:

tor was updated to 0.2.4.23 which addresses CVE-2014-5117. The kernel
was updated to 3.15.7+ Gentoo’s hardened-patches-3.15.7-1.extras. All
other packages are the same as the previous release. It is recommended
that users upgrade immediately. For more information see
https://lists.torproject.org/pipermail/tor-announce/2014-July/000094.html.

i686:
Homepage: http://opensource.dyc.edu/tor-ramdisk
Download: http://opensource.dyc.edu/tor-ramdisk-downloads

x86_64:
Homepage: http://opensource.dyc.edu/tor-x86_64-ramdisk
Download: http://opensource.dyc.edu/tor-x86_64-ramdisk-downloads


British man arrested for running a proxy

8 August, 2014 at 12:13 pm by anonymous!
2473

The UK City of London Police (PIPCU), a London-based private army, recently  arrested a young man for running a proxy server which allows people in the United Kingdom to read things  on the Internet.

From The Register:

City of London cops have ventured outside the M25 to cuff a suspect in Nottingham under the suspicion that he runs a “proxy server” which allows users to access 36 verboten sites.

Officers from City Police’s Intellectual Property Crime Unit (PIPCU) said they’d arrested and questioned a 20-year-old man suspected of running an “umbrella website” that provided access to websites that are currently subject to blocking orders.

The criminal mastermind of this atrocity, Detective Chief Inspector Andy Fyfe of PIPCU, had this comment:

 “This week’s operation highlights how PIPCU, working in partnership with the creative and advertising industries is targeting every aspect of how copyrighting material is illegally being made available to internet users. “

It is interesting to note that it is not against any UK law to run a proxy service yet the PIPCU corporation went on and destroyed this young mans life anyway – just because the entertainment industry asked them to do so. The word for this is fascism.


Netherlands terrorist organization admit to hacking Tor hidden service sites

7 August, 2014 at 1:53 am by anonymous!

Wierd story regarding “Operation Torpedo” is this:

“Operation Torpedo began with an investigation in the Netherlands in
August 2011. Agents at the National High Tech Crime Unit of the
Netherlands’ national police force had decided to crack down on online
child porn, according to an FBI affidavit. To that end, they wrote a web
crawler that scoured the Dark Net, collecting all the Tor onion
addresses it could find.

The NHTCU agents systematically visited each of the sites and made a
list of those dedicated to child pornography. Then, armed with a search
warrant from the Court of Rotterdam, the agents set out to determine
where the sites were located.

That, in theory, is a daunting task—Tor hidden services mask their
locations behind layers of routing. But when the agents got to a site
called “Pedoboard,” they discovered that the owner had foolishly left
the administrative account open with no password. They logged in and
began poking around, eventually finding the server’s real Internet IP
address in Bellevue, Nebraska.”

Full Wierd story here. The “National High Tech Crime Unit” terrorist organization from the Netherlands are clearly admitting that they are trying to gain unlawful access to totally legal (and some not legal) websites because they happen to be hosted using Tor hidden services. Their code-name for this “operation” is “Descartes”.


All data stored by US corporations anywhere in the world should be accessible to US government, judge rules

1 August, 2014 at 2:52 am by anonymous!

If you use a US corporation to store your e-mail or other data (cloud services, etc)  then your data may be inspected by United States of Fascism Corporation subsidiaries such as the NSA and the FBI even if you yourself are not US property and your data is stored outside of the USA.

Full RT story:

A federal judge in New York City sided with the United States government on Thursday and said that Microsoft must comply with a search warrant compelling the corporation to surrender customer data it stores overseas.

The multi-national computer company has for months now refused to turn over emails and other digital content requested by authorities in the US because the information in question, Microsoft insists, is kept on data servers physically located in Ireland. Previously, Microsoft said in a statement that “a US prosecutor cannot obtain a US warrant to search someone’s home located in another country, just as another country’s prosecutor cannot obtain a court order in her home country to conduct a search in the United States.”

But District Judge Loretta Preska ruled from a Manhattan courtroom on Thursday that, contrary to the company’s objections, Microsoft must produce the information sought pursuant to a US-based investigation.

“It is a question of control, not a question of the location of that information,” Preska said at the conclusion of a two-hour court hearing, Reuters reported from New York.

Microsoft said that it will challenge that ruling, however, and Preska has placed a stay on her decision to keep the order from going into effect ahead of the Second US Circuit Court of Appeal’s anticipated analysis.

“The only issue that was certain this morning was that the District Court’s decision would not represent the final step in this process,” Microsoft said in a statement, the Washington Post reported..

“We will appeal promptly and continue to advocate that people’s e-mail deserves strong privacy protection in the US and around the world,” added the Redmond, Washington-based tech giant.

On the evening before Wednesday’s decision, Microsoft general counsel Brad Smith insisted in an Wall Street Journal op-ed that content stored on the web’s “cloud” — or data that can be accessed from most anywhere with the internet even if it physically exists in a single spot — must have the same legal protections as private property.

“This dispute should be important to you if you use emails,” Smith wrote, “because it could well turn on who owns your email — you or the company that stores it in the cloud.”

“The US government position contravenes the longstanding principle that warrants issued by US courts are generally not enforceable outside the US. It also conflicts with the concept of comity, which US courts have long recognized requires them to give due regard — and, where appropriate, deference — to the laws and legal system of a foreign country,” the Center for Democracy and Technology said in a statement this week. “Applying the US government’s position on a globally reciprocal basis would yield chaos, with governments serving demands on local representatives of global companies seeking disclosure of data stored elsewhere and covered by the laws of the country where it is stored.”


CIA Admits Spying On Senate Computers

31 July, 2014 at 5:46 pm by anonymous!
spy

It’s not been a good day for the CIA. First, the State Department slams them for brutally treating terror suspects after the 9/11 attacks, noting that “no American is proud” of CIA tactics. And now, as The NY Times reports, an internal investigation has found that its officers improperly penetrated a computer network used by the Senate Intelligence Committee in preparing the report on the CIA’s detention and interrogation program. Of course, this is not the first time the CIA has hacked Senate networks but do not fear American citizenry, CIA Director has apologized for his staff “acting inappropriately” and is setting up an internal accountability board to review the matter.

The report is damning… (via AP)

The State Department has endorsed the broad conclusions of a harshly critical Senate report on the CIA’s interrogation and detention practices after the 9/11 attacks, a report that accuses the agency of brutally treating terror suspects and misleading Congress, according to a White House document.

“This report tells a story of which no American is proud,” says the four-page White House document, which contains the State Department’s preliminary proposed talking points in response to the classified Senate report, a summary of which is expected to be released in the coming weeks.

The Senate report concludes that CIA’s techniques on al-Qaida detainees captured after the 2001 attacks were far more brutal than previously understood. The tactics failed to produce life-saving intelligence, the report asserts, and the CIA misled Congress and the Justice Department about the interrogation program.

So it is no wonder the CIA decided it was above the law and hacked the Senate’s PCs… (via NY Times)

In a statement issued Thursday morning, a C.I.A. spokesman said that agency’s inspector general had concluded that C.I.A. officers had acted inappropriately by gaining access to the computers.

The statement said that John O. Brennan, the C.I.A. director, had apologized to the two senior members of the Senate Intelligence Committee and that he would set up an internal accountability board to review the matter. The board will be led by former Senator Evan Bayh, Democrat of Indiana.

The statement gave almost no specifics about the findings of the report, written by David Buckley, the agency’s inspector general.

Officials said there was a tense meeting earlier this week when Mr. Brennan briefed the two senators — Dianne Feinstein, Democrat of California and Saxby Chambliss, Republican of Georgia. The officials said Ms. Feinstein had confronted Mr. Brennan about past public statements on the issue, in which he defended the agency’s actions.

Of course Brennan denied it all when Feinstein first lost her temper over it…

When the C.I.A.’s monitoring of the committee became public in March Mr.
Brennan said, “When the facts come out on this, I think a lot of people
who are claiming that there has been this tremendous sort of spying and
monitoring and hacking will be proved wrong.”

Nope – you lied… and once again there is no accountability.


Security issue in Tails 1.1 and earlier

30 July, 2014 at 5:27 pm by anonymous!

Several vulnerabilities have been discovered in I2P which is shipped in
Tails 1.1 and earlier [12]. I2P [13] is an anonymous overlay network
with many similarities to Tor. There was quite some confusion around the
disclosure process of this vulnerability. Readers are encouraged to read
what the Tails team has written about it [14].

Starting I2P in Tails normally requires a click on the relevant menu
entry. Once started, the security issues can lead to the deanonymization
of a Tails user who visits a malicious web page. As a matter of
precaution, the Tails team recommends removing the “i2p” package each
time Tails is started.

I2P has fixed the issue in version 0.9.14 [15]. It is likely to be
included in the next Tails release, but the team is also discussing [16]
implementing more in-depth protections that would be required in order
to keep I2P in Tails.

[12]: https://tails.boum.org/security/Security_hole_in_I2P_0.9.13/
[13]: https://geti2p.net/
[14]: https://tails.boum.org/news/On_0days_exploits_and_disclosure/
[15]: https://geti2p.net/en/blog/post/2014/07/26/0.9.14-Release
[16]: https://mailman.boum.org/pipermail/tails-dev/2014-July/006459.html


Tor security advisory: “relay early” traffic confirmation attack

30 July, 2014 at 10:03 am by anonymous!
YuRi<3

SUMMARY:
On July 4 2014 we found a group of relays that we assume were trying
to deanonymize users. They appear to have been targeting people who
operate or access Tor hidden services. The attack involved modifying
Tor protocol headers to do traffic confirmation attacks.

The attacking relays joined the network on January 30 2014, and we
removed them from the network on July 4. While we don’t know when they
started doing the attack, users who operated or accessed hidden services
from early February through July 4 should assume they were affected.

Unfortunately, it’s still unclear what “affected” includes. We know
the attack looked for users who fetched hidden service descriptors,
but the attackers likely were not able to see any application-level
traffic (e.g. what pages were loaded or even whether users visited
the hidden service they looked up). The attack probably also tried to
learn who published hidden service descriptors, which would allow the
attackers to learn the location of that hidden service. In theory the
attack could also be used to link users to their destinations on normal
Tor circuits too, but we found no evidence that the attackers operated
any exit relays, making this attack less likely. And finally, we don’t
know how much data the attackers kept, and due to the way the attack
was deployed (more details below), their protocol header modifications
might have aided other attackers in deanonymizing users too.

Relays should upgrade to a recent Tor release (0.2.4.23 or
0.2.5.6-alpha), to close the particular protocol vulnerability the
attackers used — but remember that preventing traffic confirmation in
general remains an open research problem. Clients that upgrade (once
new Tor Browser releases are ready) will take another step towards
limiting the number of entry guards that are in a position to see
their traffic, thus reducing the damage from future attacks like this
one. Hidden service operators should consider changing the location of
their hidden service.

THE TECHNICAL DETAILS:
We believe they used a combination of two classes of attacks: a traffic
confirmation attack and a Sybil attack.

A traffic confirmation attack is possible when the attacker controls
or observes the relays on both ends of a Tor circuit and then compares
traffic timing, volume, or other characteristics to conclude that the
two relays are indeed on the same circuit. If the first relay in the
circuit (called the “entry guard”) knows the IP address of the user,
and the last relay in the circuit knows the resource or destination
she is accessing, then together they can deanonymize her. You can read
more about traffic confirmation attacks, including pointers to many
research papers, at this blog post from 2009:
https://blog.torproject.org/blog/one-cell-enough

The particular confirmation attack they used was an active attack where
the relay on one end injects a signal into the Tor protocol headers,
and then the relay on the other end reads the signal. These attacking
relays were stable enough to get the HSDir (“suitable for hidden
service directory”) and Guard (“suitable for being an entry guard”)
consensus flags:
https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1775
Then they injected the signal whenever they were used as a hidden
service directory, and looked for an injected signal whenever they
were used as an entry guard.

The way they injected the signal was by sending sequences of “relay”
vs “relay early” commands down the circuit, to encode the message they
want to send. For background, Tor has two types of cells: link cells,
which are intended for the adjacent relay in the circuit, and relay
cells, which are passed to the other end of the circuit.

https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l364

In 2008 we added a new kind of relay cell, called a “relay early”
cell, which is used to prevent people from building very long paths
in the Tor network (very long paths can be used to induce congestion
and aid in breaking anonymity):
http://freehaven.net/anonbib/#congestion-longpaths
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/110-avoid-infinite-circuits.txt
But the fix for infinite-length paths introduced a problem with
accessing hidden services:
https://trac.torproject.org/projects/tor/ticket/1038
and one of the side effects of our fix for bug 1038 was that while
we limit the number of outbound (away from the client) “relay early”
cells on a circuit, we don’t limit the number of inbound (towards the
client) relay early cells:
https://lists.torproject.org/pipermail/tor-commits/2009-July/014679.html

So in summary, when Tor clients contacted an attacking
relay in its role as a Hidden Service Directory to publish
or retrieve a hidden service descriptor (steps 2 and 3 on
https://www.torproject.org/docs/hidden-services), that relay would
send the hidden service name (encoded as a pattern of relay and
relay-early cells) back down the circuit. Other attacking relays,
when they get chosen for the first hop of a circuit, would look for
inbound relay-early cells (since nobody else sends them) and would
thus learn which clients requested information about a hidden service.

There are three important points about this attack:

A) The attacker encoded the name of the hidden service in the injected
signal (as opposed to, say, sending a random number and keeping a local
list mapping random number to hidden service name). The encoded signal
is encrypted as it is sent over the TLS channel between relays. However,
this signal would be easy to read and interpret by anybody who runs
a relay and receives the encoded traffic. And we might also worry
about a global adversary (e.g. a large intelligence agency) that
records Internet traffic at the entry guards and then tries to break
Tor’s link encryption. The way this attack was performed weakens Tor’s
anonymity against these other potential attackers too — either while
it was happening or after the fact if they have traffic logs. So if
the attack was a research project (i.e. not intentionally malicious),
it was deployed in an irresponsible way because it puts users at risk
indefinitely into the future.

(This concern is in addition to the general issue that it’s probably
unwise from a legal perspective for researchers to attack real users
by modifying their traffic on one end and wiretapping it on the
other. Tools like Shadow are great for testing Tor research ideas out
in the lab: http://shadow.github.io/ )

B) This protocol header signal injection attack is actually pretty neat
from a research perspective, in that it’s a bit different from previous
tagging attacks which targeted the application-level payload. Previous
tagging attacks modified the payload at the entry guard, and then
looked for a modified payload at the exit relay (which can see the
decrypted payload). Those attacks don’t work in the other direction
(from the exit relay back towards the client), because the payload
is still encrypted at the entry guard. But because this new approach
modifies (“tags”) the cell headers rather than the payload, every
relay in the path can see the tag.

C) We should remind readers that while this particular variant of
the traffic confirmation attack allows high-confidence and efficient
correlation, the general class of passive (statistical) traffic
confirmation attacks remains unsolved and would likely have worked
just fine here. So the good news is traffic confirmation attacks
aren’t new or surprising, but the bad news is that they still work. See
https://blog.torproject.org/blog/one-cell-enough for more discussion.

Then the second class of attack they used, in conjunction with their
traffic confirmation attack, was a standard Sybil attack — they
signed up around 115 fast non-exit relays, all running on 50.7.0.0/16
or 204.45.0.0/16. Together these relays summed to about 6.4% of the
Guard capacity in the network. Then, in part because of our current
guard rotation parameters:
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
these relays became entry guards for a significant chunk of users over
their five months of operation.

We actually noticed these relays when they joined the network, since
the DocTor scanner reported them:
https://lists.torproject.org/pipermail/tor-consensus-health/2014-January/004134.html
https://gitweb.torproject.org/doctor.git
We considered the set of new relays at the time, and made a decision
that it wasn’t that large a fraction of the network. It’s clear there’s
room for improvement in terms of how to let the Tor network grow while
also ensuring we maintain social connections with the operators of all
large groups of relays. (In general having a widely diverse set of relay
locations and relay operators, yet not allowing any bad relays in,
seems like a hard problem; on the other hand our detection scripts did
notice them in this case, so there’s hope for a better solution here.)

In response, we’ve taken the following short-term steps:

1) Removed the attacking relays from the network.
2) Put out a software update for relays to prevent “relay early” cells
from being used this way.
3) Put out a software update that will (once enough clients have
upgraded) let us tell clients to move to using one entry guard
rather than three, to reduce exposure to relays over time.
4) Clients can tell whether they’ve received a relay or relay-cell.
For expert users, the new Tor version warns you in your logs if
a relay on your path injects any relay-early cells: look for the
phrase “Received an inbound RELAY_EARLY cell”.

The following longer-term research areas remain:

5) Further growing the Tor network and diversity of relay operators,
which will reduce the impact from an adversary of a given size.
6) Exploring better mechanisms, e.g. social connections, to limit the
impact from a malicious set of relays. We’ve also formed a group to
pay more attention to suspicious relays in the network:
https://blog.torproject.org/blog/how-report-bad-relays
7) Further reducing exposure to guards over time, perhaps by extending
the guard rotation lifetime:
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
8) Better understanding statistical traffic correlation attacks and
whether padding or other approaches can mitigate them.
9) Improving the hidden service design, including making it harder
for relays serving as hidden service directory points to learn what
hidden service address they’re handling:
https://blog.torproject.org/blog/hidden-services-need-some-love

OPEN QUESTIONS:
Q1) Was this the Black Hat 2014 talk that got canceled recently?
Q2) Did we find all the malicious relays?
Q3) Did the malicious relays inject the signal at any points besides
the HSDir position?
Q4) What data did the attackers keep, and are they going to destroy it?
How have they protected the data (if any) while storing it?

Great questions. We spent several months trying to extract information
from the researchers who were going to give the Black Hat talk, and
eventually we did get some hints from them about how “relay early”
cells could be used for traffic confirmation attacks, which is how
we started looking for the attacks in the wild. They haven’t answered
our emails lately, so we don’t know for sure, but it seems likely that
the answer to Q1 is “yes”. In fact, we hope they *were* the ones doing
the attacks, since otherwise it means somebody else was. We don’t yet
know the answers to Q2, Q3, or Q4.


The Green Machine is a big scamming website

30 July, 2014 at 12:09 am by anonymous!

It has come to our attention that the Tor hidden service “The Green Machine”, which is administered by the “Fungi”, is in fact a “big scamming website”.

You’ve been warned – like we warned about Sheep Market Place, MtGox and numerous other scams before they were exposed as such – but nobody ever listens.


livelyblog.com | Random blog | Login | Get your own blog | ^^^
anonymous.livelyblog.com/Login