Monthly Archives: January 2017

NVD

CVE-2014-9754

The hardware VPN client in Viprinet MultichannelVPN Router 300 verison 2013070830/2013080900 does not validate the remote VPN endpoint identity (through the checking of the endpoint’s SSL key) before initiating the exchange, which allows an attacker to perform a Man in the Middle attack.

NVD

CVE-2014-9755

The hardware VPN client in Viprinet MultichannelVPN Router 300 verison 2013070830/2013080900 does not validate the remote VPN endpoint identity (through the checking of the endpoint’s SSL key) before initiating the exchange, which allows remote attackers to perform a replay attack.

Panda Security

It Isn’t Ransomware, But It Will Take Over Your Server Anyway

In this week’s Tales From Ransomware, we take a look at a ransomware that isn’t really ransomware. Nor even malware. But it can hijack your server anyway.

A few days ago we saw a typical Remote Desktop Protocol (RDP) attack, which lead us to believe that it was a similar attack to the one we told you about a few months ago which cybercriminals are using to infect devices with ransomware. But we were very wrong.

First of all because instead of encrypting data, it locks the desktop with a password that the victim doesn’t know. Secondly, it does not demand a ransom (!) in exchange for the credential, but rather seeks to keep the device locked for as long as possible so that it can be used for bitcoin mining for as long as possible. And thirdly, it doesn’t use malware as such.

Once they’ve gained access to your machine by brute force (this particular server was fielding 900 attempts daily) the attacker copies a file called BySH01.zip. This in turn contains:

  • BySH01.exe (executable through AutoIt)
  • 7za.exe (goodware, the well-known free tool 7zip)
  • tcping.exe (goodware, a tool for performing TCP pings)
  • MW_C.7z (a compressed password-protected file), which contains:
    • An application –goodware for bitcoin mining
    • An application –goodware for blocking the Windows desktop

The attacker runs the BySH01.exe file, and the following interface appears:

Кошелек – Wallet; Имя воркера – User Name; Количество ядер – Number of cores; Пароль – Password; Локация – Location; Пусть установки – Installation path; Расширения системы – Processor Extension; Порт – Port; Добавить в автозагрузку – Add to startup; Установить – Install; Удалить – Delete; Тест – Test; Пинг – Ping; Локер – Locker

With the help of our colleagues at Panda Russia, those of us who don’t know Russian can get an approximate idea of what its telling us with the above word list.

Basically, the bitcoin mining application uses this interface to configure how many cores to use, what extension of processor instructions to use, what “wallet” to send the bitcoins to, etc. Once the desired configuration is selected, the attacker clicks on Установить to install and run the bitcoins mining application. The application is called CryptoNight, which was designed for mining bitcoins using CPUs.

Then they click on Локер, which installs and runs the desktop lock application. It is the commercial application Desktop Lock Express 2, modified only so that the information shown in the properties of the file are the same as those of the system file svchost.exe. Finally it clears all the files used in the attack except CryptoNight and Desktop Lock Express 2.

Desktop Lock Express 2, the application used by the attackers.

We detected and blocked several attacks in different countries. Examples such as this one show how, once again, cybercriminals take advantage of weak passwords that can be guessed using the brute force method over a given period of time. Malware is no longer necessary to gain access to the system, so it’s up to you to use a robust password that will keep out unwanted visitors.

Tips for the System Admin

In addition to using a solution like Adaptive Defense, which detects and prevents this kind of attack, a couple of tidbits of advice for all administrators who have to have an open RDP:

  • Configure it to use a non-standard port. What 99.99% of cybercriminals do is track all Internet on TCP and UDP ports 3389. They might bother to track others, but they do not have to, since most do not change these ports. Those who do change ports do so because they are careful about security, which probably means that their credentials are already complex enough to not be gotten by brute force within any reasonable amount of time.
  • Monitor failed RDP connection attempts. Brute force attacks can easily be identified in this way, since they use automated systems and can be seen making a new attempt every few seconds.

The post It Isn’t Ransomware, But It Will Take Over Your Server Anyway appeared first on Panda Security Mediacenter.

Panda Security

What You Need To Know About The iMessage Security Flaw

With everything that’s gone down in 2016 it’s easy to forget Tim Cook’s and Apple’s battle with the FBI over data encryption laws. Apple took a strong stance though, and other tech giants followed suite leading to a victory of sorts for (the little guy in) online privacy. In this era of web exposure, it was a step in the right direction for those who feel our online identities are increasingly vulnerable on the web.

All of this stands for little though when a security flaw in your operating system allows carefully encrypted messages to be effectively decrypted offline. That’s what happened to Apple with its iOS 9.2 operating system. Though the patches that ensued largely fixed the problem, the whole issue has understandably left iOS users with questions. What really happened and are we at immediate risk?

What Is The iMessage Security Flaw?

A paper released in March by researchers at John Hopkins University exposed weaknesses in Apple’s iMessage encryption protocol. It was found that a determined hacker could intercept the encrypted messages between two iPhones and reveal the 64-digit key used to decrypt the messages.

As iMessage doesn’t use a Message Authentication Code (MAC) or authenticated encryption scheme, it’s possible for the raw encryption stream, or “ciphertext” to be tampered with. iMessage instead, uses an ECDSA signature which simulates the functionality. It’s still no easy feat exploiting the security flaw detailed by the researchers. The attacker would ultimately have to predict or know parts of the message they are decrypting in order to substitute these parts in the ciphertext.

Using this method, a hacker can gradually figure out the contents of a message by replacing words. If they figure out, for example, that they have successfully replaced the word “house” in the message for “flat” they know the message contains the word “house”. Knowing whether the substitution has been successful though, is a whole other process which may only be possible with attachment messages.

It may sound simple, but it really isn’t. The full details of the security flaw, and the complex way it can be exploited are detailed in the John Hopkins paper.
The paper includes the recommendation that, in the long run, “Apple should replace the entirety of iMessage with a messaging system that has been properly designed and formally verified.”

Are iMessage Users At Immediate Risk?

Despite the recommendation, the answer is no. It is very unlikely. One thing that should be made clear is that these weaknesses were exposed as a result of months of investigation by an expert team of cryptologists. The type of hacker that would take advantage of these weaknesses would undeniably be a sophisticated attacker. That of course doesn’t mean that Apple shouldn’t take great measures to eradicate this vulnerability in their system.

Your messages, though, are not immediately at risk of being decrypted, and much less if you’ve installed the patches that came with iOS 9.3 and OS X 10.11.4 (though they don’t completely fix the problem). Tellingly, the flaws can’t be used to exploit numerous devices at the same time. As already mentioned, the process that was exposed by the John Hopskins paper is incredibly complex and relies on various steps that are by no means easy to complete successfully.

All of this means that it would take a very sophisticated attacker a complex and lengthy process (up to and beyond 70 hours) to decrypt one message. iMessage has a supported base of nearly one billion devices and handles more than 200,000 encrypted messages per second. We’ll let you do the math there but it seems highly unlikely that a hacker would try to exploit this weakness unless they’re trying to uncover very sensitive and important data.

A hacker would most likely carefully vet their target as someone who possesses valuable information that could then be contained within that person’s messages. If a hacker’s investing 70 hours of their time to uncover cat pics, the joke’s really on them.

Could this have any connection with the FBI encryption dispute?

Matthew D. Green, the well-known cryptographer and leader of the John Hopkins research team, has spoken with the Washington Post about the implications of his team’s research. “Even Apple, with all their skills -and they have terrific cryptographers- wasn’t able to quite get this right. So it scares me that we’re having this conversation about adding back doors to encryption when we can’t even get basic encryption right.”

So you’d probably need the resources of say, the FBI, to pull off an attack exploiting the vulnerability exposed in the John Hopkins paper. It seems very unlikely that individuals would be targeted en masse. 2016 has been such a surreal year though, who are we to say what is and isn’t possible?

The post What You Need To Know About The iMessage Security Flaw appeared first on Panda Security Mediacenter.

NVD

CVE-2017-5541 (symphony_cms)

Directory traversal vulnerability in template/usererror.missing_extension.php in Symphony CMS before 2.6.10 allows remote attackers to rename arbitrary files via a .. (dot dot) in the existing-folder and new-folder parameters.