"Defensive" BGP hijacking?

Hello Everyone,

I would like to give as much insight as I can in regards to the BGP hijack
being discussed in this thread. I won’t be going into specific details of
the attack, but we do plan to release more information on our website when
we are able to. I also wanted to let Hugo (who started the thread) know
that we harbor no hard feelings about bringing this topic up, as it is
relevant to the community and does warrant discussion. Hugo, you may owe me
a beer the next time we meet. :slight_smile:

We agree with others that NANOG is the most appropriate venue to answer any
questions and discuss the topic at hand. I have been attending NANOG for
the past 3-4 years, and I can assure you that it is of the utmost
importance to me how the community views my company, my employees, and
myself. There are many people in this community that I personally have the
upmost respect for, and it would sadden me If I were to lose the respect of
mentors, colleagues, and friends by not responding. That being said, I
think there are a fair number of people in NANOG that would vouch for my
character and ethics relating to the intent of my actions, even if I were
to remain silent. I would also like to preface that my explanation of the
events that occurred and actions taken by BackConnect are not to justify or
provide excuses. My goal is to simply show what happened and give insight
into our actions.

I will start with a little background to bring anyone up to speed that is
not aware of the events that transpired.

*About the company, BackConnect, Inc.*: We are a new (~4 months old)
open-sourced based DDoS mitigation and network security provider that
specializes in custom intrusion detection and prevention systems. We also
provide threat intelligence services, with an emphasis on active botnets,
new and upcoming DDoS attack patterns, and boot services. From time to
time, this information flows through our network for collection purposes.

*Events leading to the Hijack*: On 9/6/2016, ~10:30AM PST, one of our
clients and our website received a large and relatively sophisticated DDoS
attack. The attack targeted entire subnets and peaked over 200 Gbps and
40Mpps. Although the attack was automatically detected and mostly filtered,
there was initially a small leak. In response we quickly applied new
security rules that rendered it entirely ineffective. The attackers
continued to attack our network and client for roughly 6 hours before
giving up.

*Events that caused us to perform the BGP hijack*: After the DDoS attacks
subsided, the attackers started to harass us by calling in using spoofed
phone numbers. Curious to what this was all about, we fielded various calls
which allowed us to ascertain who was behind the attacks by correlating
e-mails with the information they provided over the phone. Throughout the
day and late into the night, these calls and threats continued to increase
in number. Throughout these calls we noticed an increasing trend of them
bringing up personal information of myself and employees. At this point I
personally filled a police report in preparation to a possible SWATing
attempt. As they continued to harass our company, more and more red flags
indicated that I would soon be targeted. This was the point where I decided
I needed to go on the offensive to protect myself, my partner, visiting
family, and my employees. The actions proved to be extremely effective, as
all forms of harassment and threats from the attackers immediately stopped.
In addition to our main objective, we were able to collect intelligence on
the actors behind the bot net as well as identify the attack servers used
by the booter service.

*Afterthoughts*: The decision to hijack the attackers IP space was not
something I took lightly. I was fully aware there were services that
reported such actions and knew that this could potentially be brought up in
discussion and hurt BackConnect’s image. Even though we had the capacity to
hide our actions, we felt that it would be wrong to do so. I have spent a
long time reflecting on my decision and how it may negatively impact the
company and myself in some people’s eyes, but ultimately I stand by it. The
experience and feedback I have gained from these events has proven
invaluable and will be used to shape the policies surrounding the future
handling of similar situations. I am happy to field questions, but cannot
promise any answers, disclosure of further information, or when they will
be responded to.

Sincerely,

Bryant Townsend

Will you do the bgp hijacking in the future: yes or no?

Thanks!

+1 to this question.

Bryant, thanks for giving us your side of this story.

Matt Freitag
Network Engineer I
Information Technology
Michigan Technological University
(906) 487-3696 <%28906%29%20487-3696>
https://www.mtu.edu/
https://www.it.mtu.edu/

What would you have done if the personal harassment didn't stop? What would you have done if they simply switched to a new source range/different set of bots?

Seems like a very slippery slope to me.

Spencer Ryan | Senior Systems Administrator | sryan@arbor.net<mailto:sryan@arbor.net>
Arbor Networks
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com<http://www.arbornetworks.com/>

Bryant, what actions, exactly, did you take? This topic seems intentionally glossed over while you spend a much larger amount of time explaining the back story and your motivations rather than your actions.

Questions I was left with:

1. What prefixes have you announced without permission (not just this
    event)?
2. How did you identify these prefixes?
3. Did you attempt to contact the owner of these prefixes?
4. Did you attempt to contact the origin or transit AS of these prefixes?
5. What was the process to get your upstream AS to accept these prefix
    announcements?
6. Was your upstream AS complicit in allowing you to announce prefixes
    you did not have authorization to announce?

I think you're saying that the BGP hijack wasn't done in as part of an attempt to
mitigate a DDoS, rather that you used the tools you had available
to go on the offensive in response to phone calls you received. Am I reading
that right?

Cheers,
  Steve

Blake,

I concur that these are key questions. Probably _the_ key questions. The fabric of the Internet is today based on trust, and BGP's integrity is the core of that trust.

I realize that BGP hijacking is not uncommon. However, this is the first time I've seen in it used defensively. I don't see a way to ever bless this kind of defensive use without compromising that core trust. If Internet reachability depends on individual providers believing that they are justified in violating that trust when they are attacked, how can the Internet stand?

In addition to the question posed to Bryant about whether he would take this action again, I would like to add: what about the innocent parties impacted by your actions? Or do you take the position there were no innocent parties in the hijacked prefixes?

-mel via cell

Wait, so if I hijack someone else's prefix, someone ends up buying me a
beer?

Let me fire up my terminal...

If only there were a global system, with consistent and verifiable security
properties, to permit address holders to declare the set of AS's authorized
to announce their prefixes, and routers anywhere on the Internet to
independently verify the corresponding validity of received announcements.

*cough https://www.nanog.org/meetings/abstract?id=2846 cough*

I now return us to our discussion of network police, questionnaires for
network security, and the use of beer as a motivating force.

dougm

@ca & Matt - No, we do not plan to ever intentionally perform a
non-authorized BGP hijack in the future.

@Steve - Correct, the attack had already been mitigated. The decision to
hijack the attackers IP space was to deal with their threats, which if
carried through could have potentially lead to physical harm. Although the
hijack gave us a unique insight into the attackers services, it was not a
factor that influenced my decision.

@Blake & Mel - We will likely cover some of these questions in a future
blog post.

@ca & Matt - No, we do not plan to ever intentionally perform a
non-authorized BGP hijack in the future.

Great answer. Thanks.

Committing to pursuing a policy of weaponizing BGP would have triggered a
serious "terms of service" violations that would have effectively ended
your business swiftly and permanently.

Tip to the RIR policy folks, you may want to make this point very crisp. A
BGP ASN is the fundamental accountability control in a inter-domain
routing. Organizations with repeated offensense need to have their ASN
revoked, and further there should be controls in places so bad actors
cannot acquire "burner" ASNs.

@Steve - Correct, the attack had already been mitigated. The decision to

@ca & Matt - No, we do not plan to ever intentionally perform a
non-authorized BGP hijack in the future.

Great answer. Thanks.

Committing to pursuing a policy of weaponizing BGP would have triggered a
serious "terms of service" violations that would have effectively ended
your business swiftly and permanently.

Tip to the RIR policy folks, you may want to make this point very crisp. A
BGP ASN is the fundamental accountability control in a inter-domain
routing. Organizations with repeated offensense need to have their ASN
revoked, and further there should be controls in places so bad actors
cannot acquire "burner" ASNs.

@Steve - Correct, the attack had already been mitigated. The decision to
hijack the attackers IP space was to deal with their threats, which if
carried through could have potentially lead to physical harm. Although the
hijack gave us a unique insight into the attackers services, it was not a
factor that influenced my decision.

@Blake & Mel - We will likely cover some of these questions in a future
blog post.

Ca, and the community, I don't make the leap. How does attacking someone by hijacking their IP space mitigate a physical threat? How does impeding someone's access to the internet access prevent them from performing an act of physical violence against you? If a party threatens me, would I be justified in attacking him or her? In my experience, attacking someone is more likely to escalate a situation - not deescalate it.

Bryant did weaponize BGP and stated he stands by his actions and further indicated that he will use what he learned here to shape handling of future situations:

I have spent a
long time reflecting on my decision and how it may negatively impact the
company and myself in some people’s eyes, but ultimately I stand by it. The
experience and feedback I have gained from these events has proven
invaluable and will be used to shape the policies surrounding the future
handling of similar situations.

When I read Bryant's comments, I see justification and excuses for his behavior. I do not see an apology nor admission of wrongdoing. I believe what Bryant did was wrong and I would hate for others to be allowed to act similarly without consequence.

If only there were a global system, with consistent and verifiable security
properties, to permit address holders to declare the set of AS's authorized
to announce their prefixes, and routers anywhere on the Internet to
independently verify the corresponding validity of received announcements.

*cough https://www.nanog.org/meetings/abstract?id=2846 cough*

I now return us to our discussion of network police, questionnaires for
network security, and the use of beer as a motivating force.

dougm

Interesting that backconnect has invalid ROA issued

The RIRs have made it very clear that they will not get involved. Period.

-Hank

If only there were a global system, with consistent and verifiable security
properties, to permit address holders to declare the set of AS's authorized
to announce their prefixes, and routers anywhere on the Internet to
independently verify the corresponding validity of received announcements.

*cough https://www.nanog.org/meetings/abstract?id=2846 cough*

I now return us to our discussion of network police, questionnaires for
network security, and the use of beer as a motivating force.

dougm

Interesting that backconnect has invalid ROA issued

AS203959 DEMENIN B.V. - bgp.he.net

Well, no, that’s not what the bgp.he.net (live long and prosper!) icons mean.

There is nothing invalid about the ROA. And BackConnect did not issue it.

The red key means that AS203959 BackConnect Security LLC is announcing routes for 181.215.239.0/24, 191.96.128.0/24. etc that are invalid according to the RPKI. Someone else with the right to use 181.215.239.0/24, 191.96.128.0/24. etc, created ROAs authorizing some other AS(s) to originate the route.

You can look at the ROAs for those prefixes with red keys in http://rpki-browser.realmv6.org (and with the RPKIviz and EOM tools from www.securerouting.net). You can see that there are ROAs for 181.214.0.0/15 for AS50673, AS60458, AS61440. and ROAs for 191.96.0.0/16 for AS61440, AS60458, AS29073, AS33182, AS37692. and ROAs for 191.101.0.0/16 for AS60458, AS37692, AS61440.

Except.

It looks like, maybe, BackConnect was re-allocated the four prefixes with red keys, and whoever reallocated the prefixes to them created ROAs for their aggregate — but not for their customers. See for example 191.96.128.0/24 - bgp.he.net (and 191.101.191.0/24 - bgp.he.net)

This can occurred as the world backfills the existing allocations and the customers don’t keep up and their providers aren’t careful. Some RPKI implementations will warn you that the ROA you are about to create will make existing routes appear invalid to the RPKI.

Just for fun, take a look at the IRR entries for the four prefixes with red key icons:

route: 191.96.128.0/24
descr: Clan Servers
origin: AS20473
notify: net-support@ap.equinix.com
notify: noc@ap.equinix.com
mnt-by: MAINT-EQUINIXPAC
changed: mvillalobos@ap.equinix.com 20151229
source: NTTCOM

route: 191.96.129.0/24
descr: Clan Servers
origin: AS20473
notify: net-support@ap.equinix.com
notify: noc@ap.equinix.com
mnt-by: MAINT-EQUINIXPAC
changed: mvillalobos@ap.equinix.com 20151229
source: NTTCOM

route: 191.101.191.0/24
descr: Clan Servers
origin: AS20473
notify: net-support@ap.equinix.com
notify: ap-noc@ap.equinix.com
mnt-by: MAINT-EQUINIXPAC
changed: mporquez@ap.equinix.com 20151227
source: NTTCOM

route: 181.215.239.0/24
descr: Proxy route object registered by AS2764
origin: AS45177
remarks: This route object was created by AAPT on behalf of a customer.
remarks: As some of AAPTs upstream networks filter based on IRR objects,
remarks: this route object has been created to ensure that the advertisement
remarks: of this prefix is not rejected.
notify: routing.shared@aapt.com.au
mnt-by: MAINT-AS2764
changed: nobody@aapt.com.au 20160106
source: RADB

(like the “nobody” part???)

At least the aggregate announcements aren’t proxies.

route: 181.214.0.0/19
descr: Digital Energy Technologies LTD.
origin: AS61440
mnt-by: MAINT-AS61440
changed: modestas@host1plus.com 20140814 #13:04:53Z
source: RADB

route: 191.101.0.0/21
descr: Digital Energy Technologies LTD.
origin: AS25761
mnt-by: MAINT-AS61440
changed: modestas@host1plus.com 20150610 #08:53:38Z
source: RADB

—Sandy

(Since bgp.he.net changes as the routing world changes, the red keys could be gone by the time anyone looks, of course.)

So after reading your explanation of things...

Your technical protections for your client proved sufficient to handle the
attack. You took OFFENSIVE action by hijacking the IP space. By your own
statements, it was only in response to threats against your company. You
were no longer providing DDoS protection to a client. You were exacting a
vendetta against someone who was being MEAN to you. Even if that person
probably deserved it, you still cannot do what was done.

I appreciate the desire to want to protect friends and family from
anonymous threats, and also realize how ill equipped law enforcement
usually is while something like this is occurring.

However, in my view, by taking the action you did, you have shown your
company isn't ready to be operating in the security space. Being threatened
by bad actors is a nominal part of doing business in the security space.
Unfortunately you didn't handle it well, and I think that will stick to you
for a long time.

Lucy, you got some (*serious*) 'splainin to do...

http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/
http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijacks/

While I was reading the krebsonsecurity.com article cited below, the site, hosted at Akamai address 72.52.7.144, became non responsive and now appears to be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, as if blackholed (but adjacent IPs pass through to Akamai):

traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets
1 router1.sb.becknet.com (206.83.0.1) 0.771 ms 0.580 ms 0.342 ms
2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.715 ms 1.026 ms 0.744 ms
3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 9.532 ms 6.567 ms 2.912 ms
4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 2.919 ms 2.925 ms 2.904 ms
5 telia-level3-4x10g.losangeles.level3.net (4.68.70.130) 3.981 ms 3.567 ms 3.401 ms
6 sjo-b21-link.telia.net (62.115.116.40) 11.209 ms 11.140 ms 11.161 ms
7 * * *
8 * * *
9 * * *
10 * * *

Weird coincidence?

-mel beckman

earlier on Twitter Krebs said he was hit by 665Gbps attack (so says
Prolexic/Akamai). Could be ongoing/related.

Brian Krebs tweeted out that Prolexic reported a 665Gbps attack directed at
his site.

https://twitter.com/briankrebs/status/778398865619836928