Ah, the ever-present PDF, and our love-hate relationship with the format. We’ve lost count of how many vulnerabilities have been fixed in PDF software, but it’s been a bunch over the years. This week, we’re reminded that Adobe isn’t the only player in PDF-land, as Foxit released a round of updates, and there were a couple serious problems fixed. Among the vulnerabilities, a handful could lead to RCE, so if you use or support Foxit users, be sure to go get them updated.
Remember PunkBuster? It’s one of the original anti-cheat solutions, from way back in 2000. The now-classic Return to Castle Wolfenstein was the first game to support PunkBuster to prevent cheating. It’s not the latest or greatest, but PunkBuster is still running on a bunch of game servers even today. [Daniel Prizmant] and [Mauricio Sandt] decided to do a deep dive project on PunkBuster, and happened to find an arbitrary file-write vulnerability, that could easily compromise a PB enabled server.
One of the functions of PunkBuster is a remote screenshot capture. If a server admin thinks a player is behaving strangely, a screenshot request is sent. I assume this targets so-called wallhack cheats — making textures transparent, so the player can see through walls. The problem is that the server logic that handles the incoming image has a loophole. If the filename ends in
.png as expected, some traversal attack checks are done, and the png file is saved to the server. However, if the incoming file isn’t a png, no transversal detection is done, and the file is naively written to disk. This weakness, combined with the stateless nature of screenshot requests, means that any connected client can write any file to any location on the server at any time. To their credit, even Balance, the creators of PunkBuster, quickly acknowledged the issue, and have released an update to fix it.
Continue reading “This Week In Security: PunkBuster, NAT, NAS And MP3s”
The SIP protocol is commonly used for IP telephone communications. Unfortunately it’s notorious for having issues with NAT traversal. Even some major vendors can’t seem to get it right. [Stephen] had this problem with his Cisco WRVS4400N router. After a bit of troubleshooting, he was able to come up with a workaround that others may find useful.
The router had built in SIP ALG functionality, but it just didn’t work. [Stephen] was trying to route SIP traffic from a phone to an Asterisk PBX system behind the router. The router just couldn’t properly handle these packets regardless of whether SIP ALG was enabled or disabled.
[Stephen] first tried to change the SIP port on the external VOIP phone from the default of 5060 to something else. Then he setup port forwarding on the router to the Asterisk box to forward the traffic to the Asterisk system on the original port. This sort of worked. The calls would go through but they would eventually drop after about 20 seconds.
The only thing that [Stephen] could get to work completely was to change the SIP port in Asterisk’s sip.conf file using the “bindport” directive. He changed it to some random unused high port number. Then he setup port forwarding on the router to forward incoming UDP packets on that port to the Asterisk system. This worked fine, but now all of the original phones behind the router stopped working because they were configured to use the default port of 5060.
Rather than re-configure all of the phones in the organization, [Stephen] made one change on the Asterisk system. He setup an iptables rule to forward all incoming traffic on UDP port 5060 to the new SIP port. Now all of the phones are working with minimal changes across the organization. It’s a lot of hassle to go through just because the router couldn’t handle SIP correctly, but it gets the job done.
Many G1/ADP1 owners have been using the app Tetherbot to get internet access on their laptop via USB to the phone’s data connection. The app relied on the Android Debug Bridge to forward ports. It worked, but people wanted a solution better than a SOCKS proxy. The community figured out a way to create a properly NAT’d connection using iptables and then [moussam] rolled them up into easy to use applications. There’s one for setting up a PAN device on Bluetooth and another for adhoc WiFi networking. It requires you to have root on your phone, but hopefully you’ve achieved that and are already running the latest community firmware.
Zero Day has an interview with German researchers who have found a way to take down the Storm Worm botnet. Their program, Stormfucker, takes advantage of flaws in Storm’s command network: Nodes that are NAT‘d only use a four-byte XOR challenge. Nodes that aren’t NAT’d are only using a trivial 64bit RSA signature. Their solution can clean infected machines and also distribute to other nodes. Unfortunately, installing software without the user’s consent is the exact same behavior as malware. Don’t expect to see this in any sort of widespread use. The researchers did point out that some ISPs have moved to shutting off service for infected customers until their machines are cleaned.