10 ms·

The insecurity of telecom stacks in the wake of Salt Typhoon

• ofrzeta 2y ago
  From the article I am not totally convinced that "Telecom security sucks today", given they just randomly picked Freeswitch to find a buffer overflow. "Telecom stacks" might or might be not insecure but what's done here is very weak evidence. The Salt Typhoon attacks allegedly exploited a Cisco vulnerability, although the analysts suggest the attackers have been using proper credentials (https://cyberscoop.com/cisco-talos-salt-typhoon-initial-access/ https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...) So nothing to do with Freeswitch or anything.
  • posperson 2y ago
    Cisco Unified Call Manager almost certainly has vulnerabilities, as does Metaswitch which has shambled along in network cores after Microsoft publicly murdered it, Oracle SBC is often wonky just doing the basics, whatever shambling mess Teams is shipping this week for their TRouter implementation definitely has Denial of Service bugs that I can't properly isolate. Lets not even talk about the mess of MF Tandems or almost every carrier barebacking the web by slinging raw unencrypted UDP SIP traffic over the internet... It is possible to build secure systems in this space, but instead we have almost every major telecom carrier running proprietary unmodifiable platforms from long dead companies or projects (Nortel, Metaswitch,etc) and piles of technical debt that are generally worse than the horribly dated and unpatched equipment that comprises their networks.
    • tjohns 2y ago
      I find it absolutely insane that the industry standard for SIP trunks is unencrypted UDP, usually using IP-based authentication. When I asked a popular VoIP carrier about this a while back, they argued that unencrypted connections were fine because the PSTN doesn't offer any encryption and they didn't want to give their customers a false sense of security. While technically true, this doesn't mean we shouldn't at least try to implement basic security where we can - especially for traffic sent over the public Internet.
      • jvdvegt 2y ago
        PSTN starts at the home router these days, I don't think I can get an actual analog line in my house.
        • supertrope 2y ago
          My DOCSIS service provider turned off encryption. That's likely due to the certificate expiring on a popular modem brand. Key management is hard, certificate management is hard. Especially when they don't care about security. The encryption was only DES to begin with instead of AES which is supported in DOCSIS but few service providers bother. Anyone who has the tools to sniff DOCSIS can eavesdrop on my provider's nodes and hear the incoming leg of phone calls.
          • ngneer 2y ago
            Great example. Anyone who cavalierly states "let's do PKI!" has not done PKI.
    • jauntywundrkind 2y ago
      Painting a dire picture here! It'd be lovely to see some nations of the world pour some serious money into the various Linux Foundation (or other open source) telco & cellular projects.
      • surajrmal 2y ago
        Pouring money is not how you get good quality software. You need a company driving product quality. Most Linux foundation projects have companies heavily invested in productionizing the projects and that leads to them contributing to them to ensure high quality code. Code without a driving product tends to wander aimlessly.
        • jauntywundrkind 2y ago
          That's, like, your opinion man. Maybe the money should have more strings attached, be attached to grant proposals, whatever. I don't see that that is an important or clarifying distinction. Governments should be directly helping, with money, somehow. Collectivizing the investment is better returns and far better outcomes, open source is the only way you're going to avoid risking your investment in a single company that may over time fail. Having your nation take its infrastructure seriously should be obvious, and this is how. And I disagree that good things only happen at companies. The post I was responding to stands as incredibly broadscale evidence that that often doesn't happen.
          • immibis 2y ago
            Governments are often the ones the encryption is protecting us from - they're not going to fund better encryption.
          • surajrmal 2y ago
            Contract work is tricky because individuals who own a particular project may be full time employed already and not capable of taking on contract work. Not every project is capable of generating enough contract work to make it sustainable to do it full time and not everyone wants that level of instability on their income. Hiring an outside company to do contract work leads to longer term maintenance issues where they disappear after the contract completes. It would be better to have individuals from a distributed set of organizations all collectively pitch in to do maintenance. This is how the Linux project is organized and it's very successful. While this is understandably unlikely to happen for smaller projects I think that just means it's important for projects to be created and maintained by larger collectives. Again, this is a common trend you see occur.
    • heraldgeezer 2y ago
      >Cisco Unified Call Manager Is that not a kind of business/enterprise thing? "Telecom" to me is like a network core equipment and radio towers - https://www.cisco.com/c/en/us/products/wireless/pgw-packet-data-network-gateway/index.html https://www.cisco.com/c/en/us/products/wireless/pgw-packet-d...
    • foobiekr 2y ago
      Call Manager etc have zero to do with SP networks.
  • some_furry 2y ago
    I've had a few conversations with [security nerds more familiar with telecom] since SignalWire broke embargo. The "everything sucks and there's no motive to fix it" was a synopsis because, frankly, those conversations get really hard to follow if you don't know the jargon. And I didn't feel like trying to explain it poorly (since I don't understand the space that well, myself), so I left it at what I wrote. (I didn't expect Hacker News to notice my blog at all.)
    • Semaphor 2y ago
      > (I didn't expect Hacker News to notice my blog at all.) Your blog actually gets posted somewhat regularly [0]. I actually remembered it, because it’s one of the rare cases where I like the "cute" illustrations. [0]: https://hn.algolia.com/?q=https%3A%2F%2Fsoatok.blog%2F https://hn.algolia.com/?q=https%3A%2F%2Fsoatok.blog%2F
    • sunbum 2y ago
      As security nerd working within telecom agreed. Nobody really cares about security issues. And when people already struggle to care about the issues it gets even worse when fixing some of the issues (such as SS7 vulns) requires coordination with telcos around the world. cape[1] at least seems like its a breath of fresh air within the space. [1] - cape.co
      • ikiris 2y ago
        Can confirm. It’s not even nonchalance, but outright hostility to security because that sounds like work and change. And if there’s anyone who hates change, it’s telcom. They still resent having to learn voip and it could have kids in college at this point.
      • 1oooqooq 2y ago
        cape.co marketing sounds suspiciously like the cia front in Switzerland in the late 90s. "hey you who needs privacy, here's something that somehow costs even less than the ones selling your data"
      • ethagnawl 2y ago
  • cyberax 2y ago
    I worked with telecom code. It's code that parses complicated network protocols with several generations of legacy, often written in secrecy (security by obscurity), and often in C/C++. There's just no way it can be insecure. Right.
    • surajrmal 2y ago
      That's also how the majority of network appliances are handled outside of Telecom.
      • cyberax 2y ago
        Yep. And the network appliance world also tried to make that a "feature", by making things like "management VLANs" and pretending that you don't need to be secure because of it.
    • ofrzeta 2y ago
      I don't doubt that this cruft is insecure. It's just a bit of a stretch to get to that conclusion from finding a potential buffer overflow in Freeswitch. Maybe it's not a stretch but just a conclusion by analogy but then you might just say "all software is insecure".
  • amiga386 2y ago
    This blog article is a combination of "I did a thing I do for a living" plus "recipient of my report does not share my (and the rest of the Security Industry) values", and concludes that Telecom security sucks. It's very nice that the author spent their free time looking at code, found a bug and reported it -- I don't want to discourage that at all, that's great. But the fact that one maintainer of one piece of software didn't bow and scrape to the author and follow Security Industry Best Practises, is not a strong basis for opining that "Telecom security sucks today" (even if it does) If someone came to you with a bug in your code, and they didn't claim it was being actively exploited, and they didn't offer a PoC to confirm it could be exploited... why shouldn't you just treat it as a regular bug? Fix it now, and it'll be in the next release. What's that? People can see the changes? Well yes, they can see all the other changes too. Good luck to them finding an exploit, you didn't. The same thing happens in Linux distros. A security bug gets reported. Sometimes, the upstream author is literally dead, not just intransigent. If you want change on your own timeline, make your own releases.
    • tlb 2y ago
      When the code is sprintf(stackbuf, "%s", attacker_supplied_input) in 2025, I expect some serious bowing and scraping.
      • matthewdgreen 2y ago
        In fairness, with that level of vulnerability in the code, fixing it is like using paper towels to mop up the ocean.
      • camgunz 2y ago
        Yeah if anyone thinks people don't just run searches for `sprintf` they're pretty naive.
  • jeroenhd 2y ago
    Telecom stacks are full of questionable security decisions, some stemming from the protocol level. Protocols like SS7 were designed without any concept of hackers or malicious actors. You can slap firewalls on top of them, but those interfere with desired functionality and even if they don't they require extra investment. DIAMETER is better but still full of holes. Security in the telecom space has been a point of priority for the past couple of years and things are improving, but there are decades of legacy hardware, software, firmware, and network designs to cover for. I doubt anyone is running standard Freeswitch in their telco networks, but the problems Freeswitch has as an aging telecom product with a history of not looking for security as much as one might expect those are all over the place.
• xvilka 2y ago
  Time to rewrite telecom software in Rust?
  • thephyber 2y ago
    I’m guessing this is a joke. Rust only fixes the memory safety issues. It doesn’t fix bad software design, the problem where we have to trust other companies to keep their security issues under control (eg. Cisco), and it can’t undo bad decisions that have become industry standards (eg. SS7)
    • zinekeller 2y ago
      SS7, to summarize charitably, was built assuming trust exists. Some of the vulnerabilites aren't vunerabilities, they're features!
      • thephyber 2y ago
        Do you believe this statement refutes my claim that SS7 was badly designed?
        • DrillShopper 2y ago
          Yes, given the SS7 design started in the 1970s when telecommunications was either the purview of a government agency or a state granted monopoly (depending on where you were in the world. in which case it is perfectly rational to assume that your counterparties are trusted.
    • rightbyte 2y ago
      > (eg. SS7) I don't have a lock on my mailbox. It is bad that the "low trust" internet overflows into my everyday life. I would rather that there was some separation of telephone calls, local community and banking etc from the lawless voids, than normalizing all these scams. Telephone scam calls are mostly an internet problem.
      • 2y ago
• rickandmortyy 2y ago
  [dead]
• richardwhiuk 2y ago
  No major carrier is running FreeSwitch or Asterisk at the core.
  • tonetegeatinst 2y ago
    Is that a Foss or GPL compliant codebase/OS?
  • Narkov 2y ago
    This very much depends on your definition of major.
  • EvanAnderson 2y ago
    Motorola's low-end 911 phone system, Emergency CallWorks (ECW), is Asterisk with proprietary modules running on Linux under Proxmox. Granted, Motorola is killing the produce, but it's out there. The one I babysit is heavily firewalled but I'd imagine not all of them are.
    • shrubble 2y ago
      That is not the core, however; the core means the central pieces of a large telecom, the part that handles all the needed data to set up say, 10,000 or more calls per second.
      • EvanAnderson 2y ago
        For sure. The implicit trust that participants on the PSTN appear to give to each other, imparts a certain amount of undue influence to the constellation of dodgy systems interconnected to it.
  • kamma4434 2y ago
    Depends on your definition of ‘major’
    • heraldgeezer 2y ago
• dqv 2y ago
  I wonder how many people are even using the XML RPC module. It doesn't get loaded by default. Edit: 468 according to Shodan. I'm wondering if senddirectorydocument gets used at all by the XML RPC module.
  • dqv 2y ago
    Following up on this, I was unable to get it to do anything. curl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}" Any ideas on triggering it? I imagine if we get a PoC that at least causes a segfault or whatever, they will be more likely to do a security release.
    • dangerboysteve 2y ago
      I maybe wrong, but I think you need to enable the module for API access.
      • dqv 2y ago
        Yeah, it's enabled with `load mod_xml_rpc`. Listening on 8080. $ ./test3 # see above <HTML><HEAD><TITLE>Error 408</TITLE></HEAD><BODY><H1>Error 408</H1><P>Problem getting the request header</P><p><HR><b><i><a href="http://xmlrpc-c.sourceforge.net">ABYSS Web Server for XML-RPC For C/C++</a></i></b> version 1.26.0<br></p></BODY></HTML> hmmm
• asimpleusecase 2y ago
  I would dare to whisper that the lack of security suits the NSA just fine. However you can add just about every technically competent nation state, organised crime, major corporations, and a collection of non-state actors. About the only group besides us nomies who I think might really care about this are the payment rails folks as this insecurity facilitates more fraud.
• miki123211 2y ago
  One thing I absolutely don't understand about telecom security is how, in 2025, we're still using pre-shared keys in our mobile phone standards. RSA and Diffie Hellman[1] have existed for decades, so have CA systems, yet SIM cards are still provisioned with a pre-shared key that only the card and the operator knows, and all further authentication and encryption is based on that key[2]. If the operator is ever hacked and the keys are stolen, there's nothing you can do. To make things even worse, those keys have to be sent to the operator by the SIM card manufacturer (often a company based in a different country and hence subject to demands of foreign governments), so there are certainly opportunities to hack these companies and/or steal the keys in transit. To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world. [1] I'm aware that those algorithms are not considered best practices any more and that elliptic curves would be a better idea, but better RSA than what we have now. [2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-nr-4g-5g/ https://nickvsnetworking.com/hss-usim-authentication-in-lte-...
  • Narkov 2y ago
    > To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world. This feels like the obligatory XKCD comic[1] when in reality there isn't any secretive key extraction or cracking...things are just sent unencrypted from deeper into the network to the three-letter-agencies. Telco's are well known to have interconnect rooms with agencies. [1] https://xkcd.com/538/ https://xkcd.com/538/
    • bayindirh 2y ago
      > Telco's are well known to have interconnect rooms with agencies. Maybe these connections are a requirement for their permits in the first place. Who knows?
      • deleted 2y ago
• gregw2 2y ago
  Three thoughts. 1) To be slightly annoyingly contrarian, there is money to be made in secure telecom; Skype founders made a bundle, no? 2) This article conflates freeswitch with major telecom carrier infeastructure. My impression is that 30+% of the problem with security is not technical but economic. Carriers outsource a ton of their operations, effectively outsourcing most efforts to care about security... which never helps security posture unless the outsourcer considers their core value proposition, which they generally don't, instead pushing themselves as a cost/capitalization play. 3) No discussion of Matrix here as where things are headed, security-wise? https://matrix.org/blog/2024/10/29/matrix-2.0-is-here/ https://matrix.org/blog/2024/10/29/matrix-2.0-is-here/
  • svilen_dobrev 2y ago
    > Carriers outsource a ton of their operations most of them - if not all of them. This article is from 2021: https://berthub.eu/articles/posts/how-tech-loses-out/ https://berthub.eu/articles/posts/how-tech-loses-out/
    • gregw2 2y ago
      Thanks for the pointer. What a /great/ article.
  • some_furry 2y ago
    > 3) No discussion of Matrix here as where things are headed, security-wise? From the same author (that is to say, from me): https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/ https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
• lsnd-95 2y ago
  One area where freeswitch is probably used quite often (and without support contract) are BigBlueButton installations (virtual classroom system) in schools and universities. I am more worried about them then about telcos.
• 0xbadc0de5 2y ago
  The author admits to having zero experience with carrier-level infrastructure, but their suspicions are essentially correct. I actually have done a fair bit of 4G and 5G specific pentesting and security research for a number of major carriers. While it varies between carriers and between product vendors, it's still an absolute horror show. Until very recently, the security was entirely achieved through obscurity. The 4G and 5G standards have started to address this, but there are still gaps big enough to be deeply concerning. I don't think it's overly hyperbolic to assume that any moderately sophisticated threat actor who wants a beachhead on a carrier can achieve it. I've demonstrated this multiple times, professionally. IMHO the hardware vendors from a certain East Asian state have such poorly written software stacks, that they could almost be classified as APTs - security is non-existent. There are valid reasons Western countries have banned them. Western hardware vendors have significantly more mature software, but are still many years behind what most of us would consider modern security best practices.
  • matthewdgreen 2y ago
    A few years back the U.K. tried a political experiment in which it purchased Huawei equipment and also set up a special government/Huawei lab where they could analyze the source code to ensure it was safe to use. GCHQ found that the code quality made it unreviewable, and that they could not even ensure that the source code provided actually ran on the equipment (because Huawei had direct update capability.) I believe that equipment has been banned since 2020. https://www.washingtonpost.com/world/national-security/britains-spy-agency-delivers-a-scathing-assessment-of-the-security-risks-posed-by-huawei-to-the-countrys-telecom-networks/2019/03/27/ab16d7d2-50fd-11e9-8d28-f5149e5a2fda_story.html https://www.washingtonpost.com/world/national-security/brita...
    • 0xbadc0de5 2y ago
      Correct. Both the US and Canada also did similar investigations and came to similar conclusions.
      • gmueckl 2y ago
• eadmund 2y ago
  Why was FreeSWITCH written in C? Even in 2006 there were more secure alternatives. We as an industry keep poking each ourselves in our collective eye with a sharp stick, wondering why it hurts.
  • dangerboysteve 2y ago
    It's the lang devs were comfortable with and some of them came from the asterisk world.
  • ipython 2y ago
    What popular high performance memory safe system programming language existed in 2006? I get why nobody should use C for security sensitive code now, but in 2006 the options were very limited.
• traceroute66 2y ago
  To be honest, the conclusion of the blog post that Freeswitch are not budging from their community release schedule does not surpise me one iota. Freeswitch used to have a strong community spirit. Things all changed since they took a more agressive commercial turn, a couple of years ago IIRC. Since that point you now have to jump through the "register" hoop to gain access to stuff that should be open (I can't remember what it is, IIRC something like the APT repos being hidden behind a "register" wall, something like that). I don't want to "register" with a commercial company to gain access to the foss community content. Because we all know what happens in the tech world if you give your details to a commercial company, the salesdroids start pestering you for an upsell/cross-sell, you get put in mailing lists you never asked to be put on, etc.
  • BEBAA7 2y ago
    In Signalwire’s defence, reading through the old mailing list, I got the feeling they drove the development of Freeswitch for years without being properly compensated by downstream projects. Sadly I’ve also seen other parts of the Voip community recalibrate their generosity when it comes to open source and I honestly can’t blame them. The team behind Matrix.org talked about a similar problem in one of their FOSDEM’25 talks: commercial vendors free loading on development.
    • knowitnone 2y ago
      It's MPL licensed. Perhaps they should have chosen a different license if they want to be compensated.
      • traceroute66 2y ago
        > It's MPL licensed. Perhaps they should have chosen a different license if they want to be compensated. Or indeed if they wanted to be compensated, they could have moved to an open-core model. It was their decision for many years to keep the majority of the project as foss. IIRC there were only ever two commercial optional licenses, one for the G.729 codec and one for something else. Everything elee was foss. They could have sold licenses for this that and everything else, but it was their decision and theirs alone not to.
• tmaly 2y ago
  This made me think, how many people have tried feeding some of this critical code to the best LLM models and asking it to point out any bugs?
  • some_furry 2y ago
    You probably don't need an LLM to find vulnerabilities in software written like this. It took me a few minutes with GitHub in a web browser, but I'm sure you could make some headway with semgrep if you were bold enough.
  • ngneer 2y ago
    First, can you point to examples where using LLMs to find vulnerabilities works?
  • rini17 2y ago
    Lol no need for LLM. This kind of problems can be caught straight by C compiler itself with -Wall or equivalent switch. Plus there are plenty of static code analyzers. Clearly no one cares here.
• johann8384 2y ago
  I imagine most of the people running Freeswitch have their own patches on top of the community releases anyway so we're compiling those security fixes in to our own builds. That's what we did anyway when I worked for a place using Asterisk, Freeswitch, and OpenSER/Kamailio whatever it is called this decade. "potentially thousands of telecom stacks around the world that SignalWire has decided to keep vulnerable until the Summer, even after they published the patches on GitHub."
• CursedSilicon 2y ago
  In a past life I worked at AWS as a support engineer I once got a ticket from T-Mobile (US) asking what "AWS's best practices were around security patching. How long should we wait?" A week later they admitted to an enormous data breach I'd say I switched phone carriers after that, but after working in the ISP market I already knew they were all absolute clown shows where all the money only went to C-levels and not infrastructure or security
• lenerdenator 2y ago
  I think it's fair to assume that between foreign threat actors, the Five Eyes/other Western pacts, and the demand to make the line go up, there's no real anonymity online. If they want you, they've got the means to get you. In reality that's really no different than the pre-internet age. If you don't want your stuff intercepted, you need to encrypt it by means that aren't trivial to access electronically for a major security apparatus. Physical notes, word-of-mouth, hand signals, etc. Also, you need to be ready for the consequences of what you say and do online should a state actor decide to allocate the resources to actually act upon the data they have.
• Nextgrid 2y ago
  I highly recommend checking out P1 Security's presentations around mobile telco security: https://www.slideshare.net/slideshow/day1-hacking-telcoequipmentthehlrhsslaurentghigonisp1sec/34291135 https://www.slideshare.net/slideshow/day1-hacking-telcoequip.... It's old but there's no reason to believe things have improved as there are zero incentives to. Also, software security vulnerabilities are only part of the problem - the other part is that telcos willingly outsource control and critical access to the lowest bidder: https://berthub.eu/articles/posts/5g-elephant-in-the-room/ https://berthub.eu/articles/posts/5g-elephant-in-the-room/
• sakras 2y ago
  I've been beating the drum about this to everyone who will listen lately, but I'll beat it here too! Why don't we use seL4 for everything? People are talking about moving to a smart grid, having IoT devices everywhere, putting chips inside of peoples' brains (!!!), cars connect to the internet, etc. Anyway, it's insane that we have a mathematically-proven secure kernel, we should use it! Surely there's a startup in this somewhere..
  • wmf 2y ago
    Rewriting all software would cost infinite money.
    • sakras 2y ago
      New smart grids with new software do not require a rewrite!
      • ngneer 2y ago
        They will!
      • wmf 2y ago
        Almost all vulnerabilities are in apps and libraries which seL4 does little or nothing to solve. The only solution is secure coding across the entire stack which will reveal that much of the existing code is so low-quality that it just has to be thrown away and rewritten.
• ta20240528 2y ago
  The really good hacks happen with CAMEL MAP injection. Controls all sorts of goodness like SMS, USSD, and the crown jewel: location services. Many a "bulk SMS" provider in places like the richer carribean islands, and Indonesia that do a lot more than send spam.
  • heraldgeezer 2y ago
    To add, MAP is 2G and 3G. So, it is old. 2G was designed in the 90s. I don't really know what people expect? I'm just happy it works at all, lol.
    • ta20240528 2y ago
      2G GSM piggybacked its wired backed on the ISDN telecom standard (which is which your phone number is called a MSISDN). Today's CAMEL (MAP and CAP) signalling is an evolution of the ISDN signalling which traces it roots back into (amongst others) the SINAP signalling protocol and the SS7 network stack from even before that. SS7 is early 1970s stuff. From a more innocent time.
• capitainenemo 2y ago
  From the article. "This is not typically a problem, since most browsers don’t support URLs longer than 2048 characters, but the relevant RFCs support up to about 8 KB in most cases. (CloudFlare supports up to 32KB.)" So obviously relying on browsers is not enough, but a nitpick. The article links to a stackoverflow which actually notes browsers support a lot more. Browser Address bar document.location or anchor tag ------------------------------------------ Chrome 32779 >64k Android 8192 >64k Firefox >300k >300k Safari >64k >64k IE11 2047 5120 Edge 16 2047 10240
  • some_furry 2y ago
    Ah, that's fair.
• kamma4434 2y ago
  I wonder who in practice runs XMLRPC today. My feeling id that nobody looked at that code in decades, because nobody cares.
• heraldgeezer 2y ago
  SS7 again... ofc. Kinda tiresome now. Yes, insecure, but needed. Unless you want to shut down 2G and 3G worldwide. It is happening, slowly. The FreeSwitch stuff? Telcom buy from vendors like Nokia, Cisco, Ericsson, Huawei where they can't see src anyway.
• protocolture 2y ago
  I have gone on about this before but most carriers have a psychological aversion to security, and most of their vendors adopt the same. They see themselves as the wire, and thus completely incapable of being targeted by hostile third parties. Non exhaustive list of problems I have seen: Credit cards stored in plaintext on the carriers wordpress website. esxi and drac ports publicly available to the internet, not patched. inbound authentication not dropped by core infrastructure, log files just filling up with brute force attempts (often successful) Software vendors not implementing carrier network standards and telling everyone they know better. tech support opening socks proxy ports for technical support reasons and then leaving them open, where they get abused for netflix traffic. Field techs running around with core infrastructure passwords written on their paperwork Vulnerable hardware remaining unpatched and available to the internet for years - particularly fortigate stuff. Technicians building unencrypted pptp vpns on client infrastructure and leaving them open for years. It doesnt surprise me that freepbx/asterisk etc are full of issues. They only get yelled at when they push a change that knocks some eccentric sip config offline, no one cares if they maintain vulnerable code as long as it works. Doubly so because theres a cottage industry in locating and using vulnerable SIP credentials for fraudulent phone calls.
• knowitnone 2y ago
  the paid version is probably not much better