Posts tagged: 'network security'
The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.https://blog.logrhythm.com/tags/network-security/feed
Recently, I learned a valuable lesson from what appeared as though it would be a regular Monday. My day started off routinely, but along the way some surprising events unfurled.
I was scheduled to go on-site with a federal customer for a “knowledge transfer” (aka OJT) as a new NOC/SOC team was coming online. When I got there, it started out as a rather typical meeting—get an understanding of the team’s knowledge of LogRhythm, assess their goals, and introduce them to any new features/products available.
Prior research led me to believe that this was an older deployment that had been neglected for some time. I was pleasantly surprised to find out that this was not the case. Rather, it was a rather new XM-6350 running LogRhythm 6.3.3 and the latest KB. Not having to perform a system upgrade was a relief.
However, as I listened to the customers’ requirements and dug into the deployment deeper, I quickly realized that the system was only being used for log collection, and rarely were people logging in or monitoring the data being collected by the XM. I’d say they were using about 30% of the LogRhythm features and functionality. Moreover, the WebUI wasn’t installed and AIE was disabled.
After a quick install of the WebUI, initialization of AIE, addition of the basic LOW/LOW-LOW rules found in the Post-Install Guide for POCs and setting up the third-party threat feeds (as well as some other customer requested tweaks)—the XM was back in fighting shape!
After a brief conversation, my sales rep and I started to walk the team through a quick demo using the customers XM, Data and WebUI. Within 10 minutes of talking, we happened to click on the Alarms tab, and to our surprise, we found some interesting data.
A few red alarm cards with ratings of 90 appeared denoting “Malware Found.” The team asked “What’s that all about?” We began to pivot drilldown and discovered the systems affected by the malware. Apparently this information was being reported by their Symantec and McAfee systems for quite some time and on the regular.
The NOC/SOC team quickly sprang into action to remedy the issue (albeit they were a bit annoyed). Moments later, we returned to the demo and another alarm fired with a score of 97. The team (almost in unison) said “What now!?”
After a quick drilldown, we discovered that their Fortinet deployment was reporting a breach coming from an “external IP” (outside the U.S.). Being that this was a government customer, we’d just tripped DEFCON-1 (and were called into the manager’s offices to explain the situation). The customer thanked us for helping to spot the external breach and asked us to leave for the day, as they were about to get very busy.
What was the lesson learned? Make sure that you always look under the hood of an existing LogRhythm deployment to verify that the basics have been covered. It’s important to understand what LogRhythm is capable of and how to best leverage the system to your advantage.
As one of the NOC/SOC employees put it, “If we’d been paying attention and using LogRhythm more regularly, we could have caught this sooner. Who knows how long we’ve been under attack.”
A typical Monday, indeed…
This week, security researchers revealed evidence of a new flaw, LogJam, which could allow hackers to weaken encrypted connections between a user and a web or email server. The vulnerability was discovered as part of investigations into the FREAK flaw, found earlier in the year. LogJam takes advantage of software using 512-bit encryption keys and allows a hacker to trick a webserver to think it is using a stronger encryption key than it is. Any organization that patched the FREAK flaw will not be vulnerable to LogJam, and to take advantage of the vulnerability, the hacker needs to be on the same network as the victim.
Currently it feels like a day doesn’t go by without an organization being hacked, or a new security vulnerability being revealed. Over the last year or so we’ve seen a few serious flaws exposed and it’s likely we’ll see many more as the internet gets older and hackers get better at finding and exploiting cracks that have appeared. However, some threats are more serious that others and, while it pays to make people aware of all of them, we need to try and avoid causing mass hysteria each time one emerges.
The fact that LogJam can only be exploited when hackers and targets are on the same network, as well as patches being imminent, means that hype around it is likely to be a bit of a storm in a tea cup. Organizations should, however, use flaws like this as an excuse to give themselves a security health-check. While the fact that someone has to be on the same network to take advantage of the flaw may see many breathe a sigh of relief, they do have to ask themselves one question – would we know if they are and taking advantage? With an increase in remote working, as well as a few high profile breaches perpetrated by a malicious insider, no-one should be resting on their laurels quite yet. We’ve seen countless cyber hacks take months, or even years in some cases, to be identified and remediated, so everyone should really be double-checking they’re clean.
No business is safe today and trying to prevent attacks is becoming almost pointless. If a hacker wants to get in badly enough, they’ll happily spend some time by-passing even the best firewalls and intrusion detection systems. Given this, organizations need to shift their focus from trying to them getting in, to making sure that, when they do, they can get them out as quickly as possible. Businesses now need to have the necessary security intelligence in place, to enable them to detect and respond to threats in hours and minutes – rather than months and days – to be sure they can limit any damage. With flaws like LogJam being identified with increasing frequency, the only real way to know you’re safe, is to know you can stop an attack in its tracks as soon as it gets going.
The home network is equally important to secure as the organization you work for. Think about it, this is the network that you use when not in the office; you plug your work laptop in, access sites that are unfiltered/unprotected by your company’s proxy, and then bring the laptop back in to the office the next day and plug it in to the production network. This has the potential to introduce significant risk to the organization. This risk is only exacerbated if someone is able to compromise your home network. In fact, using work laptops outside of the company network is one of the most common ways malware makes it into the organization.
For these reasons it is important to take security seriously both inside and outside of the office. To help with this, I’ve put together 7 steps that you can take to improve the security of your home network.
1. Encrypt your home network using WPA2 and a strong password
Open wireless networks should be avoided unless there is no other option. When using open networks, a VPN should be employed to protect your data while in transit. When it comes to your personal home network, there is absolutely no reason to leave the wireless network open. Encryption is built in to every standard Wi-Fi router so there is absolutely no reason to not enable this. More importantly, Wi-Fi Protected Access 2 (WPA2) should be used as it is the most secure Wireless protocol available for home use. WEP and standard WPA can be cracked and are not considered secure.
In addition to enabling encryption, a very strong password should be used. This doesn’t need to be something ridiculously hard to remember, or so complex that you need to write it down. Remember, when it comes to password strength it’s all about entropy. So, the longer the password the better. This could be something as simple as a sentence with a few capital letters, spaces, and maybe one special character. This makes it very hard to guess but easy to remember, and if someone is able to capture the challenge-response, it will be very difficult for them to crack.
2. Change default router passwords and settings
Just do it… This is the very first thing that every penetration tester will try once connected to a wireless network. If they can log in to the administrative interface using a default or easily-guessable password, then all bets are off. The same goes for default settings. The fact that they are ‘default’ means that they are generally public knowledge and a quick google search will give an adversary everything they need to gain access to your network.
Aside from passwords — which should be changed for obvious reasons, the main setting of concern is the default IP address. This is normally 192.168.x.1 and various exploit kits are hard-coded to take advantage of these default configuration settings. Simply changing the IP address to anything else (IE: 10.112.123.111) will greatly improve the security of the router and subsequently, your home network as a whole.
One other setting that should not be overlooked is Wireless Protected Setup (WPS). This feature is prone to well-known and simple proximity attacks and can be broken very easily. When using WPS to configure devices such as printers or similar technology, it is best practice to enable WPS, add the device, and then disable WPS once the device has associated with the access point.
3. Set up a guest network for family and friends to use when they visit
Guest networks are a simple and effective way to segment your devices from potentially untrusted devices on the network. Sometimes a friends system can contain malware that could infect other systems over the network. Or, if you have guests regularly (think Air BnB) that connect to your network, do you really want them to be able to access your computer, servers, or other systems on your personal network? Another aspect to consider if you have ‘untrusted guests’ is to lock the router away to deter physical access attacks.
Many routers have a built-in guest feature. If yours doesn’t support this, you may want to consider purchasing another cheap router and bridge this off of your normal access point. This segments the network and keeps untrusted devices off of the main network. This could also be key if someone uses your guest network to download torrents or perform other illegal activities, as showing that this was conducted over your guest network by a device that you don’t own could get you out of hot water.
4. Set up a separate network for Internet of Things (IoT) devices
If you can control your lights from the internet, so can anyone else who happens to guess the password to your Internet of Things control center. What’s worse is that if they can get to your lights, what else can they access on your network? With the rise in home automation and remote access to physical devices, it is important to segment the network to reduce the risk of an outsider gaining access to the internal network by way of an exposed service.
5. Disable remote access to your home network
Many routers come with the ability to allow remote access. This can be very dangerous, especially if default passwords are still in place. Once someone gains access to the router remotely, they can sniff traffic and access systems on the internal network from anywhere in the world. Often these technologies are only protected by a username and password, which can be easily broken with a dictionary attack, often without the owner even knowing. This is why it is very important to only enable remote services when you can compensate for the risks by adding protections such as multifactor authentication.
The same precautions should be taken when running a demilitarized zone (DMZ) and exposing Windows or Linux servers to the internet. Unless it is absolutely necessary to access these systems directly from the internet, a VPN with multifactor authentication should be used instead. This will allow you to access your home network remotely in a more secure manner. If you are running a web server or something similar and need to have these services directly exposed, any remote administration protocols such as RDP or SSH should be protected using a public/private key pair in addition to the username/password combination.
6. Use a firewall
Firewalls are a cheap and effective way to curb attacks against your home network. Plus, they give you additional insight into the traffic that is traversing over the network boundary, in addition to maintaining a separate record of traffic history. Firewalls can also be implemented on the router directly, in fact most modern routers come with the built in ability to block specific ports or even filter specific types of traffic. A really good one that I would highly recommend is pfsense.
If you are exposing servers to the internet, Honeyports are a free and easy to use tool can be used to detect and ban IP addresses as attacks are observed. Artillery is one of my favorite tools for this and it can be installed on the server and up and running in minutes. This will prevent known-bad IP addresses from reaching your server once a connection attempt has been made against one of the exposed Honeyport services.
7. Log out of the router when not using it
Many of the attacks against routers today are done by forcing the client to perform an action within the administrative interface of the router on behalf of the attacker. This attack is commonly referred to as Cross-Site Request Forgery (CSRF) and is a very effective means of gaining access to a router. Some of the attacks simply enable remote access to the router and change the administrative password while others completely take over the device and backdoor it. For these reasons, it is important to always log out of the router’s web interface when you are done administering the services.
If you are currently running any Drupal 7 web applications, there is a very critical SQL Injection vulnerability affecting Drupal Core. This was publicly released on Wednesday, 10/15/14 along with an exploit. The proof of concept simply modifies the administrator’s username and password, allowing an attacker to gain administrative access to the Drupal application.
“Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks.
A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks.
This vulnerability can be exploited by anonymous users.”
The vulnerability is ranked as Highly Critical, a 5 out of 5 on the Drupal Security Team’s risk scale… A patch has been released and upgrading to Drupal Core version 7.32 will remediate this vulnerability. If you host Drupal sites, it is imperative that you patch soon. One quick way to test and see what sites have yet to be patched would be to make a simple bash loop to check all the known Drupal sites in your environment and see if any of them are still vulnerable.
Be very careful doing this, it will modify the admin’s password on every vulnerable site!
Even though this was only publicly released just a couple days ago, there is a chance that this vulnerability has been known for quite some time as it affects every Drupal 7 web application running version 7.31 or older. Luckily there are log traces of this attack that can be used to ascertain whether or not the vulnerability has been exploited.
The evidence in question lies within the Drupal Watchdog logs. Ideally this information should be extracted and stored in a SIEM or similar central logging solution. However, if you are only moving server logs off of the host then you are missing a good portion of the actionable evidence. Not to mention that once an attacker has gained access they can simply clear out the logs, erasing all remnants of the attack within the application.
If you are not offloading these logs to a SIEM and are lucky enough to still have Watchdog logs available following a breach, then you should search through these for the following four events in succession. Sometimes there will only be the first three (from bottom to top) as the attacker may wait to actually log in.
The details of the three messages to look for are:
- Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 478 of /var/www/redman/includes/unicode.inc).
- Warning: addcslashes() expects parameter 1 to be string, array given in DatabaseConnection->escapeLike() (line 981 of /var/www/redman/includes/database/database.inc).
- Login attempt failed for .
The nice thing about this attack is that the logs consistently provide us with valuable data, making it very easy to create a correlated events on a successful attack. So, if you are unsure of whether or not all of the Drupal 7 sites have been adequately patched, it’s a good idea to alert the SOC to successful attacks against any Drupal applications in the environment. Using LogRhythm this can be done with a simple correlated event rule block that looks for these messages in quick succession. I’ve included an example rule below that simply looks for this activity within the Watchdog logs. The first of which alerts on the message data from the first portion of the attack within Drupal 7 UDLA logs…
The second rule block looks for the next error message in the Watchdog database table…
And the third rule block looks for a failed login with a [ blank username ].
All of which is grouped by the same Impacted Host.
You could also add a rule looking for a successful login using the admin account. However they could change the admin’s username and may not even log in for quite some time following a successful attack. For this reason I did not include the fourth potential log message in the rule.
If you have a WAF that is tuned properly, this attack should be blocked. The LogRhythm Web Application Defense Module can assist with detecting this attack as well. Due to the popularity of this CMS, many organizations currently have a very large number of Drupal applications and often have little control over when they get patched. For this reason, it is beneficial to now when these applications are successfully compromised at the very least. Alerting on this activity will allow the security team to make a business case to get the sites patched in a reasonable amount of time as the only true way to fix this issue is to upgrade to Drupal 7.32 as soon as possible.
Tricking users into copying different commands from what is displayed on a web page…
OK, maybe I’m late to this party but I recently came across a very cool attack vector that I had not heard about until now. There’s an excellent write up on this here that was actually published in 2008, so I won’t go through the details of how this works. However you can view an interactive demo of this in action here.
Essentially, this is ruse that can be used to trick people into running a different command on their system than what they thought they had initially copied from a website. Go ahead and try it out over at JSFiddle.net, just copy the text within the ‘result’ box and paste it into a text editor to review the full command. Neat, huh?!
The demo above shows an attempt to shovel a reverse python shell back to the attackers system though make it appear like the command simply echoed “this is a test” to the screen as expected. This proof of concept is demonstrated below.
This is merely another vector that can be leveraged in social engineering attacks. Demonstrating the risk with blindly copying + running commands from websites that you do not trust. Always re-type commands such as this or paste them into a text-editor prior to running them directly. Also, if you are cloning a repository from a resource such as GitHub, review the code before integrating this into your project. All too often websites are backdoored due to the themes or modules that have been downloaded and installed from an un-trusted repository without going through code-review. In general, you shouldn’t implicitly trust anything at face value; trust but verify…