16.8 C
Saturday, September 23, 2017
Home Tags BGP

Tag: BGP

Routers should know their place One of the most persistent bugs in Internet infrastructure, route leaks in the border gateway protocol (BGP), is in the sights of a group of 'net boffins and their with a new Internet-Draft.…
Visa, MasterCard, and Symantec among dozens affected by "suspicious" BGP mishap.
Boffins say BGP is a threat to the crypto-currency Attacks on Bitcoin just keep coming: ETH Zurich boffins have worked with Aviv Zohar of The Hebrew University in Israel to show off how to attack the crypto-currency via the Internet's routing infrastructure.…
New service puts logic closer to users, aims to be "global load balancer" for apps.
2017-01 Security Bulletin: Junos: Denial of Service vulnerability in RPD (CVE-2017-2302)Product Affected:This issue can affect any product or platform running Junos OS. Problem: On Junos OS devices where the BGP add-path feature is enabled with 'send' ...
One billion-plus accounts stolen in one online heist.

The U.S. presidential election messed with by another country.

Corporate secrets stolen and released on the internet on a regular basis. More and more data held hostage by ransomware.
Stock markets routinely manipulated by hackers.

Denial-of-service attacks whacking websites all over the place. Will computer security ever get better? Or is this the way things are and we simply have to live with it? For a long time I’ve speculated that it would take a tipping-point event for the world to stop treating the horrible current state of security as business as usual.
It would take a major shutdown of most of the internet or the major stock exchanges for a day or longer. Nothing else would be shocking enough.

Everything else is business as usual. But maybe a global catastrophic event would not be enough. Maybe what we have now is what we have for the foreseeable future.
I’ve long worried that this might be the case, but I haven’t wanted to admit it as realistic possibility. The past is prologue People and things change, but not so much.

The best indicator of future behavior is past behavior. Most real change is slow and nonlinear, and it happens unexpectedly.
I’ve been expecting computer security to get significantly better for three decades now.
It’s only gotten worse.
Sure, we’ve made progress in a few places, and we’re even arresting more big hackers.

But for the most part the overall risk of something malicious happening is the same or higher than before. Nobody has a plan The biggest evidence that we aren’t going to have a significantly more secure internet soon is that exactly zero big initiatives are moving forward that could help.
It seems the era of doing big things to the internet’s underlying infrastructure is dead. We are still relying on insecure protocols (Border Gateway Protocol, DNS, UDP) for most of the behind-the-scenes plumbing. More secure versions have been tried for decades and still the internet resists.

Things that could make the internet significantly safer aren’t going to be a reality anytime soon. Acceptable risk As bad as the risk is—essentially, kids and professional hackers can shut down big parts of the internet or steal anything they want at will—the world has responded through its inaction.

This risk is acceptable compared to the cost of better securing the internet. This reminds me of a story Bruce Schneier wrote a while back. He said computer security professionals are mistaken if they think users don’t understand the risk of poor passwords. We professionals confuse the risk incurred by poor passwords (such as exposing a company’s most cherished intellectual property) with the risk to the user who chooses poor passwords (basically, none). Whose fault is it anyway? Do any of us know of a single person who was punished, much less fired, for using poor passwords? I don’t.
I’m sure it happens.
I’m sure someone used a “123456” password that led to malicious hacking and was held accountable for that stupidity.
I mean, companies lose hundreds of millions of dollars due to internet theft every year. Occasionally, someone must get punished for it besides the odd CIO. On the other hand, maybe it’s like the U.S. financial system, where blatant fraud and untenable risk decisions led to more than $1 trillion in capital going up in smoke, without a single person being successfully prosecuted (except for this guy). Even after the huge financial crisis, from which the world is still recovering, relatively weak regulations were put in place to stop it from happening again.
In the United States, those regulations (Dodd-Frank) are likely to be undone by the next Congress.

This shouldn’t surprise anyone: No one in government was fired for undermining regulations prior to the meltdown, which made the whole mess almost inevitable. The point is that the huge theoretical risk of bad internet security is acceptable to almost everyone … until it’s not.

Even if the worst happens, it’s unlikely anyone will actually get in trouble, much less fired.
If you think of risk management that way—the real way every human being measures it—then what we have is good enough. I don’t like this idea at all.

But I need to stop living in a dream world where everyone suddenly realizes how bad internet security is and actually demands something better.

The fact is, we could make the internet significantly more secure today for relatively low cost and most users would support it.

But lack of accountability means it’s not going to happen.
Apply best routing practices liberally. Repeat each morning Solve the DDoS problem? No problem. We’ll just get ISPs to rewrite the internet.
In this interview Ian Levy, technical director of GCHQ’s National Cyber Security Centre, says it’s up to ISPs to rewrite internet standards and stamp out DDoS attacks coming from the UK.
In particular, they should change the Border Gateway Protocol, which lies at the heart of the routing system, he suggests. He’s right about BGP.
It sucks.

ENISA calls it the “Achilles’ heel of the Internet”.
In an ideal world, it should be rewritten.
In the real one, it’s a bit more difficult. Apart from the ghastly idea of having the government’s surveillance agency helping to rewrite the Internet’s routing layer, it’s also like trying to rebuild a cruise ship from the inside out. Just because the ship was built a while ago and none of the cabin doors shut properly doesn’t mean that you can just dismantle the thing and start again.
It’s a massive ship and it’s at sea and there are people living in it. In any case, ISPs already have standards to help stop at least one category of DDoS, and it’s been around for the last 16 years.

All they have to do is implement it. Reflecting on the problem Although there are many subcategories, we can break down DDoS attacks into two broad types.

The first is a direct attack, where devices flood a target with traffic directly. The second is a reflected attack. Here, the attacker impersonates a target by sending packets to another device that look like they’re coming from the target’s address.

The device then tries to contact the target, participating in a DDoS attack that knocks it out. The attacker fools the device by spoofing the source of the IP packet, replacing their IP address in the packet header’s source IP entry with the target’s address.
It’s like sending a letter in someone else’s name.

The key here is amplification: depending on the type of traffic sent, the response sent to the target can be an order of magnitude greater. ISPs can prevent this by validating source addresses and using anti-spoofing filters that stop packets with incorrect source IP addresses from entering or leaving the network, explains the Mutually Agreed Norms for Routing Security (MANRS).

This is a manifesto produced by a collection of network operators who want to make the routing layer more secure by promoting best practices for service providers. Return to sender One way to do this is with an existing standard from 2000 called BCP 38. When implemented in network edge equipment, it checks to see whether incoming packets contain a source IP address that’s approved and linked to a customer (eg, within the appropriate block of IPs).
If it isn’t, it drops the packet.

Corero COO & CTO Dave Larson adds, “If you are not following BCP 38 in your environment, you should be.
If all operators implemented this simple best practice, reflection and amplification DDoS attacks would be drastically reduced.” There are other things that ISPs can do to choke off these attacks, such as response rate limiting.

Authoritative DNS servers are often used as the unwitting dupe in reflection attacks because they send more traffic to the target than the attacker sends to them.

Their operators can limit the number of responses using a mechanism included by default in the BIND DNS server software, for example, which can detect patterns in incoming traffic and limit the responses to avoid flooding a target. The Internet of Pings We’d better sort this out, because the stakes are rising.

Thanks to the Internet of Things, we’re seeing attackers forklift large numbers of dumb devices such as IP cameras and DVRs, pointing them at whatever targets they want. Welcome to the Internet of Pings. We’re at the point where some jerk can bring down the Internet using an army of angry toasters.

Because of the vast range of IP addresses, it also makes things more difficult for ISPs to detect and solve the problem. We saw this with the attack on Dyn in late October, which could well be the largest attack ever at this point, hitting the DNS provider with pings from tens of millions of IP addresses.

Those claiming responsibility said that it was a dry run. Bruce Schneier had already reported someone rattling the Internet’s biggest doors. “What can we do about this?” he asked. “Nothing, really.” Well, we can do something. We can implore our ISPs to pull their collective fingers out and start implementing some preventative technology. We can also encourage IoT manufacturers to impose better security in IoT equipment. Let’s get to proper code signing later, and start with just avoiding the use of default login credentials first. When a crummy malware strain like Mirai takes down half the web using nothing but a pre-baked list of usernames and passwords, you know something’s wrong. How do we persuade IoT vendors to do better? Perhaps some government regulation is appropriate.
Indeed, organizations are already exploring this on both sides of the pond. Unfortunately, politicians move like molasses, while DDoS packets move at the speed of light.
In the meantime, it’s going to be up to the gatekeepers to solve the problem voluntarily. ® Sponsored: Want to know more about PAM? Visit The Register's hub
Updated OpenStack Networking packages that resolve various issues are nowavailable for Red Hat OpenStack Platform 9.0 (Mitaka) for RHEL 7. Red Hat OpenStack Platform provides the facilities for building a privateor public infrastructure-as-a-service (IaaS) cloud running on commonlyavailable physical hardware.

This advisory includes packages for:* OpenStack Networking serviceOpenStack Networking (neutron) is a virtual network service for OpenStack.Just as OpenStack Compute (nova) provides an API to dynamically request andconfigure virtual servers, OpenStack Networking provides an API todynamically request and configure virtual networks.

These networks connect'interfaces' from other OpenStack services (e.g. virtual NICs from ComputeVMs).

The OpenStack Networking API supports extensions to provide advancednetwork capabilities (e.g. QoS, ACLs, network monitoring, etc.)This update addresses the following issue:* Prior to this update, the `Fail` mode on OVS physical bridges was not set,defaulting to `standalone`. However, this meant that when `ofctl_interface` wasset to `native`, and the interface became unavailable (due to heavy load, OVSagent shutdown, network disruption), the flows on physical bridges could becleared.Consequently, the physical bridge traffic was disrupted. With this update, theOVS physical bridge fail mode has been set to `secure`.

As a result, flows areretained on physical bridges. (BZ#1372369) Red Hat OpenStack 9.0 for RHEL 7 SRPMS: openstack-neutron-8.1.2-5.el7ost.src.rpm     MD5: 7a03c92f63add23df2c93848bd867bf6SHA-256: 347f26f914b4cd65acf26cbf098fb396ecca112d560e4ee90eaaab30f2fe75e2   x86_64: openstack-neutron-8.1.2-5.el7ost.noarch.rpm     MD5: 95e7f37a1a06262772a06fe268b26159SHA-256: 2eff67fd7218933cf832f835520b3555560222524d8c004c8ebacfc286d00c19 openstack-neutron-bgp-dragent-8.1.2-5.el7ost.noarch.rpm     MD5: f6067ed0ccf4fb6bdd05ab454649ccdbSHA-256: c481d4143b709d92341ad9b15542216552194ce947cc0e0388cb848744722c1b openstack-neutron-common-8.1.2-5.el7ost.noarch.rpm     MD5: 58ae59f4c3c526aa81c73da5f5a052aaSHA-256: 840169960f1b4522808281310591e4c6fe9db0464e08d1a9182b8fceb0ef0449 openstack-neutron-linuxbridge-8.1.2-5.el7ost.noarch.rpm     MD5: efd957cc875e087be43787ede19d17a2SHA-256: f107a94c4fc427add3a74ce3201e41c8b9f059b648ff99519578405d158afab8 openstack-neutron-macvtap-agent-8.1.2-5.el7ost.noarch.rpm     MD5: 8a486748edf094b20fb42e531dd8fdbbSHA-256: b4b1987a4524831daec072012e5aa07216b974e90bcbcb40173cabbabbbcf31e openstack-neutron-metering-agent-8.1.2-5.el7ost.noarch.rpm     MD5: 1a6e0366baede5d288c5c643317b2d58SHA-256: d47afe271058d0a26cf855f3c42ebf07655229ccf65474ec0ec8eff165308164 openstack-neutron-ml2-8.1.2-5.el7ost.noarch.rpm     MD5: fecbc48e87e1bc17e35a7b90cd5e1883SHA-256: afc5bb9e9873ade54a8d64570274b555a7aef82e33685c3ace58c542a69e34c1 openstack-neutron-openvswitch-8.1.2-5.el7ost.noarch.rpm     MD5: abd888cb525f7897e066bfb28c5894c1SHA-256: e00c76b3529af3c10d88837a4eabecee12200c964f8feae0ffe9fc8c3793aed2 openstack-neutron-rpc-server-8.1.2-5.el7ost.noarch.rpm     MD5: 92b91e2db156e0175faec5ab6c9e0e8eSHA-256: 2f8aee9eb22508c7094ba458b2626977d9db2834109c0ee08a735b8540afc81d openstack-neutron-sriov-nic-agent-8.1.2-5.el7ost.noarch.rpm     MD5: dad81ca432db814ff64177c3205bdd8bSHA-256: 975e0aaf9facad18d6c0bd37fb90ae0c5dbdbeef48354fc3934fec554a9a18c8 python-neutron-8.1.2-5.el7ost.noarch.rpm     MD5: d2662f8cf02662aeac46f9b9b121ed21SHA-256: c007949167a77df8d4e2f65fb65fbc33e318bd342cd219dc661f063c2fac6c2d python-neutron-tests-8.1.2-5.el7ost.noarch.rpm     MD5: 932a0579bae6f1c0e4865b981bb55e58SHA-256: a010c716e8a70e1b843748a6c4c41339f42581633312b6df8a3de0e828338b97   (The unlinked packages above are only available from the Red Hat Network) 1372369 - Backport to mitaka: Set secure fail mode for physical bridges These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from:
Updated OpenStack Networking packages that resolve various issues are nowavailable for Red Hat OpenStack Platform 9.0 (Mitaka) for RHEL 7. Red Hat OpenStack Platform provides the facilities for building a privateor public infrastructure-as-a-service (IaaS) cloud running on commonlyavailable physical hardware.

This advisory includes packages for:* OpenStack Networking serviceOpenStack Networking (neutron) is a virtual network service for OpenStack.Just as OpenStack Compute (nova) provides an API to dynamically request andconfigure virtual servers, OpenStack Networking provides an API todynamically request and configure virtual networks.

These networks connect'interfaces' from other OpenStack services (e.g. virtual NICs from ComputeVMs).

The OpenStack Networking API supports extensions to provide advancednetwork capabilities (e.g. QoS, ACLs, network monitoring, etc.)Changes to the openstack-neutron component:* Previously, all controllers restarted at the same time, causing all AMQP(RabbitMQ) servers to also restart; this caused the connection between neutronagents and the AMQP servers to seem to hang until timed-out, while the time-outamount was linear (60 seconds, then 120, then 240, and so on (limited at 600)).Consequently, an agent was considered `down` (not receive any events) until thetimeout expired. With this update, the time-out mechanism in the specific eventthat tries to connect between the agents and the neutron-server has been changedto always be 60 seconds.

As a result, if the connection hangs because of arestart of all the controllers, the agents will recover quicker (~60 secondsafter the controllers fully start again). (BZ#1359894) Red Hat OpenStack 9.0 for RHEL 7 SRPMS: openstack-neutron-8.1.2-4.el7ost.src.rpm     MD5: ed8f7c0ff5a626262768d276ffd09a62SHA-256: c9d49b497819324eb721939151d91abe54ac82c5c91d8fbe18cdcf6fdd8d1758   x86_64: openstack-neutron-8.1.2-4.el7ost.noarch.rpm     MD5: c0f569edb81efe99f2fd95ac3eab40d9SHA-256: 9651481b0b21e09d741e5079def7c07a8d1a18073aa22e3e828a53402aa94266 openstack-neutron-bgp-dragent-8.1.2-4.el7ost.noarch.rpm     MD5: 60065a2d458acb80b171e48ca488cb4dSHA-256: bb29919c717553c76394ded9f648f84b9ae1293a5b5c202a46659a8322c4e10a openstack-neutron-common-8.1.2-4.el7ost.noarch.rpm     MD5: 3c59c028f833ebdd7f0dffc6f1aeb28bSHA-256: b5ffa796d97d1f1fb90381ab262186fca16689a064dfb822f259187ff444e346 openstack-neutron-linuxbridge-8.1.2-4.el7ost.noarch.rpm     MD5: e0c7a1bc0b3bffd453204d9177e7d81aSHA-256: 836fdecae031f26759c305ab578d5f46317e6c1b59f627b18be69bf824c28d5f openstack-neutron-macvtap-agent-8.1.2-4.el7ost.noarch.rpm     MD5: e9f2ac44863b7ff05aead7c776a716c8SHA-256: f81037fc7bb316f4e003988349e738c23c57424263f10a0daa07d46801f9dc0d openstack-neutron-metering-agent-8.1.2-4.el7ost.noarch.rpm     MD5: 4f4ab35e81a86f99ddceeb2ddc251c4dSHA-256: e3e68b3276027fa256fed7ece96ef136de140164cc436deb8d6eafe25e5f579f openstack-neutron-ml2-8.1.2-4.el7ost.noarch.rpm     MD5: 6bc45c86d7fa14044c8c1e0426dddaa7SHA-256: ab6e5f100a1cbf70d685d1190de4d6572b0cfb24b66120f8a722283cdc3e9512 openstack-neutron-openvswitch-8.1.2-4.el7ost.noarch.rpm     MD5: 790ee5538dc725dc201ed8e09aa8295bSHA-256: 7b2a33b92cf2790946757bd50ed2942197fb18b52c3cd45a57c85a6bc84fc26b openstack-neutron-rpc-server-8.1.2-4.el7ost.noarch.rpm     MD5: 45e23d8561827fa45e385a524154ea29SHA-256: 361aec16c8f76c6afcdb5f46dad2a6b2629c8e260baeb3acc76089bc649910ff openstack-neutron-sriov-nic-agent-8.1.2-4.el7ost.noarch.rpm     MD5: 5a29afbe63b65ebd5ac3acc14e9bcd34SHA-256: baa9e082e7a51e2330a4fa0cb6870e730c196efef5f8aef84637e537e1603945 python-neutron-8.1.2-4.el7ost.noarch.rpm     MD5: ef24dda1a29020a7adb0ee2ada3839dcSHA-256: a6463fd536f9f11605a80c56f7bd8bee6515286469356cb3067a7b58c3efb7f4 python-neutron-tests-8.1.2-4.el7ost.noarch.rpm     MD5: 871d3fa1a8335388d5fc64891d8fcea8SHA-256: dbbc1ba16b312c644b385fce7c908deca03f1cb33e57174f7b9d991756e0a8b5   (The unlinked packages above are only available from the Red Hat Network) 1353188 - ssh is not working from undercloud to created VM because of different MTU values1359894 - openvswitch agents are being reported as down for 10 minutes after all reset controllers come back online1365617 - Calculate MTU on every network fetch instead of on create1365622 - ovs: set device MTU after it's moved into a namespace1366187 - ovsdb native interface may get stuck These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from:
 Download PDF Introduction The telecommunications industry keeps the world connected.

Telecoms providers build, operate and manage the complex network infrastructures used for voice and data transmission – and they communicate and store vast amounts of sensitive data.

This makes them a top target for cyber-attack. According to PwC’s Global State of Information Security, 2016, IT security incidents in the telecoms sector increased 45% in 2015 compared to the year before.

Telecoms providers need to arm themselves against this growing risk. In this intelligence report, we cover the main IT security threats facing the telecommunications industry and illustrate these with recent examples. Our insight draws on a range of sources.

These include: The latest telecoms security research by Kaspersky Lab experts. Kaspersky Lab monitoring systems, such as the cloud antivirus platform, Kaspersky Security Network (KSN), our botnet tracking system and multiple other internal systems including those used to detect and track sophisticated targeted (advanced persistent threat, APT) attacks and the corresponding malware. Underground forums and communities. Centralized, specialized security monitoring systems (such as Shodan). Threat bulletins and attack reports. Newsfeed aggregation and analysis tools. Threat intelligence is now a vital weapon in the fight against cyber-attack. We hope this report will help telecoms providers to better understand the cyber-risk landscape so that they can develop their security strategies accordingly. We can provide more detailed sector and company-specific intelligence on these and other threats.

For more information on our Threat Intelligence Reporting services please email intelligence@kaspersky.com. Executive summary Telecommunications providers are under fire from two sides: they face direct attacks from cybercriminals intent on breaching their organization and network operations, and indirect attacks from those in pursuit of their subscribers.

The top threats currently targeting each of these frontlines feature many classic attack vectors, but with a new twist in terms of complexity or scale that place new demands on telecoms companies. These threats include: Distributed Denial of Service (DDoS) attacks. DDoS attacks continue to increase in power and scale and, according to the 2016 Data Breach Investigations Report, the telecommunications sector is hit harder than any other. Kaspersky Lab’s research reveals that in Q2, 2016, the longest DDoS attack lasted for 291 hours (or 12.1 days) – significantly longer than the previous quarter’s maximum (8.2 days), with vulnerable IoT devices increasingly used in botnets.

Direct DDoS attacks can reduce network capacity, degrade performance, increase traffic exchange costs, disrupt service availability and even bring down Internet access if ISPs are hit.

They can be a cover for a deeper, more damaging secondary attack, or a route into a key enterprise subscriber or large-scale ransomeware attack. The exploitation of vulnerabilities in network and consumer devices. Our intelligence shows that vulnerabilities in network devices, consumer or business femtocells, USBs and routers, as well as root exploits for Android phones, all provide new channels for attacks – involving malware and technologies that individuals, organisations and even basic antivirus solutions cannot always easily remove. Compromising subscribers with social engineering, phishing or malware.

These classic techniques remain popular and can easily be mastered by entry-level cybercriminals, although 2016 sees changes in how more sophisticated attackers conduct their campaigns.

Growing numbers of cyber-attackers now combine data sets from different sources, including open sources, to build up detailed pictures of potential targets for blackmail and social engineering purposes. Insider threat is growing.

Detailed profiles of targets are also used to recruit insiders to help perpetrate cybercrime.
Some insiders help voluntarily, others are cooerced through blackmail.
Insiders from cellular service providers are recruited mainly to provide access to data, while staff working for Internet service providers are chosen to support network mapping and man-in-the-middle attacks. Other threats facing telecommunications companies include targeted attacks; poorly configured access controls, particularly where interfaces are publicly available to any Internet user; inadequate security for 2G/3G communications; and the risk of telecoms providers being drawn into unrelated attacks that exploit telecoms resources, and suffering collateral damage as a result. Typical threats targeting telecoms Overview We can divide the main threats facing the telecommunications industry into two, interrelated, categories: Threats targeting telecommunication companies directly.

These include DDoS attacks, targeted attacks (APT campaigns), network device vulnerabilities and human-related threats like insider access, social engineering and the risk of allowing third parties to access information. Threats targeting subscribers of telecoms services – particularly the customers of cellular service providers (CSPs) and Internet service providers (ISPs).

These include malware for mobile devices, subscriber data harvesting, end-user device vulnerabilities, and more. Threats directed at telecoms companies DDoS DDoS (distributed denial of service) attacks remain a serious threat to telecoms providers around the world as attackers discover ever more ways of boosting the power and scale of attacks. Kaspersky Lab’s DDoS intelligence report for Q2, 2016 notes that websites in 70 countries were targeted with attacks.

By far the most affected country was China, with South Korea and the US also among the leaders. 70.2% of all detected attacks were launched from Linux botnets, with cybercriminals paying close attention to financial institutions working with cryptocurrency.

Another trend observed in Q2 was the use of vulnerable IoT devices in botnets to launch DDoS attacks. The telecommunications sector is particularly vulernable to DDoS attacks.

According to the 2016 Data Breach Investigations Report, the telecommunications sector was hit around twice as hard as the second placed sector (financial exchanges), with a median DDoS packet count of 4.61 million packets per second (compared to 2.4 Mpps for exchanges.) The impact of a DDoS attack should not be underestimated.

Direct attacks can reduce network capacity, degrade performance, increase traffic exchange costs, disrupt service availability and even bring down Internet access if ISPs are affected. With a growing number of connected devices and systems supporting mission-critical applications in areas such as healthcare and transport, unexpected downtime could be life threatening. Further, DDoS attacks can be a cover for a deeper, more damaging secondary attack, or a route into a key enterprise subscriber or large-scale ransomeware attack. A good example of the first is the 2015 cyber-attack on the UK telecoms company, TalkTalk.

The hack, alledgedly perpetrated by a couple of teenagers, resulted in the loss of around 1.2 million customers’ email addresses, names and phone numbers, as well as many thousands of customer dates of birth and financial information – all ideal for use in financially-motivated social engineering campaigns.

The forensic investigation revealed that the hackers had used a smokescreen DDoS attack to conceal their main activities. DDoS attacks are also evolving. 2015 saw attackers amplify the power of DDoS attacks by turning them into DrDoS (Distributed reflection Denial of Service) attacks through the use of standard network protocols like NTP, RIPv1, NetBIOS (Network Basic Input/Output System) and BGP (Border Gateway Patrol).

Another approach that is becoming more commonplace is the compromise of end-user routers via network-scanning malware and firmware vulnerabilities.

Today’s faster mobile data transfer speeds and the growing adoption of 4G are also making smartphone-based botnets more useful for implementing DDoS attacks. The worrying thing is that even inexperienced attackers can organize quite an effective DDoS campaign using such techniques. Targeted attacks The core infrastructure of a telecommunications company is a highly desirable target for cybercriminals, but gaining access is extremely difficult.

Breaking into the core requires a deep knowledge of GSM architecture, rarely seen except among the most skilled and resourced cybercriminals.
Such individuals can generally be found working for advanced, international APT groups and nation-state attackers, entities that have a powerful interest in obtaining access to the inner networks of telecommunication companies.

This is because compromised network devices are harder to detect by security systems and they offer more ways to control internal operations than can be achieved through simple server/workstation infiltration. Once inside the core infrastructure, attackers can easily intercept calls and data, and control, track and impersonate subscibers. Other APTs with telecommunications on their radar The Regin APT campaign, discovered in 2014, remains of the most sophisticated ever seen and has the ability to infiltrate GSM networks, while the Turla group, has developed the ability to hijack satellite-based Internet links as part of it’s Command & Control process, successfully obscuring its actual location. Others, such as Dark Hotel and a new cyber-espionage threat actor likely to be of Chinese origin, exploit telecoms networks in their targeted campaigns.
In these cases, the telecoms providers often suffer collateral damage even though they are not directly related to the attack.

Further details on these can be found on Kaspersky Lab’s expert Securelist blog or through a subscription to the Kaspersky APT Threat Intelligence Reporting service. Unaddressed software vulnerabilities Despite all the high profile hacks and embarrassing data leaks of the last 12 months, attackers are still breaching telecoms defenses and making off with vast quantities of valuable, personal data.
In many cases, attackers are exploiting new or under-protected vulnerabilities.

For example, in 2015, two members of the hacker group, Linker Squad gained access to Orange Spain through a company website vulnerable to a simple SQL injection, and stole 10 million items of customer and employee data. SQL injection vulnerability on Orange Spain web site The impact of service misconfiguration In many cases, the hardware used by by the telecommunications industry carries configuration interfaces that can be accessed openly via HTTP, SSH, FTP or telnet.

This means that if the firewall is not configured correctly, the hardware in question becomes an easy target for unauthorized access. The risk presented by publicly exposed GTP/GRX (GPRS Tunneling Protocol/GPRS Roaming Exchange) ports on devices provides a good example of this. As CSPs encrypt the GPRS traffic between the devices and the Serving GPRS Support Node (SGSN), it is difficult to intercept and decrypt the transferred data. However, an attacker can bypass this restriction by searching on Shodan.io for devices with open GTP ports, connecting to them and then encapsulating GTP control packets into the created tunnel. Table 1.

Top 10 countries with GTP/GRX ports exposed to Internet access
The Border Gateway Protocol (BGP) is the routing protocol used to make decisions on routing between autonomous systems.

Acceptance and propagation of routing information coming from other peers can allow an attacker to implement man-in-the-middle (MITM) attacks or cause denial of service.

Any route that is advertised by a neighboring BGP speaker is merged in the routing database and propagated to all the other BGP peers. Table 2.

Top five countries with BGP protocol exposed to Internet access
An example of such an attack took place in March 2015, when Internet traffic for 167 important British Telecom customers, including a UK defense contractor that helps to deliver the country’s nuclear warhead program, was illegally diverted to servers in Ukraine before being passed along to its final destinations. To avoid probable attacks against BGP from unauthorized remote malefactors, we recommend that companies provide network filtering, allowing only a limited number of authorized peers to connect to BGP services.

To protect against malicious re-routing and hijacking initiated through authorized autonomous systems we recommend that they monitor anomalies in BGP communications (this can be done through specialized software solutions or by subscribing to alerts from vendors providing this kind of monitoring.) Vulnerabilities in network devices Routers and other network devices are also primary targets for attacks against telecommunications companies. In September 2015, FireEye researchers revealed the router malware “SYNful knock”, a combination of leaked privilege (root) credentials and a way of replacing device firmware that targets Cisco 1841, 2811 and 3825 routers (see Cisco advisory here). Put simply, SYNful knock is a modified device firmware image with backdoor access that can replace the original operating system if the attacker has managed to obtain privileged access to the device or can physically connect to it. SYNful is not a pure software vulnerability, but a combination of leaked privileged credentials combined with a certain way of replacing device firmware.
Still, it is a dangerous way of compromising an organization’s IT infrastructure. SYNful knock backdoor sign-in credentials request Worldwide distribution of devices with the SYNful knock backdoor The latest information on the number of potentially compromised devices is available through the link https://synfulscan.shadowserver.org/stats/. A second Cisco vulnerability, CVE-2015-6389 enables attackers to access some sensitive data, such as the password file, system logs, and Cisco PCA database information, and to modify data, run internal executables and potentially make the system unstable or inaccessible.

Cisco Prime Collaboration Assurance Software releases prior to 11.0 are vulnerable.

Follow this Cisco bulletin for remediation actions. For further information on Cisco fixes for its devices see https://threatpost.com/cisco-warning-of-vulnerabilities-in-routers-data-center-platforms/115609. Juniper, another network device manufacturer has been found to carry vulnerabilities in its operating system for its NetScreen VPN appliances, enabling third-party access to network traffic.

The issue was reported by the vendor in the security advisory JSA10713 on December 18th, 2015, along with the release of the patch. It appears that the additional code with hardcoded password was planted in the source code in late 2013.

The backdoor allows any user to log in with administrator privileges using hard-coded password “<<< %s(un=’%s’) = %u”.This vulnerability has been identified as CVE-2015-7755 and is considered highly critical. Top countries where ScreenOS devices are used are the Netherlands, the United States, China, Italy and Mexico. Juniper ScreenOS-powered devices worldwide Another Juniper backdoor, CVE-2015-7756, affects ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20 and allows a third party to monitor traffic inside VPN connections due to security flaws in the Dual_EC PRNG algorithm for random number generation. To protect the organization from misconfiguration and network device vulnerabilitiy, Kaspresky Lab recommendats that companies pay close attention to vulnerabilities in the network services of telecommunication equipment, establish effective vulnerability and configuration management processes, and regularly perform security assessments, including penetration testing for different types of attackers (a remote intruder, a subscriber, a contractor, etc.). Malicious insiders Even if you consider your critical systems and devices protected and safe, it is difficult to fully control some attack vectors. People rank at the very top of this list.

Their motivations are often hard to predict and anticipate, ranging from a desire for financial gain to disaffection, coercion and simple carelessness. While insider-assisted attacks are uncommon, the impact of such attacks can be devastating as they provide a direct route to the most valuable information. Examples of insider attacks in recent years include: A rogue telecoms employee leaking 70 million prison inmate calls, many breaching client-attorney privilege. An SMS center support engineer who had intercepted messages containing OTP (One-Time Passwords) for the two-step authentication required to login to customer accounts at a popular fintech company.

The engineer was found to be freely offering his services on a popular DarkNet forum. For attackers, infiltrating the networks of ISPs and CSPs requires a certain level of experience – and it is often cheaper and easier to stroll across the perimeter with the help of a hired or blackmailed insider.

Cybercriminals generally recruit insiders through two approaches: enticing or coercing individual employees with relevant skills, or trawling around underground message boards looking for an appropriate employee or former employee. Employees of cellular service providers are in demand for fast track access to subscriber and company data or SIM card duplication/illegal reissuing, while staff working for Internet service providers are needed for network mapping and man-in-the-middle attacks. A particularly promising and successful attack vector for recruiting an insider for malicious intrusion is blackmail. Data breaches, such as the 2015 Ashley Madison leak reveal information that attackers can compare with other publically available information to track down where people work and compromise them accordingly.
Very often, these leaked databases contain corporate email addresses, including those of telecommunication companies. Further information on the emerging attack vectors based on the harvesting of Open Source Intelligence (OSINT) can be obtained using Kaspersky Lab’s customer-specific Intelligence Reporting services. Threats targeting CSP/ISP subscribers Overview Attacks targeting the customers of cloud and Internet service providers remain a key area of interest for cybercriminals. We’ve revealed a number of malware activities and attack techniques based on internal information and incidents that were caught in our scope.

As a result of analyzing this data the following main threats were identified: Obtaining subscribers’ credentials. This is growing in appeal as consumers and businesses undertake ever more activity online and particularly on mobile.

Further, security levels are often intentionally lowered on mobile devices in favor of usability, making mobile attacks even more attractive to criminals. Compromising subscribers’ devices.

The number of mobile malware infections is on the rise, as is the sophistication and functionality of the malware.

Experienced and skilled programmers are now focusing much of their attention on mobile – looking to exploit payment services as well as low-valued assets like compromised Instagram or Uber accounts, collecting every piece of data from the infected devices. Compromising small-scale telecoms cells used by consumers and businesses. Vulnerabilities in CSP-provided femtocells allow criminals to compromise the cells and even gain access to the entire cloud provider’s network. Successful Proof-Of-Concept attacks on USIM cards. Recent research shows that the cryptography of 3G/4G USIM cards is no longer unbreakable.
Successful attacks allow SIM card cloning, call spoofing and the interception of SMS. Social engineering, phishing and other ways in Social engineering and phishing remain popular activities and they continues to evolve and improve, targeting unaware or poorly aware subscribers and telecoms employees. The attackers exploit trust and naiivity.
In 2015, the TeamHans hacker group penetrated one of Canada’s biggest communications groups, Rogers, simply by repeatedly contacting IT support and impersonating mid-ranking employees, in order to build up enough personal information to gain access to the employee’s desktop.

The attack provided hackers with access to contracts with corporate customers, sensitive corporate e-mails, corporate employee IDs, documents, and more. Both social engineering and phishing approaches are worryingly successful.

The Data Breach Investigations Report 2016 found that 30% of phishing emails were opened, and that 12% clicked on the malicious attachment – with the entire process taking, on average, just 1 minute and 40 seconds. Social engineers and phishers also use multiple ways for increasing the likeness of authenticity in their attacks, enriching their data with leaked profiles, or successfully impersonating employees or contractors. Recently criminals have successfully stolen tens of thousands of euros from dozens of people across Germany after finding a way around systems that text a code to confirm transactions to online banking users.

After infecting their victims with banking malware and obtaining their phone numbers, they called the CSP’s support and, impersonating a retail shop, asked for a new SIM card to be activated, thus gaining access to OTP (One Time Passwords) or “mTan’s” used for two-factor authentication in online banking. Kaspersky Lab recommends that telecommunications providers implement notification services for financial organizations that alert them when a subscriber’s SIM card has been changed or when personal data is modified. Some CSPs have also implemented a threat exchange service to inform financial industry members when a subscriber’s phone is likely to have been infected with malware. Vulnerable kit USBs, modems and portable Wi-Fi routers remain high-risk assets for subscribers, and we continue to discover multiple vulnerabilities in their firmware and user interfaces.

These include: Vulnerabilities in web interfaces designed to help consumers configure their devices.

These can be modified to trick a user into visiting a specially crafted page. Vulnerabilities that result from insufficient authentication.

These can allow for the modification of device settings (like DNS server addresses), and the interception, sending and receiving of SMS messages, or USSD requests, by exploiting different XSS and CSRF vulnerabilities. RCE (Remote Code Execution) vulnerabilities based on different variants of embedded Linux that can enable firmware modification and even a complete remote compromise. Built-in “service” backdoor allowing no-authentication access to device settings Examples of these kind of vulnerabilities were demonstrated in research by Timur Yunusov from the SCADAStrangeLove team.

The author assessed a number of 3G/4G routers from ZTE, Huawei, Gemtek and Quanta. He has reported a number of serious vulnerabilities: Remote Code Execution from web scripts. Arbitrary device firmware modification due to insufficient consistency checks. Cross Site Request Forgert and Cross Site Scripting attacks. All these vectors can be used by an external attacker for the following scenarios: Infecting a subscriber’s computer via PowerShell code or badUSB attack. Traffic modification and interception. Subscriber account access and device settings modification. Revealing subscriber location. Using device firmware modification for APT attack persistence. Most of these issues exist due to web interface vulnerabilities (like insufficient input validation or CSRF) or modifications made by the vendor during the process of branding its devices for a specific telecommunications company. The risk of local cells Femtocells, which are essentially a personal NodeB with an IP network connection, are growing in popularity as an easy way to improve signal coverage inside buildings.
Small business customers often receive them from their CSPs. However, unlike core systems, they are not always submitted to suitably thorough security audits. Femtocell connection map Over the last year, our researchers have found a number of serious vulnerabilities in such devices that could allow an attacker to gain complete control over them.

Compromising a femtocell can lead to call interception, service abuse and even illegal access to the CSP’s internal network. At the moment, a successful attack on a femtocell requires a certain level of engineering experience, so risks remain low – but this is likely to change in the future. USIM card vulnerabilities Research presented at BlackHat USA in 2015 revealed successful attacks on USIM card security. USIMs had previously been considered unbreakable thanks to the AES-based MILENAGE algorithm used for authentication.

The reseachers conducted differential power analysis for the encryption key and secrets extraction that allowed them to clone the new generation of 3G/4G SIM cards from different manufacturers. Right byte guess peak on differential power analysis graph Conclusion Telecommunications is a critical infrastructure and needs to be protected accordingly.

The threat landscape shows that vulnerabilities exist on many levels: hardware, software and human, and that attacks can come from many directions.

Telecoms providers need to start regarding security as a process – one that encompasses threat prediction, prevention, detection, response and investigation. A comprehensive, multi-layered security solution is a key component of this, but it is not enough on its own.
It needs to be complemented by collaboration, employee education and shared intelligence. Many telecommunications companies already have agreements in place to share network capability and capacity in the case of disruption, and now is the time to start reaping the benefit of shared intelligence. Our Threat Intelligence Reporting services can provide customer-specific insight into the threats facing your organization.
If you’ve ever wondered what your business looks like to an attacker, now’s the time to find out.

Contact us at intelligence@kaspersky.com
Possible workarounds for this issue include setting a maxpath-limit value for BGP MIBs or suppressing use of BGP MIBs.Use of the following BGP MIB tables, objects, and indexes should be avoided as a workaround:cbgpRouteAggregatorAddrcbgpRouteAggregator...
Quagga bgpd with BGP peers enabled for VPNv4 contains a buffer overflow vulnerability Original Release date: 10 Mar 2016 | Last revised: 10 Mar 2016 Overview Quagga, version and earlier, contains a buffer overflow vulnerability in bgpd with...