back to article Crims target telcos' Linux and Solaris boxes, which don't get enough infosec love

A mysterious criminal gang is targeting telcos' Linux and Solaris boxes, because it perceives they aren't being watched by infosec teams that have focussed their efforts on securing Windows. Security vendor CrowdStrike claims it's spotted the group and that it "has been consistently targeting the telecommunications sector at a …

  1. Mike 137 Silver badge

    Surprise, surprise!

    "ensuring that "firewalls responsible for the GPRS network have rules in place to restrict network traffic to only those protocols that are expected, such as DNS or GTP""

    It's scary that this suggestion even has to be made. Why would you not? As all our comms converge on a common infrastructure, such lax security is potentially lethal.

  2. martyn.hare
    Facepalm

    Splicecom anybody?

    When pentesting small business environments I’ve yet to see anything but EOL (without ever being patched) OpenSUSE installs with VNC complete with weak passwords…. No matter what the telco system is, it’s always secured piss poorly

    1. John Robson Silver badge

      Re: Splicecom anybody?

      "No matter what the telco system is, it’s always secured piss poorly"

      Except customer services - that's guarded by the most secure vault doors ever conceived.

      1. mmlj4

        Re: Splicecom anybody?

        Agreed. I did PCI for a certain almost-top-tier USA telco, and you are right about the customer service walled garden.

  3. Deanamore

    Never worked for a telco but when dealing with core DC infrastructure it always seemed to be some sort of ancient OpenBSD system that had been running for eight years and all the engineers were too afraid to touch. Said server will almost certainly have a non-descriptive name like Saturn, nobody really knows what it does but everyone knows it's very important so shouldn't be touched. Oh and an upgrade or any sort of modification is absolutely out of the question because the last time someone tried that the whole server had to be rebuilt after tracking down the guy who built it and left the company seven years ago.

    1. Peter Gathercole Silver badge

      Many security pundits demand that the names of systems are non-descriptive, to make it more difficult for miscreants to know without investigating which systems should be attacked. And some say that having a fully populated DNS available to be queried is a bad idea as well.

      It's a small measure (and certainly not enough by itself), but it is another brick in the wall.

      Mind you, it never seems to stick, and I've seen many organizations who slip back into easily identified naming schemes.

      1. Yet Another Anonymous coward Silver badge

        In America they've gone one step further by obfuscating the names of their cities.

        Nobody is going to attack the capital if they think it's a small town in Sunderland

  4. Peter Gathercole Silver badge

    The thing that needs to be considered here is that putting a backdoor that listens to a nominated non-privileged port, and provides a stepping stone into a secure environment is not that difficult on any UNIX like box. It does not even need a privileged process to work on many out-of-the-box installs.

    The protection required here is firstly to stop the initial access to the system, which could be through a non-OS route (such as the sgsnemu process mentioned), and then for any internet connected system (or even those in the hinterland), total control of all ports not explicitly used by the required services. Other protections are to have a minimalist install of the system, removing or not installing in the first place as much software as you can, and limiting what ordinary users can access or run. Mind you, the rise of very functional scripting languages like Perl and Python, and the requirement that they be installed for the OS utilities to function makes securing systems from internal threats after the initial breach much more complicated.

    This is basic UNIX security protection, and most experienced admins. will understand this.

    Unfortunately, many experienced UNIX admins have been cast aside by organizations wanting to trim their staff costs, or have seen the writing on the wall, and have switched to newer technologies, or have simply retired.

    This leaves relative noob administrators, or people who are experts in Windows or other platforms, to pick up support, and many of these will use the hand's off management principal, because they don't understand the systems.

    1. adam 40 Silver badge

      Quite right, looking at the description here

      https://www.cybersecurity-help.cz/blog/2377.html

      none of this should even be doable on a secured UNIX system.

    2. Throatwarbler Mangrove Silver badge
      Facepalm

      IME, many "experienced Unix admins" are not as good as they think they are, and many of them have been stuck in a legacy mindset where the last decade's (or last century's) technology is good enough for them. One virtue of having Windows admins tackle Linux/Unix problems is that they are, at least, willing to do so, and will not turn their noses up at working in another environment (unlike, again IME, pure-play Unix admins, who are unwilling to sully their pristine hands with the foul taint of a foreign technology).

    3. rcxb1

      <blockquote>Other protections are to have a minimalist install of the system, removing or not installing in the first place as much software as you can,</blockquote>

      This is a Unix old wives' tale, not real security. What you should uninstall (and restrict) are programs that are SUID/SGID. A non-priv program nothing runs setting on system system is no threat to anybody.

      Only the most amateur script kiddie would be slowed down by not having their favourite shell/compiler/etc. installed. Everyone competent can easily drop-in any binaries they want.

      1. Peter Gathercole Silver badge

        @rcxb1

        If you think that I'm just talking about programs with privilege, then you don't understand either the problem, or the tools that are available on a normal UNIX like system.

        For instance, that out-of-favor tool telnet, which is installed in almost all base installs of UNIX and UNIX-like systems, can be used to probe IP addresses and ports, and is not privileged. Similarly, wget, and if they were installed, netcat (or nc), nmap, wireshark, lsof, and maybe going as far as restricting netstat, ifcconfig, arp, ip, traceroute, dig, nslookup, tcpdump and I could go on and on. UNIX and UNIX-like operating systems have a very rich set of commands for those who know how to use them.

        Like I said, if I had my way, Java, Perl and Python (and most other high function scripting languages), which pretty much allow you to write internet capable programs as scripts without needing any compilation, would be banned from these systems. They just make it too easy once you have even a non-privileged process, to create your own internet capable services, like IP and port scanners, packet forwarders, and almost anything that you could write a program in C to do.

        It used to be the case that making sure a compilation system was not installed on a system meant that it would be more difficult to use it as intrusion tool, but this has changed with high function scripting languages.

        Even basic access commands like ssh (using privately run sshd processes with crafted config files) can be subverted to act as VPN servers. I've actually built packet and session forwarders to bypass firewalls using just back-to-back or nested ssh client sessions as well, but I have to admit i needed accounts on all of the systems involved.

        Dropping binaries on a system can be made difficult. If you don't let any user write to any directory, even their home directory, have /tmp and /usr/tmp mounted with the noexec flag, and remove all the tools that allow you to receive any files, you can limit an intruder to just use what they find on a system.

        Most of the experienced UNIX admins I know already know this. If you have only come across mediocre UNIX admins, then I think you must be late to the party.

        As a contrast, I know many Windows admins who never think outside of the pretty, handheld menu systems that seem to be favored by Microsoft, and never even consider how IP and basic networks function, and never get as far as even considering what a firewall does and how it does it.

        I do know other Windows admins who are very capable, but many of them have actually learned by working outside of the Windows environment to gain the extra experience that the basic Windows courses teach.

        1. Peter Gathercole Silver badge

          @Me

          Of course, I meant that the basic Windows courses don't teach.

  5. Anonymous Coward
    Anonymous Coward

    Banking?

    Surprised they are not targeting banks as well. In the UK at least, Solaris is still a big thing.

  6. Lunatic Looking For Asylum
    Alert

    "The firm also recommends that *nix implementations in telco-land need "basic security controls and logging in place (e.g., SSH logging forwarded to a SIEM, endpoint detection and response (EDR) for process execution, file integrity monitoring (FIM) for recording file changes of key configuration files)".

    which you can buy from us of course.....

  7. Clausewitz 4.0
    Devil

    Let's not forget HP-UX

    A lot of juicy stuff in big TELCOS, up to this day, are also stored on their HP-UX.

  8. Anonymous Coward
    Anonymous Coward

    Incorrect summary of the "hack"

    > the group also knows telco kit well enough to implant the TinyShell backdoor in Serving GPRS Support Node emulator sgsnemu and use it to hop across mobile networks in search of servers to compromise.

    That part of the sentence does not make sense! The SGSN is a type of node in GPRS infrastructure. From the Cloudstrike article the LightBasin "crew" are using a SGSN emulator as a way for their TinyShell to use/abuse the mobile network (via mobile SIMs/devices they control) to tunnel traffic to the command server if this cannot be reached via normal Internet connectivity.

    So an accurate rewritten text would be:

    "the group also knows telco kit well enough to implant the TinyShell backdoor and also to emulate SGSN infrastructure (via the software "sgsnemu") so that TinyShell can hop across mobile networks to contact the C2 server whenever direct Internet connectivity to that C2 server is not possible."

    I was involved with several mobile carriers' deployments of GPRS "2.5G" back in the early 2000s so used to know the handset<->SGSN<->GGSN traffic flow inside-out.

  9. Anonymous Coward
    Anonymous Coward

    Having worked for Telcos I have seen first hand the mess the security is. Despite raising concerns time and time again, it always got swept under the carpet. I remember talking to one guy during an external audit. I went through my concerns with him. The report (when it was published later) was pretty scathing.

    Roll forward 2 YEARS and the guy gets employed by the Telco in question. He turned up at my desk with a forlorn look on his face and said "Nothing raised in that report has been implemented. If anything, its got worse!". I just grinned and welcomed him to my hell.

    Even the new network designs had such obvious security implications that anybody looking at it would say 'Hold up - you did what?' but they still got implemented because it was deemed too late to fix it.

  10. Kev99

    Telcos have millions of miles of copper carrying their telephone traffic but still use the internet to control their kit. Huh? It isn't that hard to run POTS securely. They did it for decades with dedicated lines. You know, the telephone lines Sears, Penneys, MetInsurance, Prudential and hundreds of others used for their operations until the bean counters and gee whiz children talked the C-levels to move to the 'net. And everyone knows net is just a bunch of holes held together with string.

    1. Peter Gathercole Silver badge

      @Kev99

      POTS is mostly dead.

      Most Telcos, at least in Europe, the US and Far East, have almost completely replaced copper for all than the 'last mile' in their networks. They've been running TCP/IP protocols on their fibre for quite a long time as well (it was a core requirement for BT's C21 initiative).

      It makes sense to use TCP/IP for the control network as well. At various places, it would not surprise me if they also use the Internet proper as a second route into remote installations, although I would expect that it would be protected from casual access.

      1. Snake Silver badge

        Re: TCP/IP

        "It makes sense to use TCP/IP for the control network as well."

        It makes sense from a cost and implementation perspective, but not from a security one. TCP/IP [was] quite inherently a non-secure protocol, designed for ease of sharing with no inherent security baked-in.

        Techies never want to either admit or talk about that elephant in the room. We use tunneling protocols (VPN), add-on end-point encryptions and many other methods to patch the inherent problem of IPv4. We spend an inordinate amount of time and effort, both of which equate to money, to try to fix the security controls of a protocol that has none.

        IMHO, and I've said this many times (please feel free to disagree, many people seem to!) it would be FAR, FAR better to bake the security in at communication-level, rather than at app or device-level. This should have been the killer IPv6 push but instead the industry pushed IPv6 on to the public for the idea of IoT / no-NAT connectivity...and the public didn't care.

        Actually, just the opposite: the general public almost actively opposed IPv6 because it would only make their SOHO install administration troublesome with 128-bit addresses on their Mac Minis, from their perspective a completely unnecessary headache (and they are correct). If the industry would have pushed the IPSec advantages of IPv6, I think we would be seeing a much greater acceptance.

        1. Yet Another Anonymous coward Silver badge

          Re: TCP/IP

          > TCP/IP [was] quite inherently a non-secure protocol, designed for ease of sharing with no inherent security baked-in.

          Compared to analogue voltages on bare bits of wire strung from poles through the countryside ?

          1. Snake Silver badge

            Re: TCP/IP

            "Compared to analogue voltages on bare bits of wire strung from poles through the countryside ?"

            That you need physical access to in order to compromise.

            :sigh:

            I said this before. Can you hack an internet-connected TCP/IP network from any place in the world??

            Yes, yes you CAN.

            Can you hack a plain-wire landline POTS network from any place in that world?

            Oh, that's a lot, lot, LOT harder.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021