Archive for the ‘network security’ Category

Researchers Release Tool That Finds Vulnerable Robots on the Internet

January 28th, 2019
A team at a robot cybersecurity startup has released a free, open-source tool for information security professionals to help them easily 'footprint' and detect unprotected robots, not only connected to the Internet, but also to the industrial environments where they operate. Dubbed "Aztarna," the framework has been developed by Alias Robotics, a Spanish cybersecurity firm focused on robots and

Posted in Aztarna, cyber security, cyber security tools, hacking robots, hacking tools, iot devices, network security, port scanning tools, Robot hacking, Robotics | Comments (0)

IPS as a Service Blocks WannaCry Spread Across the WAN

August 14th, 2017

One of the most devastating aspects of the recent WannaCry ransomware attack was its self-propagating capability exploiting a vulnerability in the file access protocol, SMB v1.

Most enterprises defences are externally-facing, focused on stopping incoming email and web attacks. But, once attackers gain a foothold inside the network through malware, there are very few security controls that

Posted in Cato Networks, firewall, intrusion prevention system, network security, Network Security Services, network security tool, ransomware, smb vulnerability, WannaCryptor | Comments (0)

What is the hype around Firewall as a Service?

July 10th, 2017

Admit it. Who would not want their firewall maintenance grunt work to go away?

For more than 20 years, companies either managed their edge firewall appliances or had service providers rack-and-stack appliances in their data centers and did it for them.

This was called a managed firewall — an appliance wrapped with a managed service, often from a carrier or managed security service provider

Posted in best firewall software, firewall, firewall as a service, Firewall Security, network security, network security manager, network security tool, secure firewall | Comments (0)

Online Training for Cisco CCNA, CCNP Certification Exams

June 12th, 2017

As governments and enterprises migrate toward controller-based architectures, the role of a core network engineer are evolving and more important than ever.

There is a growing number of jobs in Networking, but if you lack behind, you need to pass some certification exams to enter into this industry and get a significant boost in your IT career.

If you are looking forward to making career

Posted in CCNA, CCNP, cisco certification, Cisco Certified Network Associate, Cisco Certified Network Professional, network administrators, network security | Comments (0)

Vulnerable OpenSSL Handshake Renegotiation Can Trigger Denial of Service

May 9th, 2017

OpenSSL, the popular general-purpose cryptographic library that implements SSL/TLS protocols for web authentication, has recently suffered from several vulnerabilities. We have written about “CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL” and “SSL Death Alert (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers” among others. Today we examine the high-severity bug CVE-2017-3733, the Encrypt-Then-MAC renegotiation crash that can cause a denial of service.

Before SSL/TLS encrypts data, it runs the Handshake and ChangeCipherSpec protocols.

During the Handshake phase, the client and server decide which encryption algorithms to use. Once the negotiation is done, the client and the server send each other a ChangedCipherSpec message, after which the traffic is encrypted with the negotiated algorithms.

Encrypted data is sent in one of two ways along with the message authentication code (MAC) in SSL/TLS.

  1. MAC-then-encrypt: This method calculates the MAC of the plain text, concatenates it with the plain text, and runs the encryption algorithm over it.
  2. Encrypt-then-MAC: The cipher-text is generated by encrypting the plaintext and then appending a MAC of the encrypted plaintext.

If the ClientHello message does not contain an Encrypt-Then-Mac extension, then the default is MAC-then-encrypt mode. If ClientHello has an Encrypt-Then-Mac extension, the server will compute the MAC after encrypting the data.

If the client or server wish to change the algorithms used for encryption, they can renegotiate the Cipher_Suites that they have already agreed upon. This can occur any time during data transfer by initiating a new Handshake, which takes place over an existing SSL connection.

Triggering the vulnerability

OpenSSL offers this explanation:

“During a renegotiation handshake if the Encrypt-Then-Mac extension is negotiated where it was not in the original handshake (or vice-versa) then this can cause OpenSSL to crash (dependent on ciphersuite). Both clients and servers are affected.”

Say the client starts a TLS handshake with the server using the default MAC-then-encrypt mode. If the client later renegotiates with the Encrypt-then-MAC extension enabled and sends encrypted data in that mode before the ChangeCipherSpec message, the server will crash, causing a denial of service.

When the client triggers this vulnerability, the server crashes at the ssl3_get_record function, in the ssl3_record.c file:

The crash occurs at line no. 352, when checking to see if mac_size is less than EVP_MAX_MD_SIZE (64 bytes):

The if statement preceding the assertion checks whether the Encypt-then-MAC flag is set in the server. The macro in the if condition:

The flag TLS1_FLAGS_ECRYPT_THEN_MAC is already set when the ClientHello packet is sent with the Encrypt-then-MAC extension at the time of renegotiation. So the control will go inside the if condition. But because the ChangeCipherSpec message has not yet passed to the server, it does not know it must use Encrypt-then-MAC.

Putting a break point at line no. 352 and checking the mac_size variable shows us the value 0xffffffff, which is greater than EVP_MAX_MD_SIZE (64). Thus the assertion fails and the server crashes.

Let’s go to the code and find how the mac_size variable gets the value 0xffffffff. The EVP_MD_CTX_size function calculates the mac_size.

It returns -1 when the message digest value is null. 0xffffffff is the two’s complement of -1. This means “s->read_hash” returns null as the server tries to calculate the hash using the MAC-then-encrypt mode.

Users of McAfee products are protected from this attack by signature 0x45c09700. All administrators should update OpenSSL to the latest version.

 

Thanks to Hardik Shah for helping me with this post.

 

 

 

 

The post Vulnerable OpenSSL Handshake Renegotiation Can Trigger Denial of Service appeared first on McAfee Blogs.

Posted in computer security, McAfee Labs, network security, Vulnerability | Comments (0)

Firewalls: Still Your First Line of Defense

April 21st, 2017

The term “firewall” has been used since early computing days to describe a kind of electronic bouncer that keeps threats from entering your network. But it would be a mistake to think that this fundamental network security measure is now old school. With the recent boom in internet-connected devices,  firewalls are more important than ever.

Firewalls work by examining and filtering all the information coming in through your internet connection. They represent an important first line of defense because they can stop a malicious program, or attacker, from gaining access to your network and information before any potential damage is done.

Firewalls come in two forms: either as a software program that you install on your computer, or as part of a piece of hardware, like a router, that monitors access to all of the devices with which it connects. In an ideal situation, you would have both.

Software firewalls are important because they allow you to keep your computer protected even if you take it to another physical place, like your office. Plus, software firewalls can be customized to block unsafe applications, setup safe printer sharing, and other options.

That said, a hardware firewall is also necessary if you have a number of computers and devices in one location. A hardware firewall allows you to filter access to all of these devices from one piece of equipment. You will just need to consult your manual to configure it correctly and adjust a few settings.

Hardware firewalls provide essential security for the Internet of Things (IoT), like smart thermostats and smart light bulbs. This is because these new devices often come with weak security features, leaving your network vulnerable if the devices aren’t secured by a firewall.

Take, for instance, the large-scale attack in late 2016 that took down many popular websites. The attackers used thousands of infected webcams, smart fridges, DVRs and other IoT devices to flood the websites with traffic. The devices used in the attack were consumer devices, like yours, left unprotected.

The simple truth is that the more connected we become, the more vulnerable we are to security threats, making the smart use of firewalls even more important.

Here are a few tips to make sure that you stay protected:

  • Secure your computers with a software firewall, like the one included in the McAfee LiveSafe ™ service. In addition to firewall protection, McAfee LiveSafe™ gives you the extra advantage of providing antivirus and threat protection for all your devices, including smartphones and tablets.
  • Use the hardware firewall that is built into your home router or gateway. Consult the manual that came with your router, or do a quick online search to find steps to walk you through the setup.
  • Know that each new internet-connected device you bring into your home is a potential avenue of attack. Make sure to reset any default passwords, and keep those devices current with the latest manufacturer updates.

Looking for more mobile security tips and trends? Be sure to follow @McAfee Home on Twitter, and like us on Facebook.

The post Firewalls: Still Your First Line of Defense appeared first on McAfee Blogs.

Posted in Consumer Threat Notices, Internet of things, network security, next generation firewall | Comments (0)

The perimeter has changed, so should you

April 11th, 2017

People have wandered a long way outside of the secure walls of corporate computing. Your users are working from more places than you can keep track of. They are using devices you may or may not own, and cloud services you may or may not know about. In fact, about 40% of cloud services are procured outside of the IT department. Whether this was your choice or not doesn’t really matter, what matters is that the perimeter concept of information security is rapidly disappearing. The solution is to move to either a pure cloud or a hybrid cloud strategy. With budgets flat and businesses demanding growth and cost savings, the efficiency of cloud services are essential. This applies to security, too.

 

Over the past three decades, a distinctly defined perimeter has been one constant characteristic of information security. Organizations relied on the fact that their assets would operate behind a defined perimeter. Data centers were on premise, and most of the user devices were, too. The increased adoption of laptops brought us VPNs, which was primarily an effort to extend the perimeter.

 

Today, our architectures are very different, driven by a wealth of portable devices, cloud computing, and a highly-mobile workforce. Everyone wants access to everything, everywhere, at any time. The VPN model of connecting “back” to the corporate environment suffers from network latency and the need for multiple holes in the firewall. The old architecture has become too cumbersome, so it is time for a new one.

 

The new security architecture is cloud-based, virtualized, and more concerned with data than location. Security-as-a-service continuously monitors web traffic, regardless of where it originates from. Instead of trying to redirect all user traffic to an on-premises web security gateway, cloud-based web gateways operate where the users are. This configuration improves performance and reduces network complexity, maintaining security at all off-premise locations.

 

Cloud access security brokers (CASB) and data loss prevention (DLP) solutions apply enterprise privacy and security policies to cloud services. These tools make sure that data is appropriately encrypted when in transit or in storage across cloud services, and protect sensitive corporate data from moving to inappropriate locations. They also provide the essential service of monitoring traffic to and from the cloud, helping to identify and secure Shadow IT instances that are a high-risk point for most organizations.

 

Finally, virtual network security platforms (vNSP) are the protectors of public cloud services and traffic. Security services are matching the path of other computing functions, bringing the efficiency and agility of virtualization to cyber defense. Virtual network security readily scales and adapts to dynamic virtual workloads. Perhaps more important, virtual intrusion prevention systems (IPS) deliver inspection and visibility capabilities for east-west traffic that was often overlooked or assumed to be secure in physical data centers.

 

Your organization needs flexibility, agility, and constant connectivity, and innovators responded with public and hybrid cloud compute models that are meeting these needs while reducing costs. Your security needs similar characteristics and security innovators have responded. As devices, data, and people spread across physical and virtual environments, make sure that they do not go there unprotected.

 

As the perimeter changes, so do the objectives of the security team. The primary job is now minimizing risk, especially as devices, data, and processes spread out among the clouds. Next is minimizing business slow-downs and interruptions, and cloud-based security addresses traditional bottlenecks and points of failure with distributed processes, at a significant savings.

 

Third, security needs to actively help the business grow and remain competitive. Every organization now uses technology as an enabler of speed, efficiency, and efficacy. Empowering users to work when mobile and connect to data and applications when needed is an important part of business strategy. Focusing on the data and incorporating security from ideation through deployment is necessary for the organization to succeed, securely.

 

Your security perimeter may be gone, but your people, devices, and data can travel safely and securely with virtualized and cloud-based defenses that operate at the speed and scale of your organization.

The post The perimeter has changed, so should you appeared first on McAfee Blogs.

Posted in Cloud security, Data Center, DLP, network security | Comments (0)

Analyzing CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL

March 8th, 2017

OpenSSL is a popular open-source library for SSL and is used by various software and companies across the world. In January, OpenSSL released an update that fixed multiple vulnerabilities. One of them is CVE-2017-3731, which can cause a denial of service due to a crash. McAfee Labs analyzed this vulnerability to provide detection for customers. 

Figuring out the changes using patch diff

The patch modified a couple of files related to various cipher algorithms. For this report we will examine e_chacha20_poly1305.c. The following code shows the patch to this file, taken from https://git.openssl.org/?p=openssl.git;a=commitdiff;h=2198b3a55de681e1f3c23edb0586afe13f438051.

We can see that a simple step was added to check the value of variable length against the constant POLY1305_BLOCK_SIZE and just below that we see that this constant is subtracted from the variable “len.”

If we look at the declaration, POLY1305_BLOCK_SIZE is declared in the file poly1305.h as “#define POLY1305_BLOCK_SIZE 16.” The variable len is defined in e_chacha20_poly1305.c as “unsigned int len;”

So if the variable len is less than 16, it will cause an integer underflow, that is, the value of len will become very large. When used, this value can cause problems with the normal program flow because the value of len will be incorrect.

Digging further

We can see in the preceding image that this len value is assigned to “actx->tls_payload_length.” Then the function chacha20_poly1305_cipher is called. Inside this function actx->tls_payload_length is assigned to the variable “plen”:

Notice that variable plen will now have the very large value that we got from the previous len integer underflow. We can further see that the value of plen is passed to the function poly1305_Update:

Poly1305_Update will carry this large value as it calls the function Poly1305_blocks:

If we take a closer look at the function, we can see that the variable len contains a very large integer value, which is used as the counter in a “while” loop:

We can also see a call to the function U8TOU32, which reads the value of *inp (a pointer), and that the value of *inp is increased by POLY1305_BLOCK_SIZE for each iteration of the loop. Because the value of len is very large, eventually *inp will point to nonreadable memory. Attempting to read that will cause an access violation error—resulting in an OpenSSL crash.

Exploiting the vulnerability from the network

To exploit this vulnerability, a client needs to use the chacha20_poly1305 cipher suite (or another vulnerable cipher, as can be seen from patch diff) and send an encrypted handshake message in which the record length is less than 16 bytes (in the case of chacha20_poly1305 cipher). This will cause an integer underflow and OpenSSL will crash, as we see in the following images running OpenSSL and Gnu Debugger:

Conclusion

OpenSSL is very popular and thus can be a target for denial of service attacks. These types of vulnerabilities can impact many installations. We recommend that users update their OpenSSL installations to the latest version.

McAfee Network Security Platform customers are protected against this vulnerability through signature ID: 0x45c09400.

The post Analyzing CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL appeared first on McAfee Blogs.

Posted in computer security, McAfee Labs, network security, Vulnerability | Comments (0)

Pentesters Can Take Advantage of Weakness in SAML

March 4th, 2017

When penetration testers examine the security of applications, we employ a number of tools. We recently wrote about keeping track of browser options. Another protocol that we use to test is the Security Assertion Markup Language (SAML), a popular XML-based authentication information exchanger for implementing single sign-on (SSO) authentication.

The protocol works like this:

  • A user accesses the application URL (the service provider).
  • The application initiates the SSO request and redirects the user to the SSO URL (the identity provider) if already not logged in.
  • The user enters valid SSO account details and the identity provider generates SAML response code and sent it to the service provider.
  • The service provider (application) verifies the SAML response code and authenticates the user.

This protocol considered secure, with the following advantages:

  • Users need to authenticate only once online to access different services, reducing the chances for identity theft and phishing attacks. Because SAML response code controls authentication attempts, users account details never leave the identity provider firewall.
  • The unique user accounts are taken care of by the identity provider, so users do not need to remember additional authentications for each application. This even eliminates separate action for each service such as changing or forgotten passwords, etc.
  • An administrator has one console to control all users.

In spite of this generally secure structure, however, we have observed interesting privilege escalation issues through SAML response tampering.

Here is the scenario:

  1. To test authorization, we created two user roles.
  2. Normal user, aka testuser, with limited access.
  3. Administrator user, aka adminuser, with full access.
  4. We launched the application SSO login URL and used testuser to log in.
  5. We ran a man-in-the-middle login process using the Burp proxy server to examine the SSO login.
  6. After entering testuser’s valid id and password, we observed that an intermediary request was used to generate the SAML response and make the SSO.

SAML assertion message generated from a successful authentication.

  1. We intercepted the response for this request.
  2. We copied the Base64-encoded SAML response and decoded the value using decoders available online.
  3. While examining this decoded value, we saw that the value had a parameter “testuser.”
  4. We replaced this value with “adminuser” and again encoded the value with Base64.

Login ID in decoded SAML response.

  1. We placed this edited SAML response into the intercepted response in Step 5 and continued the traffic.
  2. The result was that testuser’s privilege had escalated to a higher level user and that we had effectively logged on as adminuser.

This is one useful attack scenario while pentesting with SAML. Other SAML-specific attacks can be found in the OWASP SAML cheat sheet.

We recommend that application service providers validate user authorization based on the complete original SAML assertion message instead of only on a single element such as the “saml NameID” in the preceding example.

The post Pentesters Can Take Advantage of Weakness in SAML appeared first on McAfee Blogs.

Posted in computer security, McAfee Labs, network security | Comments (0)

Unpatched Python and Java Flaws Let Hackers Bypass Firewall Using FTP Injection

February 21st, 2017

This newly discovered bugs in Java and Python is a big deal today.

The two popular programming languages, Java and Python, contain similar security flaws that can be exploited to send unauthorized emails and bypass any firewall defenses.

And since both the flaws remain unpatched, hackers can take advantage to design potential cyber attack operations against critical networks and

Posted in Cyber Attack, ftp protocol, FTP server, hacking news, Java, network security, network security manager, programming language, protocol injection, Python, Vulnerability | Comments (0)