Re: [tor-talk] Mirai Botnet Relocates To Onions

[Roger Dingledine]

On Sat, Dec 17, 2016 at 10:59:37PM -0700, Mirimir wrote:
> > "Try to shut down .onion 'domains' over Tor," he boasted, knowing that
> > nobody can.
> 
> OK. However, it's not hard to scan for connections to Tor servers. And
> you don't expect them for random devices. But maybe Mirai is setup to
> use bridges.

Yuck. The 2013 botnet operator from Ukraine apparently stopped using Tor
for controlling his bots (they were doing ad click fraud), because he
attracted way more attention signing them all up to Tor than they had
attracted before, and in the end he decided it wasn't worth it.

For a while I've been trying to figure out how to share his lesson with
other botnet operators around the world. The western journalists are alas
super excited to talk about how amazing and brilliant and insightful the
idea is to move your botnet over to Tor, and if some new botnet operator
only reads those stories, they won't get an accurate impression. :(

(Keep an eye on the user graph on the metrics page, because there's a good
chance that this story is nonsense and the graph won't change at all.)

--Roger

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Mirai Botnet Relocates To Onions

[Mirimir]

On 12/17/2016 10:11 PM, grarpamp wrote:
> https://www.bleepingcomputer.com/news/security/security-firms-almost-brought-down-massive-mirai-botnet/



> Currently, to avoid further takedown attempts from similar security
> firms, BestBuy has started moving the botnet's command and control
> servers to Tor. "It's all good now. We don't need to pay thousands to
> ISPs and hosting. All we need is one strong server," the hacker said.
> "Try to shut down .onion 'domains' over Tor," he boasted, knowing that
> nobody can.

OK. However, it's not hard to scan for connections to Tor servers. And
you don't expect them for random devices. But maybe Mirai is setup to
use bridges.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Mirai Botnet Relocates To Onions

[grarpamp]

https://www.bleepingcomputer.com/news/security/security-firms-almost-brought-down-massive-mirai-botnet/

"Following a failed takedown attempt, changes made to the Mirai
malware variant responsible for building one of today's biggest
botnets of IoT devices will make it incredibly harder for authorities
and security firms to shut it down," reports Bleeping Computer.
Level3 and others" have been very close to taking down one of the
biggest Mirai botnets around, the same one that attempted to knock the
Internet offline in Liberia, and also hijacked 900,000 routers from
German ISP Deutsche Telekom.The botnet narrowly escaped due to the
fact that its maintainer, a hacker known as BestBuy, had implemented a
domain-generation algorithm to generate random domain names where he
hosted his servers.
Currently, to avoid further takedown attempts from similar security
firms, BestBuy has started moving the botnet's command and control
servers to Tor. "It's all good now. We don't need to pay thousands to
ISPs and hosting. All we need is one strong server," the hacker said.
"Try to shut down .onion 'domains' over Tor," he boasted, knowing that
nobody can.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Intel ME / AMT + NSL vs Tor Nodes

[podmo]

> On 12/17/2016 4:08 PM, Roman Mamedov wrote:

> Confirmed technical details on this topic aren't exactly
> published on Intel's site.
>
...
> Podmo stated

Agree Intel needs to do a much better job documenting the capabilities,
but until there's a verified exploit not much point running around in
circles about it. Could always use a third party NIC instead of the
onboard one too.
(And it wasn't me, I was just quoting a followup Reddit post.)


-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Intel ME / AMT + NSL vs Tor Nodes

[Joe Btfsplk]

On 12/17/2016 4:08 PM, Roman Mamedov wrote:

On Sat, 17 Dec 2016 21:48:51 -
"podmo"  wrote:


It cannot be used to access all your data remotely. That
only works if you have all AMT features enabled, and you have a special
device called a BMC card plugged into your computer and connected to the
network.

The whole point of Intel AMT is that you CAN manage your computer remotely
without it having a separate BMC plugged in (e.g. see [1]). AMT itself is in
effect an integrated BMC by its own. After that the entire "well-written,
rational response" falls apart, the author clearly has not even a single clue
of what he's trying to talk about.

[1]
http://support.radmin.com/index.php?/Knowledgebase/Article/View/9/9/How-to-set-up-Intel-AMT-features

I'm no expert on Intel ME capabilities (by any stretch), but from the 
little I read from more "professional" sources, it does provide ability 
to remotely access computers.
Assuming they have the expertise & required data access to it. Those 
professional sources could also have some things wrong, or partly 
wrong.  Confirmed technical details on this topic aren't exactly 
published on Intel's site.


If it gets to the point where it's common knowledge to every hacker how 
to even partially misuse the ME, then Intel will have made a grave 
business decision.  At that point, they'd have to discontinue it, 
perhaps give refunds for unusable computers or issue permanent fixes - 
to close the holes.  If it becomes common knowledge & they don't take 
drastic action, they'd suffer tremendously.  That's not to say they 
might not leave a better protected opening for government agencies.


What are all the countries - businesses, governments around the world 
going to do?  Buy computers that are open books to even 1 or 2 top level 
agencies of a few key "democratic" countries, much less hackers freely 
trading (Intel ME) "Both the keys and the toolchain, as well as the 
source code," as Podmo stated?

I doubt it.
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Intel ME / AMT + NSL vs Tor Nodes

[podmo]

> https://www.reddit.com/r/onions/comments/5i6qa3/can_the_nsafbi_use_intel_me_to_defeat_tor_on_95/
>
> "
> So, The NSA and FBI CAN force Intel to give up the keys Intel ME.
[...]

There is a well-written, rational response further down in that same
Reddit thread:

"This post has a lot of misunderstandings behind it. First off, the
Intelligence Community does not need to force Intel to give up
Manageability Engine keys (or AMD's PSP keys for that matter). Both the
keys and the toolchain, as well as the source code are traded underground.
I know that at least up to firmware version 8 is traded underground, and
version 11 (the latest) is available without difficulty to people who know
how to find it. I have access to version 8's signing keys myself, being in
that scene, but all my computers use version 11 so I haven't cared to mess
with it. It's certainly not common but it is absolutely something that
FVEY and related contractors (Raytheon, Leidos, half the people you'll see
at ISS, etc) will be able to get their hands on, if they haven't already.

Second, the abilities of the Manageability Engine are greatly
over-exaggerated. It cannot be used to access all your data remotely. That
only works if you have all AMT features enabled, and you have a special
device called a BMC card plugged into your computer and connected to the
network. BMC cards can include 3G/4G or WiMax support, which is where the
myth that vPro CPUs have a 3G backdoor comes from. I have an enterprise
ThinkPad that proudly boasts having WiMax support, requiring extensive
configuration. It was expensive. If you don't have a BMC card (and you do
not), then it is not possible to remotely control your system. Even if you
did have a BMC, simply having the signing keys and toolchain for the ME
would not be sufficient to get in. An attacker would need either a 0day,
or your credentials. Having the signing key allows nothing more than
writing malicious firmware over SPI and allowing it to persist. It's just
a little more powerful than the UEFI kits cr4sh can write, and just as
easily detectable by reading your flash chip. But it's not like you're
analyzing your microcode (of which there are likely signing keys being
traded as well), which can also be installed on a large number of systems,
considering the BIOS functions to load the latest microcode it has into
the CPU.

Thirdly, you don't have to worry about the ME hiding Intel-provided
backdoors because it is not impossible to reverse engineer ME firmware.
The firmware is huffman coded, which can be decoded with some manual
effort, and then you have ARCompact bytecode with Java-based modules.
Intel can be a nasty company, but they aren't going to risk everything
with overt backdoors that simply exfiltrate your memory over the network.
Plus you could easily block that with a separate firewall. Even if it is
sent out-of-band with regards to the kernel's networking stack, it's still
sent over the same physical NIC, just with a different IP and MAC.

The ME is absolutely not what you have to worry about in these threat
models. It is only a way for malware to hide itself from forensic
analysis, not a mystical way to remotely contact any system which runs it,
absent a BMC card.

If you have to have something to worry about, worry about 0days. They are
much more dangerous and valuable than something which, at best, provides a
persistent infection that is trivial to detect offline. There are RCEs for
every major httpd. There are LPEs that even work on grsecurity (at least
one that I know of), and dozens that work on vanilla Linux. There are at
least two traded ring 0 RCEs for Windows, one of which I have, and there
are probably a couple ring 0 RCEs in Linux's Netfilter (conntrack,
anyone?). Secure your OS, use sandboxes and mandatory access controls
(SELinux or AppArmor or RBAC), keep up to date, read security mailing
lists, be wary of red herrings, use grsecurity + PaX, and most
importantly, understand your own threat model.

I can say with absolute confidence that the Intel Manageability engine is
not a threat in the least to the integrity of the Tor network. Especially
not when each and every one of you are running a browser which can be
exploited with images and CSS. Sandbox your shit."

P.S. Please double-check the facts before spreading FUD.


-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Multiple 404 ("Not found") when trying to fetch certificates for authorities

[Ivan Markin]

Dimitar Milkov:
> From some time now, i'm getting warns in the Tor log about missing
> key certificates of authorities when the client is trying to obtain
> them from directory mirrors:
> 
> WARN: Received http status code 404 ("Not found") from server
> '104.233.94.181:9001' while fetching
> "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".

Why are you sure that these are "certificates of authorities"? It seems
that this is just a fingerprint of a relay that is not in consensus
anymore and thus relays don't have the cert for it to serve over either
DirPort or begindir. But your client still has it (somehow).

> I'm using an old version of Tor (0.2.5.x) for various reasons.

This it really old. I'm curious about what are reasons behind it.
Please don't run relays on that old versions.

--
Ivan Markin
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Multiple 404 ("Not found") when trying to fetch certificates for authorities

[Dimitar Milkov]

From some time now, i'm getting warns in the Tor log about missing key 
certificates of authorities when the client is trying to obtain them from 
directory mirrors:

WARN: Received http status code 404 ("Not found") from server 
'104.233.94.181:9001' while fetching 
"/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956". 
WARN: Received http status code 404 ("Not found") from server 
'104.233.94.181:9001' while fetching 
"/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956". 
WARN: Received http status code 404 ("Not found") from server 
'104.233.94.181:9001' while fetching 
"/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".

It happens with different mirrors.

I'm using an old version of Tor (0.2.5.x) for various reasons.

Obviously, most of those directory mirrors are no longer mirrors or serve 
directory information on different port. Why the Tor client is still trying to 
obtain authority certificates from them?
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk