Having a solid grasp of tcpdump is mandatory for anyone desiring a thorough understanding of TCP/IP.
Let there be no mistake about this: from a technical point of view, 5G Network Slicing is totally awesome!
However, some aspects seems to disagree with Network Neutrality principles.
The research paper by P1 Security was presented last week in a security conference in France
A team of researchers from security firm P1 Security has detailed a list of flaws in the VoLTE protocol that allows an attacker to spoof anyone’s phone number and place phone calls under new identities, and extract IMSI and geo-location data from pre-call message exchanges.
These issues can be exploited by both altering some VoLTE packets and actively interacting with targets, but also by passively listening to VoLTE traffic on an Android device.
Voice over LTE (VoLTE)
VoLTE is a standard for high-speed wireless communication for mobile phones and data terminals, based on the IP Multimedia Subsystem network.
With VoLTE the voice service being delivered as data flows within the LTE data bearer, without dependency on the legacy circuit-switched voice network to be maintained.
Researchers divide vulnerabilities into “active”, that require modifying special SIP packets, and “passive” that expose data via passive network monitoring or do not require any SIP packet modification.
Below a brief list of the flaws discovered (for extended information please refers to links in ‘Reference’ section, at the end of the post):
SIP INVITE messages are exchanged when phone calls via VoLTE are initiated and passes through all the mobile networking equipment that supports the call: an attacker on the same network can send modified SIP INVITE messages to brute-force the mobile provider and get a list of all users on its network.
Free data channel over SDP
This flaw allows a VoLTE customer to exchange data (phone calls, SMS, mobile data) via VoLTE networks without initiating the CDR module, responsible for billing.
P1 team discovers a method that using SIP and SDP messages to create unmonitored data tunnels in VoLTE networks: it allows possible crime suspects a way to create covert data communications channels.
User identity spoofing
Mobile networking equipment does not verify if the SIP INVITE header information is correct, taking the caller’s identity at face value, so an attacker can modify certain headers in SIP INVITE messages and place calls using another user’s MSISDN (phone number).
VoLTE equipment fingerprinting and topology discovery
This vulnerability allows an attacker to fingerprint network equipment of a target operator just by listening to VoLTE telephony traffic reaching an Android smartphone.
Leak of the victim’s IMEI
Watching VoLTE traffic on an Android that’s initiating a call, researchers discovered that intermediary messages exchanged before establishing a connection reveal information about the caller IMEI number.
Leak of the victim’s personal information
Similarly to the attack above, researchers also discovered that the same SIP messages can also leak more detailed information about victims: attackers could initiate shadow calls, detect the victim’s approximate location, and hang up before the phone call is established.
Did you know that in 2009 it was announced that the ifconfig Linux command would be deprecated?
Let’s try to summarize them:
Show network devices
ip addr show
ip link show
Enable a network interface
ifconfig eth0 up
ip link set eth0 up
A network interface can be disabled with:
ifconfig eth0 down
ip link set eth0 down
Setting IP address
The simple version:
ifconfig eth0 192.168.0.77
ip address add 192.168.0.77 dev eth0
The complete version with network mask or the broadcast address:
ifconfig eth0 192.168.0.77 netmask 255.255.255.0 broadcast 192.168.0.255
ip addr add 192.168.0.77/24 broadcast 192.168.0.255 dev eth0
Delete an IP address
This feature is available only with ip:
ip addr del 192.168.0.77/24 dev eth0
Add alias interface
ifconfig eth0:1 10.0.0.1/8
ip addr add 10.0.0.1/8 dev eth0 label eth0:1
Add an entry in the ARP table.
arp -i eth0 -s 192.168.0.1 00:11:22:33:44:55
ip neigh add 192.168.0.1 lladdr 00:11:22:33:44:55 nud permanent dev eth0
Set ARP resolution off on one device
ifconfig -arp eth0
ip link set dev eth0 arp off
Show the routing table
ip route show
With ip you can query on which interface a packet to a given IP address would be routed to:
ip route get 192.168.88.77
Changing the routing table
Add a route:
route add -net 192.168.3.0/24 dev eth3
ip route add 192.168.3.0/24 dev eth3
Removing entries from a routing table:
route del -net 192.168.3.0/24 dev eth3
ip route del 192.168.3.0/24 dev eth3
Add a gateway:
route add -net 192.168.4.0/24 gw 192.168.4.1
ip route add 192.168.4.0/24 via 192.168.4.1
A most complete list of deprecated commands and them replacement is available on this post of Doug Vitale:
BGP Hijacking is an actual problem that we need to solve
About BGP Hijacking i have already written something about, you can read on https://www.andreafortuna.org/bgp-hijacking-current-state-and-future-developments-d4077c215d12.
Essentially, BGP Hijacking is the illegitimate takeover of groups of IP addresses by corrupting Internet routing tables:
The Internet is a network of networks.
Each “Autonomous system” (AS) connects to the internet using a router that “speaks” the Border Gateway Protocol (BGP) to disseminate and receive routing information.
The problem is that there is no authoritative way to figure out who is supposed to receive which IP address space.
If I got a new IP address range assigned, or if I agree to route it as part of an agreement with another network, then I will use BGP to advertise this to the Internet.
Sadly, nobody has figured out yet how to validate these advertisements. As a result, it is somewhat common for BGP abused to advertise IP addresses that an organization doesn’t actually own. This can lead to a denial of service, or miscreants can start using it for a man-in-the-middle attack.
The article also refers to the recent event of BGP abuse that has allowed the hijack of a large chunks of network traffic belonging to MasterCard, Visa, and more than two dozen other financial services companies that were briefly routed through a Russian government-controlled telecom:
“I would classify this as quite suspicious,” Doug Madory, director of Internet analysis at network management firm Dyn, told Ars. “Typically accidental leaks appear more voluminous and indiscriminate. This would appear to be targeted to financial institutions. A typical cause of these errors [is] in some sort of internal traffic engineering, but it would seem strange that someone would limit their traffic engineering to mostly financial networks.”
Ullrich also suggest some mitigations for this kind of attacks:
So in short, what can you do about it?
1 — The internet is an untrusted network. Deal with it. Assume people are rerouting, eavesdropping and manipulating your traffic. Technologies like TLS will help you detect these issues if properly implemented. VPNs can help to secure trusted connections within an organization or between trusted partners. But this is exactly why you have to audit these configurations and make sure they are configured based on current best practices.
2 — Monitor if someone is trying to hijack IP address space you are using.
3 — If you do own IP address space, and if you do manage BGP yourself, then make sure you implement the few security features that are available.
For more information, please refers to original article on SANS Forum:
More references about BPJ Hijacking