Home Tags Transmission Control Protocol (TCP)

Tag: Transmission Control Protocol (TCP)

Linkerd 1.0 helps cloud services communicate

Linkerd, providing an enterprise-level open source service mesh for cloud-native applications, has moved to a 1.0 release.Offered by cloud software provider Buoyant, the mesh adds service discovery, load balancing, failure handling, instrumentation, and routing to all interservice communication.[ InfoWorld's quick guide: Digital Transformation and the Agile Enterprise. | Download InfoWorld’s essential guide to microservices and learn how to create modern web and mobile applications that scale. ] Bouyant describes a service mesh as a dedicated infrastructure layer for safe, fast, and reliable service-to-service communication, sitting as a layer of abstraction above TCP/IP.
It's responsible for delivering requests through a complex topology of services in a cloud-native application, said William Morgan of Buoyant.To read this article in full or to leave a comment, please click here

TCP/IP headers leak info about what you’re watching on Netflix

Not even HTTPS can hide your secret Gilmore Girls fetish An infosec educator from the United States Military Academy at West Point have taken a look at Netflix's HTTPS implementation, and reckons all he needs to know what programs you like is a bit of passive traffic capture.…

VU#214283: Commvault Edge contains a buffer overflow vulnerability

Commvault Edge,version 11 SP6(11.80.50.0),is vulnerable to a stack-based buffer overflow vulnerability.

Nginx JavaScript is ready for prime time

Nginx has upgraded its web server and load balancer to take advantage of its JavaScript implementation. The company on Tuesday debuts Nginx Plus R12, the commercially supported version of its technology.

This release moves NginScript, a JavaScript-...

Cisco ASA Clientless SSL VPN CIFS Heap Overflow Vulnerability

A vulnerability in Common Internet Filesystem (CIFS) code in the Clientless SSL VPN functionality of Cisco ASA Software could allow an authenticated, remote attacker to cause a heap overflow. The vulnerability is due to insufficie...

Fileless attacks against enterprise networks

This threat was originally discovered by a bank’s security team, after detecting Meterpreter code inside the physical memory of a domain controller (DC). Kaspersky Lab participated in the forensic analysis, discovering the use of PowerShell scripts within the Windows registry.

Additionally it was discovered that the NETSH utility as used for tunnelling traffic from the victim’s host to the attacker´s C2.

VU#867968: Microsoft Windows SMB Tree Connect Response denial of service vulnerability

Microsoft Windows contains a memory corruption bug in the handling of SMB traffic,which may allow a remote,unauthenticated attacker to cause a denial of service on a vulnerable system.

Kill it with fire: US-CERT urges admins to firewall off Windows...

Shadow Brokers may have loosed a zero-day so you're better safe than sorry The US computer emergency readiness team is recommending organisations ditch old versions of the Windows SMB protocol and firewall off access to file servers – after a potential zero-day exploit was released by the Shadow Brokers hacking group. The call from the US security clearing house does not name the Shadow Brokers as the cause of its warning, only that its advice follows public reporting of a potential Server Message Block (SMB) vulnerability. Last year, the Shadow Brokers dumped online a cache of hacking tools from the NSA's Equation Group that attack vulnerabilities in products from major technology vendors.

The exploits were touted in a staggeringly expensive online auction. That auction, as expected, flopped. Last week, the Shadow Brokers dropped online a further cache of offensive tools for free as a parting gift: the crew is slipping off into retirement.

The group's collection of Windows exploits remains for sale, however: that download includes what's claimed to be an exploit targeting a Windows SMB zero-day vulnerability.

That SMB flaw remains unconfirmed thanks to the exploit's US$200,000-plus asking price. [250 BTC. 1 BTC = US$915 at the time of writing – ed.] US-CERT says administrators should disable SMB version one and block all SMB traffic at network boundaries as a precaution. "In response to public reporting of a potential Server Message Block vulnerability, US-CERT is providing known best practices related to SMB," it says in an advisory. "This service is universally available for Windows systems, and legacy versions of SMB protocols could allow a remote attacker to obtain sensitive information from affected systems." The team recommends administrators: Disable SMB v1. US-CERT cautions users and administrators of potential issues that could be created by disabling SMB v1. Microsoft has been urging people to get off SMB v1 for ages. Block all versions of SMB at the network boundary by blocking TCP port 445 with related protocols on UDP ports 137-138 and TCP port 139, for all boundary devices. For more information on securing SMB, you should check out Microsoft's advisories 2696547 and 204279. ® Sponsored: Flash enters the mainstream.
Visit The Register's storage hub

Android tops 2016 vuln list, with 523 bugs

Google joins Microsoft, Apple, Adobe in top of the pops Of any single product, CVE Details reckons, Android had the most reported vulnerabilities in 2016 – but as a vendor, Adobe still tops the list. The analysis is limited by the fact that only vulnerabilities passing through Mitre's Common Vulnerabilities and Exposures (CVE) database are counted.

That's a statistically worthwhile dataset, however, since 10,098 bugs were assigned numbers during 2016. Even so, with 523 vulnerabilities landing a CVE number in 2016, Android carried nearly double the patch-load of Adobe Flash (which had 266 and was number four on the list). It's worth noting that while Debian Linux (319 CVEs) and Ubuntu Linux (278 CVEs) landed second and third places, many of the CVEs attributed to those OSs will be inherited from third party packages included in the distributions. By vendor, Adobe was the clear winner with 1,383 vulnerabilities, with Microsoft in second place at 1,325, Google third with 695, and Apple fourth at 611. Android had a fairly torrid 2016 in terms of security stories.
It inherited a TCP snooping bug from the Linux kernel (August); in the same month it emerged that a Qualcomm “god mode” bug reached production Android devices.

The year ended with Mountain View patching the briefly-infamous Dirty COW bug. It would, however, be unfair to attribute Android's “best in show” award solely to it being a buggy mess of insecure software whose patches are only guaranteed to reach Nexus devices. Google does, after all, offer a generous and popular bug bounty scheme, making it an attractive target for white- as well as black-hat attackers.

The program stretches all the way to US$50,000 if you can manage remote pwnage of TrustZone or Verified Boot. Researchers have clearly lavished extra love on The Chocolate Factory in 2016: in the CVE Details 2015 analysis, the top four vendors were Adobe (1,588), Microsoft (1,466), Apple (1,264) and Redhat (a paltry 576). ® Sponsored: Customer Identity and Access Management

Another Massive DDoS Closes Out 2016, But Mirai Not To Blame

Using a new malware variant called Leet, the 650 Gbps DDoS attack matched Mirai's floods of traffic. This past year has been one for the record books when it comes to distributed denial of service (DDoS) attacks, so it is only proper that 2016 closes out with news of another massive DDoS attack, reported by Imperva researchers.

According to them, the Imperva Incapsula network was forced to mitigate a 650 Gbps DDoS attack just a few days before Christmas. One of the largest DDoS attacks on record, this particular assault is notable because it strayed from the bad guys' recent DDoS playbook.

For much of the year, attackers have been testing the bounds of DDoS traffic-pushing capabilities using the advanced Mirai botnet, which consists of hijacked IoT devices.

This time around, Imperva researchers say the holiday attack came at the hands of a new malicious network it calls Leet Botnet. Earlier this fall, Mirai was behind the 620 Gbps attack against KrebsOnSecurity.com, a 990 Gbps attack against French hosting provider OVH that reportedly utilized a network that could have been capable of pushing up to 1.5 Tbps in malicious traffic, and the massive DDoS in October against DNS provider Dyn that reached an estimated 1.2 Tbps in malicious traffic.

To pull off these attacks, Mirai primarily relied on tens of thousands of IoT devices, most of which were compromised CCTV cameras and DVR machines. Imperva researchers report that spoofed IPs make it impossible to figure out what kind of devices carried out the Christmas attack.

Their analysis of the payload does at least lead them to conclusively determine it was another botnet wreaking havoc. "So far, all of the huge DDoS attacks of 2016 were associated with the Mirai malware," wrote Avishay Zawoznik and Dima Bekerman of Imperva. "However, the payload characteristics clearly show that neither Mirai nor one of its more recent variants was used for this assault." Like many recent DDoS attacks, the Leet Botnet used a combination of both large and small SYN packet sizes "to both clog network pipes and bring down network switches," the pair wrote.

The smaller packets were used to push up packet rates up past 150 million packets per second (Mpps), while the larger ones were used to increase the overall attack capacity.
Imperva dubbed the botnet Leet because of a 'signature' left in some of the TCP Options headers of the smaller packets that spelled out "1337." What really interested researchers, though, was Leet's larger payloads, which were populated by shredded lists of IP addresses that indicated Leet was accessing local files of compromised devices and scrambling them up to generate its payloads. "Basically, the entire attack was just a mishmash of pulverized system files from thousands upon thousands of compromised devices," Zawoznik and Bekerman wrote. "It makes for an effective obfuscation technique that can be used to produce an unlimited number of extremely randomized payloads. Using these payloads, an offender can circumvent signature-based security systems that mitigate attacks by identifying similarities in the content of network packets."  This year we saw DDoS attacks escalate to record heights and these high-powered botnets are a symptom of the times. So far, all of the huge DDoS attacks of 2016 were associated with the Mirai malware. However, the payload characteristics clearly show that neither Mirai nor one of its more recent variants was used for this assault. Related content: Ericka Chickowski specializes in coverage of information technology and business innovation.
She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio More Insights

Switcher: Android joins the ‘attack-the-router’ club

Recently, in our never-ending quest to protect the world from malware, we found a misbehaving Android trojan.

Although malware targeting the Android OS stopped being a novelty quite some time ago, this trojan is quite unique.
Instead of attacking a user, it attacks the Wi-Fi network the user is connected to, or, to be precise, the wireless router that serves the network.

The trojan, dubbed Trojan.AndroidOS.Switcher, performs a brute-force password guessing attack on the router’s admin web interface.
If the attack succeeds, the malware changes the addresses of the DNS servers in the router’s settings, thereby rerouting all DNS queries from devices in the attacked Wi-Fi network to the servers of the cybercriminals (such an attack is also known as DNS-hijacking).
So, let us explain in detail how Switcher performs its brute-force attacks, gets into the routers and undertakes its DNS-hijack. Clever little fakes To date, we have seen two versions of the trojan: acdb7bfebf04affd227c93c97df536cf; package name – com.baidu.com 64490fbecefa3fcdacd41995887fe510; package name – com.snda.wifi The first version (com.baidu.com), disguises itself as a mobile client for the Chinese search engine Baidu, simply opening a URL http://m.baidu.com inside the application.

The second version is a well-made fake version of a popular Chinese app (http://www.coolapk.com/apk/com.snda.wifilocating) for sharing information about Wi-Fi networks (including the security password) between users of the app.
Such information is used, for example, by business travelers to connect to a public Wi-Fi network for which they don’t know the password.
It is a good place to hide malware targeting routers, because users of such apps usually connect with many Wi-Fi networks, thus spreading the infection. The cybercriminals even created a website (though badly made) to advertise and distribute the aforementioned fake version of com.snda.wifilocating.

The web server that hosts the site is also used by the malware authors as the command-and-control (C&C) server. The infection process The trojan performs the following actions: Gets the BSSID of the network and informs the C&C that the trojan is being activated in a network with this BSSID Tries to get the name of the ISP (Internet Service Provider) and uses that to determine which rogue DNS server will be used for DNS-hijacking.

There are three possible DNS servers – 101.200.147.153, 112.33.13.11 and 120.76.249.59; with 101.200.147.153 being the default choice, while the others will be chosen only for specific ISPs Launches a brute-force attack with the following predefined dictionary of logins and passwords: admin:00000000 admin:admin admin:123456 admin:12345678 admin:123456789 admin:1234567890 admin:66668888 admin:1111111 admin:88888888 admin:666666 admin:87654321 admin:147258369 admin:987654321 admin:66666666 admin:112233 admin:888888 admin:000000 admin:5201314 admin:789456123 admin:123123 admin:789456123 admin:0123456789 admin:123456789a admin:11223344 admin:123123123 The trojan gets the default gateway address and then tries to access it in the embedded browser. With the help of JavaScript it tries to login using different combinations of logins and passwords. Judging by the hardcoded names of input fields and the structures of the HTML documents that the trojan tries to access, the JavaScript code used will work only on web interfaces of TP-LINK Wi-Fi routers If the attempt to get access to the admin interface is successful, the trojan navigates to the WAN settings and exchanges the primary DNS server for a rogue DNS controlled by the cybercriminals, and a secondary DNS with 8.8.8.8 (the Google DNS, to ensure ongoing stability if the rogue DNS goes down).

The code that performs these actions is a complete mess, because it was designed to work on a wide range of routers and works in asynchronous mode. Nevertheless, I will show how it works, using a screenshot of the web interface and by placing the right parts of the code successively. If the manipulation with DNS addresses was successful, the trojan report its success to the C&C So, why it is bad? To appreciate the impact of such actions it is crucial to understand the basic principles of how DNS works.

The DNS is used for resolving a human-readable name of the network resource (e.g. website) into an IP address that is used for actual communications in the computer network.

For example, the name “google.com” will be resolved into IP address 87.245.200.153.
In general, a normal DNS query is performed in the following way: When using DNS-hijacking, the cybercriminals change the victim’s (which in our case is the router) TCP/IP settings to force it to make DNS queries to a DNS server controlled by them – a rogue DNS server.
So, the scheme will change into this: As you can see, instead of communicating with the real google.com, the victim will be fooled into communicating with a completely different network resource.

This could be a fake google.com, saving all your search requests and sending them to the cybercriminals, or it could just be a random website with a bunch of pop-up ads or malware. Or anything else.

The attackers gain almost full control over the network traffic that uses the name-resolving system (which includes, for example, all web traffic). You may ask – why does it matter: routers don’t browse websites, so where’s the risk? Unfortunately, the most common configuration for Wi-Fi routers involves making the DNS settings of the devices connected to it the same as its own, thus forcing all devices in the network use the same rogue DNS.
So, after gaining access to a router’s DNS settings one can control almost all the traffic in the network served by this router. The cybercriminals were not cautious enough and left their internal infection statistics in the open part of the C&C website. According to them, they successfully infiltrated 1,280 Wi-Fi networks.
If this is true, traffic of all the users of these networks is susceptible to redirection. Conclusion The Trojan.AndroidOS.Switcher does not attack users directly.
Instead, it targets the entire network, exposing all its users to a wide range of attacks – from phishing to secondary infection.

The main danger of such tampering with routers’ setting is that the new settings will survive even a reboot of the router, and it is very difficult to find out that the DNS has been hijacked.

Even if the rogue DNS servers are disabled for some time, the secondary DNS which was set to 8.8.8.8 will be used, so users and/or IT will not be alerted. We recommend that all users check their DNS settings and search for the following rogue DNS servers: 101.200.147.153 112.33.13.11 120.76.249.59 If you have one of these servers in your DNS settings, contact your ISP support or alert the owner of the Wi-Fi network. Kaspersky Lab also strongly advises users to change the default login and password to the admin web interface of your router to prevent such attacks in the future.

Attackers use hacked home routers to hit Russia's 5 largest banks

Botnets made up of hacked home routers were used to launch distributed denial-of-service attacks against the five largest financial organizations in Russia. The attacks occurred on Monday, Dec. 5, and were detected and mitigated by Rostelecom, Russia’s state-owned telecommunications company. The attacks peaked at 3.2 million packets per second (Mpps) and the longest attack lasted for over two hours, Rostelecom reported Friday. The company did not provide a bandwidth measurement for the attacks, but 3.2Mpps is not that much. DDoS mitigation providers regularly see attacks that exceed 100 Mpps and a very large September attack against the website of cybersecurity blogger Brian Krebs peaked at 665Gbps and 143Mpps. This week’s DDoS attacks against the Russian banks used the TCP SYN flood technique and originated from hacked home routers, according to Muslim Medzhlumov, director of Rostelecom’s cybersecurity center. A common trait for these routers is that all of them were using the CPE WAN Management Protocol (CWMP), also known TR-069. This is a protocol used by ISPs to remotely manage routers installed in their customers’ homes. A vulnerability was recently found in the TR-069 implementation from routers handed out to users by ISPs in multiple countries, including Deutsche Telekom in Germany, Eir in Ireland and TalkTalk in the U.K. Attackers quickly took advantage of the flaw to infect thousands of devices with malware and it’s very likely that some of them were used to launch the attacks against the Russian banks. Last Friday, the Russian Federal Security Service, the FSB, said that it foiled a large-scale cyberattack planned by a foreign intelligence service that aimed to destabilize the country’s financial system. The attack was planned for Dec. 5, according to the FSB, and would have included spreading fake claims about a crisis in the country’s financial system via social media and text messages. It’s not clear whether DDoS was also part of the plan and if the attacks mitigated by Rostelecom are related to the foiled campaign. DDoS attacks against banks are not unusual. In 2012, crippling DDoS attacks disrupted the online services of multiple banks in the U.S. In July 2015, three banks in the U.K. suffered similar disruptions. According to the FBI, financial institutions regularly receive extortion emails from hackers threatening to disrupt their services.