MSI is proud to announce the immediate availability of the HoneyPoint Console version 4.0!
The new version of the Console for HPSS is now available for Windows, Linux and Mac OS X. In addition to the Console, new installer tools and documentation is also available.
The new Console finally includes operation as a service/daemon WITHOUT the need to have the GUI running. That’s right, finally headless consoles that work immediately with SEIM and other monitoring tools. Configuration of the Console and management is still available through the GUI, but headless operation is now at the core of the Console product line!
Other improvements include bug fixes, increased error handling, better memory management, improved installers and installation tools and much much more. If you haven’t upgraded your Console or seen the new 4.0 Console yet, we think you will find it much improved.
To obtain the new Console, refer to your QuickStart Guide. It is now available through the HoneyPoint distribution site. No changes to the database or license key are required, however, you must have a current license to qualify for the upgrade. Please back up your Console databases prior to upgrading, though we have experienced no issues with the upgrade process.
Thanks, as always, for choosing HoneyPoint Security Server and MSI. We value your partnership and trust.
Where do most of the threats to the security of our IT systems lurk? The Internet, of course! Powerful malicious software apps are all over the Net, like website land mines, just waiting to explode into your computer if you touch them. And how about accessing social networks from your company work station? Do you really think that content on these sites is secured and only available to those you chose to see it? If so, then I’m sorry to disillusion you.
So why do most concerns still let their employees casually access and surf the Web from their business systems? Especially in the present when most everyone has a smart phone or pad with them at all times? Businesses should embrace this situation and use it to their advantage. Why not set up an employee wireless network with all the appropriate security measures in place just for Internet access? (This network should be totally separate from business networks and not accessible by business computers). It’s not expensive or difficult to administer and maintain a network like this, and employees could access websites to their hearts content (on their off time of course). And for those employees that are without a smart phone (an ever dwindling few), you could stand up a few kiosk computers that they could access using their employee wireless network password.
As for employees that need Internet access to perform their work duties, you should lock their access down tight. The best thing to do is to add needed websites to a white list and only allow those employees with a business need to access only those websites that are necessary and no others. Black listing and web filtering are partially effective, but they don’t really work well enough. I can’t tell you how often we have seen such filters in place at businesses that we assess that prevent access to gaming and porn sites, but still allow access to traps like known malicious websites in foreign countries! Go figure.
And don’t forget to properly segment your business networks. Users should only be allowed access to those network resources that they need for business purposes. Users in workstation space should never be allowed to “see” into server space. Preventing this will go a long way in curtailing attacks from the other big danger – the malicious insider.
Thanks to John Davis for writing this post.
By now most of you have likely heard of the recently announced coding error in some versions OPENSSL that can expose sensitive information stored in memory to any Internet attacker. I want to take a moment to consolidate some of the things I’ve learned about it over the last week and provide my – hopefully correct – answers to some of the questions I’ve been asked. I’ve placed a companion audio commentary here.
1) It’s real – and serious. Blocks of memory data can be retrieved by anyone.
Below is a snapshot of what an exploit of an actual vulnerable Internet-facing system revealed to me – simply by connecting to to the site and taking advantage of the vulnerability (no login/password or other credentials required).
That “PHPSESSID” string is associated with a “session id” – a string established to indicate the associated user is logged in. By collecting enough memory you can obtain the full session id of the logged in user. You then insert it in your own browser environment, point your browser at the site, and potentially “hijack” the session. You are now logged in as that user. Anything stored in memory is potentially retrievable as a result of this vulnerability – including login credentials and private keys.
2) What IS OPENSSL itself?
Quoting from the OPENSSL project site:
“The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library”
For a lot of the sites you have logged into over the last few years, its what is making the “s” ( for “secure”) in https://<yourbankingsite.com> possible.
Software applications can use OPENSSL to ensure that the connection between your browser and the website is encrypted. It’s used for more than just that – but that usage is the one most people have direct experience with. Whenever an application needs to communicate over an encrypted path, affected versions of OPENSSL may be in play. Think FTPS (encrypted FTP), SMTPS (encrypted mail), etc.
If yours is a large and diverse organization, the affected versions of OPENSSL are almost certainly present.
3) Only specific versions of OPENSSL are affected
From the OPENSSL project sites advisory:
“Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.”
4) A fairly large number of systems are affected – 17% of Internet sites.
Internet web-sites using open-source web servers like Apache and such can be affected. That is what I have primarily seen on the Internet. Windows systems are less likely to directly affected – but could be indirectly affected if an intervening web proxy that handles the SSL part is between the attacker an the Windows server.
But note this: Client systems can also be affected. And by “client” I mean your PC or smart-phone or your internal applications that communicate out to third-party systems via SSL (e.g https ). Any of these that use affected versions of OPENSSL may be affected. See: http://www.theregister.co.uk/2014/04/10/many_clientside_vulns_in_heartbleed_says_sans/
5) What’s actually happening?
The affected versions of OPENSSL have a piece of functionality called “Heartbeat”. The intent was to allow two systems that have established a secure SSL-based connection to maintain an awareness of one another during the connection. An “are you there?” heartbeat request can be initiated by either side of the connection to ensure the other side is still up. Blocks of of data are sent back and forth during the process. As a result of a coding error in the implementation of the heartbeat check, one side or the other of the connection can specify a larger block than they actually send. The coding error causes the responder to reply back with a block as large as what the requester claimed. So: I’ll claim to send you 64K bytes of data as part of the heartbeat but only actually send 1byte. You’ll send me back 64K bytes. The first byte is what I sent you – the remaining 64K bytes are random portions of YOUR memory – stuff I should never see. That’s what you are seeing in the image that starts this post.
Here’s an amusing cartoon that explains it nicely: http://xkcd.com/1354/
Note that either side of the “secure” connection can play this game. Attackers can harvest memory from vulnerable servers, and malicious servers can harvest memory from clients.
6) What do I do?
The vulnerability was just recently disclosed – but its been in place for 2 years!. You must assume that it has been exploited by attackers for at least months and – worst case – for 2 years. Not good. Even sites that are fixed now may have had the flaw – and been exploited – during that period.
For general users:
- Check to see if the “sensitive” sites you login into are patched. But remember that just because a site is OK now does not mean it was 6 months ago. Here are some testing sites:
- For sites that have patched, change your passwords now. They may have been stolen. No panic – just get it done over the next week or so.
- Do not use the same login and password on sensitive sites as you use for “throwaway” sites. This is a common mistake. Attackers will check to see if that password you use for trivial sites is the same as the one you use for banking.
- Make sure your mobile devices ( Android-based systems in particular) are patched.
- As with every “Internet event” – watch out for phishing campaigns that attempt you to get to download “fixes” for the problem or encourage you to visit unknown “https” sites. Attackers will attempt to capitalize on fear and confusion.
For developers and system administrators:
- All: Look for the presence of the vulnerable versions of OPENSSL in your environment and in any business partner environment that your application connects to. Anywhere you rely on SSL-based encryption for security inbound OR outbound. Make sure that your business partners are on top of this. They may need to issue new certificates after they patch affected systems.
- Check to see if you are using a vulnerable version of OPENSSL in your code. If so, move to a safe version or recompile with “-DOPENSSL_NO_HEARTBEATS” . Then DEPLOY!
- Both nmap and Nessus have reliable tests for the vulnerability. Use these tests now to root out all instances of the vulnerability. Scan ALL ports, not just TCP 443. Start with your Internet perimeter and all your business partner and customer-exposed systems first – then inside. Upgrade OPENSSL or at least disable the heartbeat check on all affected systems.
- For systems that are exposed to the Internet that were affected, install new certificates. The potential for the compromise of the private key portion of your certificates is real – and could have happened some time ago.
- Ask your business partners what they are doing. Make sure they are aware and are acting.
- See if your load balancers or web proxies can help. If you use such devices to terminate SSL at your boundary, they can potentially be used to protect against incoming Heartbleed attacks. Talk to your vendor!
Microsolved has the ability to quickly examine your environment for the presence of Heartbleed and a host of other problems common to our brave new digital word. If you need help, we can be there for you.
Additional sources of information:
Now that Windows XP is end-of-lifed, it is wise to replace it at home and in businesses of all sizes. Malware and vulnerabilities for XP are likely to skyrocket over the coming months, making it a very unsafe platform, indeed.
To help with replacement, we at MSI went shopping for some deals on Windows 7 and Windows 8 for you. Here are the deals we found on newer Windows software. Please note, we have no affiliation with any of these vendors and can’t recommend them in particular. We simply found the best prices we could identify for Windows OS. Your milage and paranoia may vary.
Here are the deals we could find:
For one PC license of Windows 7 Pro for as low as $69.99.
If you need more than one, the lowest is $219.99.
For Windows 8 Pro – $79.94 for single computer use.
The price is $199.99 for multiple computer to use Windows 8 Pro.
We hope that helps some of you who still need to upgrade. Until next time, thanks for reading & stay safe out there!
Just a reminder that #CMHSecLunch is Monday, 4/14/14 from 11:30 to 1 at the North Market.
Come out and hang with friends, both old and new. The whole gang will be there, so spend some time.
Hope to see you there. Bring a buddy or at least a smile! 🙂
If you use OpenSSL anywhere, or use a product that does (and that’s a LOT of products), you need to understand that a critical vulnerability has been released, along with a variety of tools and exploit code to take advantage of the issue.
The attack allows an attacker to remotely tamper with OpenSSL implementations to dump PLAIN TEXT secrets, passwords, encryption keys, certificates, etc. They can then use this information against you.
THIS IS A SERIOUS ISSUE. Literally, and without exaggeration, the early estimates on this issue are that 90%+ of major web sites and software packages using OpenSSL as a base are vulnerable. This includes HTTPS implementations, many mail server implementations, chat systems, ICS/SCADA devices, SSL VPNs, many embedded devices, etc. The lifetime of this issue is likely to be long and miserable.
Those things that can be patched and upgraded should be done as quickly as possible. Vendors are working on patching their implementations and products, so a lot of updates and patches will be forthcoming in the next few days to weeks. For many sites, patching has already begun, and you might notice a lot of new certificates for sites around the web.
Our best advice at this point is to patch your stuff as quickly as possible. It is also advisable to change any passwords, certificates or credentials that may have been impacted – including on personal sites like banking, forums, Twitter, Facebook, etc. If you aren’t using unique passwords for every site along with a password vault, now is the time to step up. Additionally, this is a good time to implement or enable multi-factor authentication for all accounts where it is possible. These steps will help minimize future attacks and compromises, including fall out from this vulnerability.
Please, socialize this message. All Internet users need to be aware of the problem and the mitigations needed, even for personal safety online.
As always, thanks for reading, and if you have any questions about the issues, please let us know. We are here to help!
One of the SANS topics discussed in March and early April caught my attention recently:
Quote from the link:
“Update:Just found what looks like a bitcoin miner on the infected DVR. There are two more binaries. D72BNr, the bitcoin miner (according to the usage info based on strings) and mzkk8g, which looks like a simplar http agent, maybe to download additional tools easily (similar to curl/wget which isn’t installed on this DVR by default). I will add these two files to https://isc.sans.edu/diaryimages/hikvision.zip shortly.
Last week, we reported that some of the hosts scanning for port 5000 are DVRs (to be more precise: Hikvision DVRs, commonly used to record video from surveillance cameras  ).”
Basically what is claimed is that compromised video equipment (HIKVISION) is scanning TCP 5000 looking for network attached storage devices (SYNOLOGY) that have a flaw: http://www.scip.ch/en/?vuldb.10255
And also – that the compromised video equipment has had bitcoin mining software installed. Nice touch.
I have an Internet-facing honeypoint listening on TCP 5000 – I did it out of curiosity.
Got this within 30 minutes
satori received an alert from 177.206.XXX.XXX at 2014-03-31 18:18:45 on port 5000 Alert Data: GET /webman/info.cgi?host= HTTP/1.0 Host: 71.XXX.XXX.XXX:5000 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Content-Type: application/x-www-form-urlencoded Content-Length: 0
Then I took a look at: 177.206.XXX.XXX ( IP is in Brazil )
PORT STATE SERVICE
21/tcp open ftp
23/tcp open telnet
443/tcp open https
554/tcp open rtsp
990/tcp open ftps
8001/tcp open vcom-tunnel
Screenshot of the site – below:
Here is the html source for the page:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″>
<link rel=”stylesheet” href=”../css/base.css” type=”text/css” />
<link rel=”stylesheet” href=”../css/login.css” type=”text/css” />
<select id=”LanguageSelect” name=”LanguageSelect” onchange=”changeFrameLanguage(this.value)”></select>
<label id=”lausername” name=”lausername”></label>
<input type=”text” id=”loginUserName” maxlength=”16″ />
<label id=”lapassword” name=”lapassword”></label>
<input type=”Password” id=”loginPassword” maxlength=”16″ />
<span onclick=”doLogin()” onmousemove=”this.className=’loginbtnon'” onmouseout=”this.className=’loginbtn'”>
<label id=”lalogin” name=”lalogin” ></label>
<label name=”laCopyRight”>©Hikvision Digital Technology Co., Ltd. All Rights Reserved.</label>
Bingo – so I have a confirmed case of compromised video equipment in Brazil scanning my home Internet IP for a vulnerability affecting NAS storage devices.
Small world, no?
This was genuinely fun for me as it allowed me to take an interesting but somewhat remote piece of the constant security news-stream and render it immediate and real – that was MY IP being scanned.
BTW: Does your organization have video equipment with exposed interfaces on YOUR Internet perimeter? Many of you do… and don’t know it.
“Things have always been done this way.” —> Doesn’t mean they will be done that way in the future, or even that this is a good way.
“We know we need to change, but we can’t find the person who can authorize the changes we need.” —> Then who will punish you for the change? Even if punishment comes, you still win, as you’ll know who can authorize the change in the future.
“We don’t have enough time, money or skills to support those controls, even though we agree they are necessary.” —>Have you communicated this to upper management? If not, why not? How high have you gone? Go higher. Try harder.
“That’s too fast for our organization, we can’t adapt that quickly.” —>Welcome to the data age. Attackers are moving faster that ever before. You better adapt or your lack of speed WILL get exploited.
In many of my clients, complexity and bureaucracy have become self re-enforcing regimes. They lean on them as a way of life. They build even more complexity around them and then prop that up with layers and layers of bureaucracy. Every change, every control, every security enhancement or even changes to make existing tools rational and effective, is met with an intense mechanism of paperwork, meetings, “socialization” and bureaucratic approvals.
While many organizations decry “change management” and “security maturity” as being at the core of these processes, the truth is, more often than not, complexity for the sake of bureaucracy. Here’s the sad part, attackers don’t face these issues. They have a direct value proposition: steal more, get better at stealing and make more money. The loop is fast and tight. It is self correcting, rapid and efficient.
So, go ahead and hold that meeting. Fill out that paperwork. Force your technical security people into more and more bureaucracy. Build on complexity. Feed the beast.
Just know, that out there in the world, the bad guys don’t have the same constraints.
I’m not against change controls, responsibility or accountability, at all. However, what I see more and more of today, are those principals gone wild. Feedback loops to the extreme. Layers and layers of mechanisms for “no”. All of that complexity and bureaucracy comes at a cost. I fear, that in the future, even more so than today, that cost will be even more damage to our data-centric systems and processes. The bad guys know how to be agile. They WILL use that agility to their advantage. Mark my words…