If you are unfamiliar with Session Management, you can check out my previous article Session Management Part One

I will focus on prevention in this second part of the Session Management topic.

 It is very crucial to handle sessions properly. That means that the application needs to create, maintain, and destroy session tokens properly over the life cycle of the web session.

The two most common session management attacks are session hijacking and session fixation.

I came across a great  blog  you can check out for nice visually explained attacks.

 Session hijacking is the attack where the hacker can gather the information that will help him to reveal the session ID and hijack it and log in as a victim himself.

 After successful authentication, a session fixation attack happens when an application does not change the session ID.

 Preventing Session Management Vulnerabilities

This is an unordered list of the best prevention practices, so you can create a more secure application with “in theory” no session vulnerabilities.

• Session identifier should remain confidential to the application. That can be achieved with:
• Use HTTPS to transfer the session ID token
• Don’t expose session ID in URL, in page content, hidden elements in DOM
• Set secure flags on session ID token cookies, such as “secure” and “httpOnly” – These restrict cookie transfer to HTTPS, and cookies cannot be accessed by JavaScript. You can also check some flags you can use to secure cookies in the article Path Traversal.
• Session ID token (cookie) should have a browser session lifetime. That means that cookies should not be stored in the file, but in the browser memory, so the content can disappear when the browser closes
• Implementing an inactivity timeout for every session. Bellow in the text is an example how to implement timeout using Angular
• When a user logs out, the session on the server should be terminated (proper logging out)
• New session ID should be generated in response for the authentication to be successful
• Use the latest web server framework to generate a new session ID token.
• Pay attention to:
  
  • Session ID name should not describe details about the meaning of the content
  • Session ID length must be at least 128 bits (16 bytes).
  • Session ID must be random enough to prevent from easily guessing
  • Session ID content must be meaningless to prevent information disclosure
• When the application is created for mobile devices, be aware that when you are invalidating a session, you should do it on the mobile and server sides. We can invalidate the session by calling session.invalidate() to destroy the session. 
• In the mobile app, use the session timeout window. Timeout periods depend on the level of the security of the application, they are often:
  
  • High level – 15 min
  • Medium level – 30 min
  • Low level – 1 hour 
• When resetting cookies, cover all authentication state changes, switch from guest user to logged-in user, one to another logged-in user, refresh after the timeout, etc.
• In order not to be able to access data exchanged within the session, the application should use restrictive cache directives for all data that went through HTTP and HTTPS
• Try to perform identity verification. Check the user’s usual IP address or application usage patterns in the application
• Use a web application firewall (WAF)
• When attackers use Brute-Force/Credential stuffing attacks, they attempt multiple logins. A good practice is to limit failed login attempts.
• Enabling multi-factor authentication (MFA) 
• Implement strong password policies
• Implement all prevention steps to avoid XSS vulnerabilities which can be used to steal session IDs. Check out articles about XSS on Vicarius site
• Don’t store passwords in cleartext
• Implement solutions that match used passwords against a list of breached credentials, so users can know and not use the same credentials (breached password protection)
• When using the secure attribute for cookie application, the “__Host” prefix can also prevent overwriting the user’s cookies.
• Try not to use old legacy frameworks and develop with modern tools. If you need to use old technology, try to add a filter or use a configuration setting to disable dangerous functionalities. For example, J2EE supports session management via URL.
• Use a strict CSP (Content Security Policy)
• Use preloaded HSTS (HTTP Strict Transport Security) to force connections to the website to be encrypted. Enable protection by adding the ‘Strict-Transport-Security’ header. Include subdomains also and enable HSTS. For implementation check out site

Organization protection from session hijacking

It is also good to protect not just the application but your organization from these types of attacks. By organization, I mean the most crucial thing – customers or consumers. To protect consumers sessions, the organization can use certificates: 

• “SSL (Secure Sockets Layer) provides security to the data that is transferred between web browser and server. SSL encrypts the link between a web server and a browser which ensures that all data passed between them remain private and free from attack” – more info on site
• TLS (Transport Layer Security) – which is more secured version of SSL. TLS ensures that no third party may eavesdrop or tampers with any message. More info on the site

Of course, there are also some steps that organizations can use these attacks, such as again

• Keep the system up to date by setting up automatic updates on all devices.
• Use antivirus software that can protect against session hijacking attackers
• Incorporate web frameworks instead of inventing your own session management
• Prevent consumers from using a public hotspot (WiFi)
• Use a Virtual Private Network in the organization
• Implement some checks and prevent phishing attacks. Clicking on an email session can be easily stolen.
• Enabling multi-factor authentication (MFA)
• Enforce using strong passwords

Tools for detecting session management attacks:

• Crashtest Security Suite
• HDIV Security
• Invicti (formerly NetSparker)
• Metasploit
• Nessus

How to implement an Inactivity timer

In this example, I will show how to manually create an inactivity timer. You can also implement an Idle timeout if you want to use a third library for implementing timeout. There is a good article that describes the implementation.

Idle timeout is the time the user is inactive on the application. This timeout is needed for better security and to stop unnecessary API calls.

Implementation

1. Create an array of events that you can check if they are not triggered for some time. That would mean that the user is inactive.

  public inactivityEvents: Array<any>[] = [
    [document, 'click'],
    [document, 'mousemove'],
    [document, 'keyup']
  ];

I added just three events as an example but don’t forget to add all necessary document and window events.

2. Create observable out of the array of events and add subscribers. Here the time should start counting, aka inactive timer. The timer will reset when events are triggered.

Declare observableArray as an array of Observables and inactivityObservable as Observable. Also, declare timeout and implement NgZone.

We need to implement NgZone because we want to use its method runOutsideAngular because we want to do work without triggering Angular change detection.

  this.inactivityEvents.forEach(x => {
    observableArray$.push(fromEvent(x[0], x[1]))
  })
  this.inactivityObservable$ = merge(...observableArray$);
 
  this.ngZone.runOutsideAngular(() => {
 
    this.observeable$ = this.mergedObservable$
    .pipe(
      switchMap(ev => interval(1500).pipe(take(this.timeout))),
 
      tap(value => ...
        //here we can add logic for checking time left to inactivity and show notification to the user
        ),
 
      skipWhile((x) => {
        return x != this.timeout- 1
      })
    );
 
  this.subscription = this.observable$.subscribe((x) => {
   ...  
  })

3. After the set time expires, unsubscribe the observable. That is the moment the timer runs out of time.

      this.subscription.unsubscribe();

Conclusion

I just scratched the Session Management topic and summarized it. I tried to provide some additional documentation on how to implement those preventions. As this topic is a big one, follow my next articles, where I will also present a few more prevention implementations.

You can also check out some OWASP suggestions for prevention on this site.

In the end, secure code is the cheapest code!

#session_management #inactivity_timer

Cover photo by Philipp Katzenberger

Vulnerability Scanners: Defined

In a nutshell, organizations can use a vulnerability scanner to check their networks, systems, and apps for security vulnerabilities.

A vulnerability scanner is an automated program that detects and inventory all IT assets linked to a network, such as servers, workstations, laptops, virtual machines, containers, firewalls, switches, and printers.

Vulnerability scanners also strive to determine the operational features of each asset. An example of a potentially vulnerable operational feature includes an operating system that is being used as apps are installed. Other qualities such as open ports and user accounts, among other things, are further examples of potentially vulnerable operational features.

How Vulnerability Scanning Works

You can set up vulnerability scanners to check all network ports for password breaches as well as questionable applications and services.

The system will use various strategies and tactics to trigger devices within the target scope. The target scope determines the type of scan used by the vulnerability platform. The vulnerability scanner will try to match the reactions of the devices to a database and establish risk ratings, or severity levels, depending on those reactions.

Five Types of Vulnerability Scanners

Depending on the assets they scan, vulnerability scanners can be divided into five major categories:

1. Application Scanners

Web application vulnerability scanners evaluate websites to identify known software vulnerabilities and incorrect setups in a network or web-based software programs.

2. Database Scanners

A database vulnerability scanner identifies weak spots and links in a database to prevent malicious attacks from taking advantage of them.

3. Host-based Scanners

Using host-based scanners, you can examine servers, workstations, or other network hosts for vulnerabilities, which show the system’s configuration and patch history. Once access is granted or taken on a system, host-based vulnerability assessment tools can provide insight into the possible damage that insiders and outsiders can inflict.

4. Network-based Scanners

Network vulnerability scanners uncover network security breaches and susceptible systems on wired or wireless networks. Network-based scanners also detect remote access servers and linkages to unsecured networks of business partners.

5. Wireless Scanners

Wireless vulnerability scanners are used to spot unauthorized access points and to verify that a company’s network has been configured securely, among other things.

The Advantages and Disadvantages of Vulnerability Scanning

When talking about Vulnerability Scanning, it is important to weigh in its pros and cons, such as the following:

Pros

Vulnerability Scanning offers the following advantages:

Prevent Cybercriminals from Exploiting Vulnerabilities by Identifying them First

Criminals hunt for and exploit known vulnerabilities in many automated cyber-attacks. That is, their expert hacking abilities do not create or discover a vulnerability: They are merely probing for vulnerabilities, just as any organization with functional scanning software could.

Organizations can find and fix holes and vulnerabilities using the same technologies before anybody else can exploit them.

Define the Level of Risk that Systems are Exposed To

Regular vulnerability scans will help companies assess their security measures’ overall efficacy. Vulnerabilities indicate significantly faulty systems or software that organizations can redesign.

Save Both Time and Money

Automated scans are simple to set up and save money over time. Because vulnerability scanning reduces the danger of a data breach, this can ultimately prevent lost customers, cleanup costs, and fines.

Cons

Vulnerability Scanning also has the following disadvantages:

Vulnerability Scanners are Not Able to Detect Every Vulnerability

Vulnerability scans are not perfect; they are only as good as their latest update.

Even with the most advanced technology, there will be vulnerabilities that the scanner will miss. This issue could be because the flaw is too complicated to exploit and, hence, spotted by an automated tool.

False-Positive Results

Unfortunately, it is not always clear what a vulnerability scan’s results imply. For example, the tool may misidentify something like a vulnerability when it is not. As a result, determining your real security position oftentimes still requires expert interpretation.

Detecting Unclear Vulnerabilities

An identified vulnerability’s influence on your business operations can be difficult to assess. An automated tool will not teach organizations this, while a system administrator is more concerned with the technical aspect.

Conclusion

Vulnerability scanning is critical for any organization looking to establish the optimal course forward to enhance security defenses. Scanning and analysis generate data and identify vulnerabilities that you can use to fine-tune a network, maximizing your security testing expenditure return.

Once again, keeping data safe and secure is no easy feat in this day and age. However, organizations can significantly ease this endeavor with the right vulnerability scanner.

#vulnerabilities #vulnerability_scanner #exploit #hacker #security #defense #vicarius_blog

Zimbra Collaboration has made it back on CISA’s Known Exploited Vulnerabilities Catalog with CVE-2022-27925 and CVE-2022-37042 and the phrase of the day is “remote code execution without authentication.” According to CISA, “These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risk to the federal enterprise.”

CVE-2022-27925 – Zimbra Collaboration (aka ZCS) 8.8.15 and 9.0 has mboximport functionality that receives a ZIP archive and extracts files from it. An authenticated user with administrator rights has the ability to upload arbitrary files to the system, leading to directory traversal. (from NIST website)

CVE-2022-37042 – Zimbra Collaboration Suite (ZCS) 8.8.15 and 9.0 has mboximport functionality that receives a ZIP archive and extracts files from it. By bypassing authentication (i.e., not having an authtoken), an attacker can upload arbitrary files to the system, leading to directory traversal and remote code execution. NOTE: this issue exists because of an incomplete fix for CVE-2022-27925. (from NIST website)

Cybersecurity organization Volexity investigated multiple breaches of ZCS in July and early August. These investigations indicated that “the likely cause of these breaches was exploitation of CVE-2022-27925,” which was initially patched back in March 2022. After further research, Volexity “determined it was possible to bypass authentication when accessing the same endpoint (mboximport) used by CVE-2022-27925.” These findings were subsequently reported to Zimbra and were patched in 9.0.0P26 and 8.8.15P33. This bypass was assigned CVE-2022-37042.

Through Internet-wide scans, Veloxity has also determined that at least 1,000 instances of ZCS have been compromised. These instances affect both global companies and government departments alongside small businesses. The United States has the highest number of compromised servers that have so far been identified.

Veloxity also adds that simply applying the current patch will not resolve any historical compromise between the exploit becoming available and the patch being applied:

“It seems that patching ZCS instances to the newest version may remove webshells placed in some directories. However, if an attacker installed any second-stage or persistent malware (run via cron), then patching your ZCS instance is insufficient to remediate the compromise.”

Zimbra has steps on rebuilding your ZCS instance and importing mail from the old server here.

Sources:

CISA

NIST

Mass Exploitation of (Un)authenticated Zimbra RCE: CVE-2022-27925

#zimbra #CISAnalysis #RCE

Ideally, we should all know this stuff by heart, but as you know that’s just not the case. It’s far from it. Cybersecurity awareness is an expression that probably bores people to death when they hear it – and rightly so! We are the ones that gave it a bad name, by doing weird and unnatural tests on our users, usually to please auditors/upper management/c level.

This notorious term usually means your organization has provided you with a bunch of videos to look at, that you, as a let’s say someone from sales or accounting, won’t care much about nor will understand fully.

Same goes for the phishing campaigns that are internal for the companies. They can actually work against you, as users can adopt the attitude of everything’s suspicious, I am not going to click or reply to any emails before forwarding them to the Cybersecurity team which is better than clicking on stuff blindly, but can easily saturate your team’s capabilities to investigate, leading to much slower resolutions and other issues. This is one of the more benign examples, but its still quite real. And if your SOC team is checking every email, they might miss some much more important event.

Obviously, social engineering is extremely tough thing to crack and control, especially since emails are also hard to defend from appropriately (not to mention that there’s almost no real solution for detecting a fraudulent email that’s coming from an internal compromised mailbox) and its what’s the crux of the whole issue. As with all things, you need to strike some balance here.

Educate your users of course – I still feel this is one of the (if not the) most important thing, but also set aside some time to understand their context, thus their ‘answers’ if you’ve just did a phishing campaign. There’s usually a reason behind every one of those user-based actions, and ideally you are going to understand your users and why they do such thing.

To conclude, I still feel that education on Cyber awareness is paramount, but if you’re going to do it blindly with out of context surveys, random videos, and phishing campaigns (that you grade on how they passed just to impress upper management) – I dare say better not to do it at all!

With that out of the way, let me try and connect some dots, and talk about the most common things an organization might experience, regardless of its size or maturity.

Common Attacks

For this article, I opted to talk about social engineering (phishing), malware and ransomware, as well as passwords and authentication. In the second, upcoming, part of this article I will talk more about MFA, backups, patches, and other things you can do to stay safer and endorse a better cyber hygiene.

Social Engineering

Social Engineering, sometimes known as People hacking is a term that is used to describe a cyber attack that targets a human, rather than a computer/electronic device.

No need to brute force and waste your CPU/GPU, when you can ask nicely, right?

All jokes aside, these social engineering attack can be extremely complex, and quite devastating to the victim as well. These attacks are usually layered and can escalate quite a bit. Imagine an attacker taking some of your publicly available information to use and obtain more information on your phone, email, ISP.

With these steps, they can eventually escalate to something like your bank account! Check this video out, as it is a prime example of how attackers can obtain your information.

Social engineering is a huge topic! And I mean huge. It also doesn’t necessarily entail a human interaction. Most notorious examples of this are the parking lot ‘lost’ USB an attacker would drop in hopes of an employee plugging it into a computer that belongs to the company. Another one is leaving the charging cable plugged in, in a very public place. Similarly to the lost USB, the cable most likely has some keylogging software or another tool to help the attacker gain control of your device.

Social Engineering: Phishing

Phishing is as we all know one of the most common attacks out there, used by many different types of threat actors, from scammers to more advanced threat actors. This is the stage zero for an attack, usually. This attack vector is used to gain access to your org’s infrastructure, before trying to move laterally, escalate privileges, drop payloads, or anything else.

This is an attack that’s a ‘subgroup’ of the social engineering class of attacks, and as the name implies, is directed against humans instead of computers.

When we say phishing, we usually mean emails, but phishing can be done through voice/calls – aka Vishing or through SMS – aka Smishing.

These are particularly dangerous since threat actors will use these tactics on an enormous scale, usually leveraging leaked/stolen phone numbers and/or emails.

I’ve already talked about most common ways phishing tries to get us to act – e.g., urgency, calling you to action, basically anything to make you act quickly without much contemplation.

There are also three main forms in which we can see phishing:

• Spearphishing – More targeted than general/regular phishing, spearphishing usually aims at an individual or a group. These campaigns are usually more carefully crafted than the email messages and bad sites you can see with general phishing since they are created with the idea to target a specific group. Oftentimes, as a part of a much larger campaign against the said group.
• Whaling – More targeted than spearphishing, whaling refers to targeting individuals of high-value – think C-level execs. These messages tend to be most sophisticated as well, thus, much harder to notice.
• Phishing – There’s no personal/individual component here, these attacks are usually of a larger scale, simpler and are generally much easier to spot since the messages are usually not that carefully crafted, and the malicious sites they try to refer you will mostly contain some obvious red flags that will signal for you that it’s time to get the hell out.

Individually, you might encounter general phishing attacks, but if you work at a high level in a big company that’s an interesting target, your business email might be of particular interest to the threat actors, making you become a prime target for these more sophisticated attacks such as whaling and spearphishing.

Good/best practices Recap

I already talked about this extensively, but there’s never enough awareness when it comes to phishing, if you ask me, so let me add these here as well:

• Untrusted email? Delete without opening, or even better, if you have a Cybersec team at your company, forward it to them. You can also report as a spam to your email provider.
• Never open attachments from untrusted sources. Even if the contact is legitimate but the content/email message wasn’t expected by you.
• Do not click on embedded stuff in the emails – if possible, go to that site through your browser (no clicks in your email client!) and try to see the content there.
• Check for misspelling in the domain names, etc.
• Try not to publicly share your personal information. Segment your stuff. If necessary, create another email, or even do ‘burner’ email addresses that you will use for a specific purpose before discarding it.

Also remember that any one of us can fall prey to phishing. If this happens to you, change any passwords that are tied to the breach (if you have multiple same passwords – ouch, please don’t do this though – change all the instances of the compromised password). Report immediately to IT/Cybersec team if this happens on the work email.

Malware

It doesn’t matter if our AV solutions are becoming better and better, scanning against large databases that collect malicious hashes/signatures for malware, this is still a big threat and it is always being worked on, developed.

Malware or malicious software is any piece of software that was designed with the intent to do malicious things to your system. There are many different types of malware, and I will be looking into this in the future, but for now I will just focus a bit on one of the most infamous types of malware, that we have all heard being talked about in the past couple of years, a lot – Ransomware.

Ransomware

Ransomware is a special type of malware, used to infect systems while encrypting the data so that it is held for ransom, hence ransomware. In theory, if the victim was to pay the ransom, the data is then returned to its owner. However, most security experts would advise you not to pay ransom but to rather have DLP policies and good backups so you can recover from this attack.

Even if the data’s returned, there’s no guarantee that it wasn’t leaked first. The payment is usually made in cryptocurrencies (such as Bitcoin).

Ransomware spreads by exploiting vulnerabilities in software (think MS Office, Windows, etc.) and can be quite fast to spread. The idea is to infect as much systems as possible, so they are rendered inaccessible and then ask for ransom – paying the attackers to give you their key to decrypt the data.

There’s usually a window that displays the message with the conditions, once the malware completes its encryption.

Wannacry Ransomware window – Instructions on paying the ransom

Tips on how to protect yourself

Generally, its best to combine good awareness with up-to-date systems that are patched up. This is especially important for OSes!

• Update your OS and other software regularly
• Don’t open suspicious emails or click on suspicious links. Don’t open attachments. Similar to phishing best practices.
• Back up your important data and store it somewhere safe and outside of reach
• Keep you AV solution up-to-date
• Never plug unknown USBs and other media (cables too) into computers that you care about or are important!!

Lastly, don’t pay the ransom! Rather, have a strategy in place if this happens, and contact authorities. Try to contain the infection as well, by disconnecting your network gear if and where needed. However, keep in mind that you might not want to power off the infected device since this can backfire on you, leaving you with no options to decrypt it without paying the ransom.

Conclusion

There’s much more that threat actors use, and there are many other types of malware out there. In time, I hope to cover most of them, but until then just keep in mind that you don’t necessarily need to be a tech expert or an Infosec pro to stay safe online. Most of the stuff I outlined in this, and previous articles pertains to best practices e.g., adopting good habits. This is something anybody can do and is for sure something that pays off to adopt.

Until next time!

Cover image by Michael Geiger

#cyberawareness #malware #phishing #common-attacks #ransomware