Planet Zuda Information Security

Progressive Insurance sells a device called Snapshot that is advertised as “This little device turns your safe driving into savings“, which sounds great at first glance. What most don’t know is that the company who makes snapshot is called Xirgo Technologies and they are hacked. We’ve tried calling Xirgo Technologies several times and emailed them about xirgotech dot com being hacked since June 22nd, 2015 but have yet to hear back from them nor have they cleaned up the hack. When we called Xirgo Technologies we always went to a voicemail and never spoke to a person. Does Xirgo Technologies believe that their site being hacked is supposed to make  Progressive customers and their other customers feel confident about this manufacturers ability to make  devices that are put into  cars?  Unfortunately, the only response we got from Xirgo Technologies was on June 22nd and it was an automated email from their sales account that said  “Dear Ryan Satterfield, Thank you for your note! We will get back to you as soon as possible.”

Earlier this year researcher Corey Thuen exposed some #security issues in the #SnapShot dongle by Progressive Insurance that connects into your OBD2 in your car. We contacted   Mr. Thuen on Twitter who said he hasn’t done any research on Xirgo Technologies Snapshot dongle since around February. We noticed a tweet by Mr. Thuen referencing the Xirgo Technology website hack that he posted on May 5th, 2015, which is before we discovered the hack and contacted the the company.  https://twitter.com/CoreyThuen/status/595716845438631936 

January 23, 2015 by Planet Zuda  

This guide is all about PayPal Two Factor Authentication and how to set it up. We don’t usually write guides like this, but due to the vulnerability in paypal we find it necessary to do so.

Step 1:  you need to do is log in to PayPal. Step 2: Once you’re logged in you need to click on the button of the little person at the right hand corner of the screen next to the log out button. The below screenshot shows you the button to push. If you want to skip to step 4 just go to https://www.paypal.com/us/cgi-bin/webscr?cmd=_profile-phone

Step 3: Click on the settings button, which is a gear and then click update phone number.

Step 4: Now you need to hit the add button to add your phone number and once you add it you need to ht the link that says link.

Step 5: go to https://www.paypal.com/us/cgi-bin/webscr?cmd=_mobile-registration and check the box that says you confirm that you are authorized to add this number and then hit continue. You can view the screenshot below Step 6: Now you need to enter the code sent to your phone on the page presented to you.

Step 7: this is an optional step that lets you replace your password with a pin.

There is another option called  the PayPal one time key, which is a physical device that costs $29.99 you may learn more about it at the PayPal page. When this is in use the vulnerability that is currently present will be stopped. Katrina Moody tested this for us using her physical key and received a recaptcha challenge and then was requested to enter her key that was texted to her phone.

Written on September 13, 2014

WordFence, a #WordPress plugin was vulnerable to being hacked by stored XSS prior to the plugin version 5.2.3. A researcher went public about discovering a WordFence exploit  which allows stored XSS in  the live traffic feature. Since the person published the security issues they were  resolved extremely quickly, unlike those who try to solve issues privately with most developers.

Does this only affect WordFence 5.2.2?

Any site using an old version of WordFence with live traffic on is most likely  vulnerable. We haven’t checked all the WordFence versions with live traffic.  While we have explained the issue, we do know that this  topic is very hard to understand, so we have taken the time to write a very simple explanation about it.

The issue in WordFence 5.2.2 allows criminals to add code into your site, so the site will do whatever they want it to do  when someone visits your website. That’s the easiest way to explain stored XSS.

What is the technical version of stored XSS?

Stored XSS, also known as cross site scripting, allows a hacker to inject code into  your  server, usually in the database. The only way to remove stored XSS is manually going into the database and deleting it. You will need to do this if someone hacks your outdated WordFence plugin.

WordFence, a #WordPressplugin for securithad an exploit prior to WordFence 5.2.2 and that issue was fixed very quickly. Another full disclosure was made about WordFence #security, which has lead to WordFence 5.2.4 being released. It is extremely important to update your WordFence plugin right away. The issues found are a stored XSS in the live IP detection page, another XSS hole was fixed which didn’t affect a lot of sites, they improved revolution slider exploit protection, and help prevent fake google-bot hacking attempts.  The developer of WordFence was extremely quick in responding to the security reports that were made public and we believe he would respond quickly to them even if they weren’t public.

Is WordFence safe to use?

While this may sound odd to a lot of our readers the more security holes found in any program and that are patched in a timely fashion, the more secure the program is. Finding security holes helps makes the program even better that is if the company fixes the security holes quickly. Hackers know how to read code and will look for any security hole they can to hack a plugin, so the more security holes that are found and are fixed, the better. Just because a plugin hasn’t had any security holes talked about publicly does not mean it is secure. An argument some people may bring up is that programs shouldn’t have security holes, unfortunately we’ve never seen any code that is 100 percent secure. The fact that security holes get fixed in a timely fashion is great and should make customers more confident with the WordFence security plugin.

WPTouch version 3.4.9 is a very nice #WordPress plugin had an open redirect vulnerability with their foundation framework. The easiest way to explain an open-redirect is that a malicious actor can make the link go somewhere else, like a malicious site. If you’d like another source, you can read what OWASP wrote about this.

The open redirect  only affected logged in users, whether you were a subscriber or any other role. The issue occured with the logout url in their foundation framework support for comments.  WPTouch promptly responded to  our report and released WPTouch 3.4.10 very quickly. We encourage more companies to be like WPTouch and react to security reports the second they hear about them.

What can I do about the WPtouch 3.4.9 vulnerability?

We contacted the MailPoet team about security holes in  MailPoet 2.6.11 and they were extremely professional, polite, and patient. Their team is as professional as the Google security team, which we’ve assisted before. We aren’t going to list all of the security holes in mailpoet 2.6.11, but one of them was stored XSS, though you had to be logged in to trigger it. If you don’t know what stored XSS is, it is xss that is saved to the database and then executed when the code is called.

If you don’t know what the WordPress MailPoet plugin is, it is a WordPress newsletter plugin. If you aren’t familiar with WordPress, it is an open-source CMS.

So am I supposed to update My WordPress MailPoet plugin to improve security?

Yes, you need to update your mailpoet plugin. The MailPoet team is always improving their software making it safer to use, so it is important to keep up with the updates. It is important to note that no piece of software is 100 percent secure. People should be impressed by companies like MailPoet who quickly fix security issues, not upset that bugs existed. The companies that quickly fix issues are the products you want to keep using and tell others to use.

W3 Total Cache Security Update — update with XSS attack

December 12, 2014 by Planet Zuda

W3 Total Cache 0.9.4.1 is a #wordpress plugin security update. If you aren’t aware what W3 Total Cache is, it is a caching plugin for WordPress. Caching helps speed up your sites. One of the issues which has been made public by another researcher is broken security in the WordPress nonces. Most plugins accidentally create numbers used once, also known as  nonces that are insecure, because of the way WordPress core works. If you use a function called wp_create_nonce(), it makes a broken nonce unless you also use the function wp_verify_nonce to try and make sure the nonce is valid. This is what was discovered and written about on WPScan.

Unfortunately, there was a misunderstanding that caused a delay in   the release. W3 Total Cache made the best patch possible, so this problem will not occur again in their plugin. Their design of stopping the issue was creative and did fix the issue.  It would be best if researchers followed nahamsec.com’s advice on how to treat companies even if you didn’t use to act the way listed, you should try and change your behavior.

Healthcare.gov, the United States healthcare portal by the government was a security disaster last year when we reviewed it. We then consulted the government on the security of healthcare.gov the following week. We reviewed their code again, at least the client side code that you can see without logging in and all the security holes we reported have been fixed. Everything has been rewritten changing the code from being a disaster to a site that takes their client side code security seriously. Please note this review is solely based on what we’ve seen without being logged in, however at the beginning of the year we didn’t have to log in to be able to see what others saw when they logged in. That issue has also been solved.

We are not saying healthcare.gov has no security holes, we just didn’t see any, partially because a lot of the programming has been switched to server side and we didn’t test the new code.  We have a copy of how healthcare.gov looked last year  and from a programming perspective it is an entirely new site. Healthcare.gov is not the only site which we’ve helped have such a dramatic security overhaul, we just don’t talk about most of our work since some  customers request privacy.

December 29, 2014 by Planet Zuda

We find security bugs all the time and have to write proof of concepts.   Unfortunately, we struggled with being able to make a  really good proof of concept for each bug. After a lot of work and help from bugcrowd, we are able to write detailed proof of concepts, which have a higher chance of getting the results you want and some places even pay more if you provide a good proof of concept.

So how do I write a good proof of concept?

Solving a  murder mystery and writing a proof of concept for information security aren’t that different. Every murder mystery has to solve five questions who, what, when, where, why and how. A good proof of concept has to answer those same questions.

Let’s talk about a fictitious program called example. You were testing example and found  persistent XSS. Now you need to report the issues in example to a large company. You may run into the problem of thinking that the person reading the letter understands security or understands what you’re trying to explain. This isn’t usually true. Here is an example of a bad proof of concept.

The product example has a persistent XSS due to a broken regex. Please fix this immediately.

That is a very, very bad  proof of concept but you don’t know it. So how do you write a good proof of concept? You have to think who the issue will affect, what it affects, when it will affect it, and why it is an issue. When you are explaining why you need to explain the impact, because just saying there is a  security hole isn’t enough. Using a tool like the CVSS calculator and then giving the company the score from 0 to 10 and how exploitable it is on 0 to 10 helps them understand the impact the issue has on their product.

Here is an example of a good proof of concept for the fictitious program called example that accepts credit cards and comments on products. Please note that we aren’t adding in any exploit code, but in a proof of concept you have to do that.

Step 1: Download example at http://example.com

Step 2: Installed the latest version of  example 0.0.1 using PHP 5.4.31 and MySQL version 5.6.22  running  CentOS  version 6.6. Step 3: The malicious actor must sign up for a normal account, which anyone can sign up for.

Step 4: Once signed up the malicious actor can post a comment and put the persistent xss in the parameter comment at https://example.com/comments/comment.php?comment=persistent_XSS_code

Step 5: Once the XSS code has been added as a comment anyone who views the page will execute the XSS. Once the XSS is executed it can lead to a full deface, redirect your users to another site or use your site to phish users information. According to the CVSS calculator this has an impact of 7.4 out of 10 and an exploit factor of 8.0 out of 10.0.

Step 6: The Persistent XSS can be fixed by using fake_function() for sanitation against code being executed or injected into the database.

Step 7: The persistent XSS issue occurs despite what PHP version, mysql version or operating system you are using.  

A  user is not supposed to have these types of permissions. We hope this can be fixed. Thank you for your time.

In the above proof of concept you’ve outline what can be affected, which is the product example. You’ve outlined why it can be affected by persistent XSS, where it is affected,  who it affects and how the product is affected. You must remember that the person getting the email most likely has a lot of reports to go through, so thanking them for their time is the least you can do.

This is the type of report companies want to get, because they don’t have to figure out the impact and since you already did the work you can help them out by explaining everything. They will most likely really appreciate this.

January 5, 2015 by Planet Zuda  >

WordPress Plugin SEO  Friendly Images 3.0.4 had over a million downloads and was trending, so we quickly took a look at it to see it suffered from two security issues. We’re happy to say that the security issues  have been fixed thanks to our help and the plugin developer Vladimir Prelovac who is the founder of the web hosting company ManageWP. He  quickly released patches for the issues. Unfortunately, when these two security issues were chained together you could run malicious code on the site, redirect the admin to another site, etc.  

SEO Friendly Images is a plugin to make images search engine friendly and while this is great, the developer forgot to make sure all forms had proper CSRF protection and the plugin was vulnerable to persistent   XSS on the admin side which we were able to exploit without being logged in due to the CSRF issue.

Persistent XSS is different then reflected XSS, because persistent XSS is stored in the database and doesn’t go away until someone goes into the database and removes the malicious code. Due  to the CSRF issue, malicous actors could trick a logged in admin into clicking links that would execute XSS as shown above.

As you can tell there are some prerequisites to exploit this, so it only has an overall CVSS  score of 5.2 out of 10  and the exploit score is 6.8 out of 10. This means that while it is pretty easy to exploit, you have to get someone logged in as an admin to their site to click a link or another action for the attack to work.

Fastmail.fm is a paid email service that runs a bug bounty.

Fastmail like any modern email service allows their users to send attachments, including images. Unfortunately they believe that their users should be allowed to upload and send  images that contain malicious code in the exif data to anyone on the web. EXIF data is the part of an image that says how quickly a shuttter closed, sometimes has the GPS coordinates, a section for comments and other information you usually don’t see. Unfortunately, you can also put malicious code in the EXIF data that will execute.

Most modern email services like gmail remove malicious code from the exif data in images or stops you from uploading images that contain malicious code. This is something  we pointed out to Fastmail and their response didn’t make a lot of sense. They changed the subject  from talking about images with malicious code in the exif data and started discussing on how they shouldn’t modify users  PGP(Pretty Good Privacy) signatures, which is part of making emails encrypted. You should never modify PGP signatures, but we were talking about malicious images, not encryption. Fastmail finally said removing malicious code would be nice, but this wasn’t their job. We did some research and found that the National Institute of Standards And Technology had a  PDF on Web hosts liabilities for malicious content which made it quite clear that this is an extremely grey area in law.

By the time we ended our discussion with FastMail they had made their point on the subject  very clear, including a link to a site saying Two Factor Authentication is cooler then Disco. They sent us to that site, because they believe trying to stop malicious code is “usual silliness in security enumerating badness“. If you haven’t heard the term enumerating badness before, it simply means not to try and stop bad code, because someone may get past your security measures. We don’t agree with this logic.

Note: This was fixed in 3.7.1 this article is being moved over to Tumblr. WpBook is a WordPress plugin by John Eckman who is the CEO of 10up. WPbook has had over 162,000 downloads and helps people connect to Facebook. When we tested WPBook version 3.7 we found a security hole in less then a minute, but before we get to the security hole you need to understand how this plugin works. The plugin let’s you connect to Facebook by adding in your own facebook app. In order to do this you are supposed to have access to the admin panel and can then only enter a FaceBook app ID to connect to, so how could anything go wrong if you need to be logged in to see it? Unfortunately, the plugin had no protection to keep intruders from editing the backend where you update the FaceBook app connection, secret key, etc. due to a vulnerability called Cross Site Request Forgery.

Most people wouldn’t realize what type of harm could be done by being able to change this information, except disconnecting the site from FaceBook.  Unfortunately, that isn’t all you can do. You can also add in your own app that you have control of to any remote site that you shouldn’t have access too. Now your app is hooked into their site. There are plenty of issues one could do with this exploit.

It is important to note that this vulnerability can only be exploited if a user clicks a link, comment, views a malicious image, etc that changes the facebook connection information.

Is WPBook still vulnerable to this exploit?

Thankfully when we contacted Mr. Eckman he pushed a fix the next day patching the issue for anyone who updated to WPBook 3.7.1 and was very nice to give us credit in the changelog. Will this vulnerability be exploited? Our theory is that every vulnerability is already known by someone, so it was most likely exploited before we found it. We are happy one security hole was fixed in WPBook, however we aren’t saying it has no security holes. In reality, everything has security holes some are just more exotic then others.

How do I fix the WPBook security hole?

To fix this particular security hole you need to update to WPBook 3.7.1 right away.