Unpack the Junk instead of Opening it

Today I learned a new and awesome trick for unpacking javascript that is found in packet captures. I have pasted the method below from the original site, along with the link to the author's posting. In short, this is an invaluable tool and makes me love Firefox even more!

Update: This technique can also be used to deobfuscate Yahoo Counters.

[Copied text]
Without any intro – crap that I usually write explaining why I had to write this post, I’m going for the subject. You(general junta or web developers or scared security guys) might see some eval packed javascript which phishing idiots ask you to copy paste on your URL bar and hit enter key.
Unpacking JS is a PITA was an answer that my brain use to give whenever I think about it. Just now, I found a very easy method to convert it into readable Javascript without any extra tool (IE boys, run away) Its very simple in FF or Opera.
FF guys, all you need to do is …
Copy the eval packed JS. something like —- eval(function(p,a,c,k,e,d){e=function(c) …………………. }
Open Error Console on your firefox
Paste the packed JS in Code input tab
Add eval = alert; at the beginning of the code
Hit Evaluate
You will get the proper javascript for the packed javascript. Copy paste it into any code prettifier. It will become perfectly readable. Opera folks, follow this. Packed JS is a huge asset for Phishing as who would have expected that packed JS in this code will make you join around 26 communities and send some stupid message to all your friends without your knowledge as soon as you copy paste some JS code on your URL bar and hit enter.
[End copied text from: http://karteek.selfdabba.com/2008/08/unpack-js/]

Setting up Apache Tomcat on CentOS5

This past weekend I decided that I didn't like the performance on my current CentOS5 setup. With that in mind, I set out to re-install and begin, again, to configure from scratch. My whole goal with this server is to eventually have running a: web server, emial server for the family, and local domain for the home network (as opposed to the current workgroup settings.

The re-install of CentOS 5.3 was again a breeze. Although, I didn't get into too many security settings. The thought behind that is that I want to make sure it will work for my needs and then I will tighten it down before publishing any content to the world.

The complicated step was the installation and testing of Apache Tomcat 6.0.20. With that in mind, a short 'how-to' (based upon the below link) is below:

To get started:

1) Files needed:
- JAVA:
- These should be saved/moved to: /root
- jre-6u14-linux-i586.bin
- jdk-6u14-linux-i586.bin
- APACHE TOMCAT:
- These should be saved/moved to: /usr/share
- apache-ant-1.7.1-bin.tar.gz
- apache-tomcat-6.0.20.tar.gz
2) Directorys needed:
- /usr/java
3) Notes:
- If some of the below process 'aren't found by your bash shell, use /sbin/[servicename]


Commands:

Install Java (JDK and JRE):

1) move to the java folder:
# cd /usr/java
2) Install JRE and JDK:
# sh /root/jre-6u14-linux-i586.bin
# sh /root/jdk-6u14-linux-i586.bin
- Verify installation. There should be a jre and jdk file in the /usr/java folder

Install ant and Apache

1) move to share folder:
# cd /usr/share
- Install ant first:
# tar -xzf apache-ant-1.7.1-bin.tar.gz
- install apache tomcat
# tar -xzf apache-tomcat-6.0.18.tar.gz

Enable Ant linkage

# ln -s /usr/share/apache-ant-1.7.1/bin/ant /usr/bin

Configure environmental variable:
- move to folder with catalina.sh
#cd /usr/share/apache-tomcat-6.0.20/bin
- open catalina.sh in your favorite editor (I used vi)
- add as a second line:
- JAVA_HOME=/usr/java/jdk1.6.0_14

Test config

# cd /usr/share/apache-tomcat-6.0.20/bin
# ./startup.sh

Check for error log
# less /usr/share/apache-tomcat-6.0.18/logs/catalina.out

Run the startup file (I may have to edit file location...doing this from memory)
#cd /usr/share/apache-tomcat-6.0.20/bin
# ./startup.sh

A startup script can be found on the below link. This script can be used to cause tomcat to start automatically at system startup. I did test this script on my original install, but opted not to use it this time (remember, I reloaded CentOS to try to clear up performance issues). I should note that the below link uses older versions of java (update 10) and of apache tomcat (6.0.18).

My end result is that my service works as it should, I set up a DynDNS account to test it, and I am now ready to re-build my website and move my domain.

Reference:
http://de0ris.blogspot.com/2008/08/installing-tomcat-6x-on-centos-5.html

Moving On

As mentioned in a previous post, last Thursday, I did something I have never done before: I turned in my two week notice!
Basically, through word-of-mouth, and two good interviews, I was offered a postion that is: closer to home, pays a lot more, and doesn't have the headaches of my current position. Anyway, that is enough complaining. I actually HAVE a lot to be grateful for, and to look forward to:
1) My son starts Kindergarten in two-weeks. He will be the only kid running around a Georgia school with Michigan Wolverine and Detroit Tiger shirts on! I LOVE IT!
2) My wife, after years of not being able to due to Army life, is finally in college and starts her first full semester in a couple of weeks. She deserves it!
3) My new job sounds incredible, is a place I have wanted to work for AWHILE, and, it will allow me to focus on what I like: intrusion detection and prevention, and I think some code inspections! I am definitely excited. This job is closer to home, more money, and, so far anyway, better people!

Drop it and Run?

I have never been able to just quit something without a reason. Nor have I been able to walk away from problems unsolved without at least making sure that I have said "my peace." I mention this because I turned in my two-week notice last Thursday, and yet here I am, still trying to solve problems for my current (for the next 8 working days) employer.

Anyway, I will save the complaining for another time but there are two things really standing out to me right now:
1) We (the cyber security section) asked for access to our network scanner over a month ago, for the second time. Finally, after the GM said we were to be given access so that we had oversight and could do our own scans, we were informed that we had access. The problem came with the fact that our normal user accounts were used, through LDAP, to grant this access. This does not allow for oversight, or privileged scanning. I KNOW that the system admins knew this is how they set it up, ignoring the requirement and the GM. However, that is all I am going to say on that for now.
2) Symantec Endpoint Protection 11: Holy Crud! What should be a very simple install has become a pain, for me and the second Symantec tech support guy (who has been A LOT better than the first).
We (my boss and I) started out with getting the pre-req's installed: java, ASP, IIS. We verified all permissions and that the IIS setup was correct. Then we installed SEP11.
The problem we had was that the clients would NEVER talk to the server. So again, at the request of the Syamanted Tech guy, we double and triple-checked the settings for IIS, the communications file (Sylink.xml), the network connectivity, etc. Nada! After the third day, the tech rep asked us to uninstall IIS (no other app was using) and SEP manager. This we did, in addition to removing the symantec client on the server box as well. We went so far as to verify that there was no left over symantec data ANYWHERE on the system.
Unfortunately, after we did all of this, we (this time with the web admin, to cover our rear-ends) set out to re-install IIS and verify its installation. However, it would NEVER install correctly. After hours of digging around on the few error messages we had, I found that this related back to file permissions on the %windir%/Registration folder (an old, MS05-051, issue). So I did the obvious thing and started to manually ensure that the permissions were correct.
However, even before I could make one change, the system froze! I was able to log off and attemp to log on, only to have the system freeze completely! What happened next was BAD!
I waited, and I waited, but the system would just not finish loading. So, I did what I think to be the obvious, and only, option: I did a hard shutdown of the server. This is a Dell PowerEdge 1950, and I already had questions about how the sysadmins set it up...but that's a WHOLE different blog. In any case, what happened was that the Server will NOT, at all, power back up! I have never had a server that had basically nothing on it, (wasn't even in production yet, really) fail to start after a hard shutdown!
To be continued?....

SSLF/FDCC compliance - The Fun Never Ends

My two biggest focal areas regarding security are: intrusion analysis and secure software programming. After testing two different, but related, security products (SEP 11 and Policy Orchestrator) and then performing the subsequent installations of each, I have come to the conclusion that:
Software installers should automatically verify known registry/GPO settings as necessary, or should at least return the top [five] possible failure mechanisms. I know I am not the first to suggest this requirement. I am also aware that there are some concerns with allowing an installer TOO much access to high-value information on the system. However, I believe that there is a compromise to be had somewhere in the middle.

Of the two products, McAfee's ePolicy Orchestrator (ePO) is used, at least in this instance, for compliance monitoring. It does have some other excellent functionality, and the program is good in general. However, I am not making a sales pitch.

The biggest issues with ePO is that the following settings MUST be made:
- Log on as a service: the accounts listed here must include the account used by ePO. This is somewhat of an obvious requirement. However, an overzealous SysAdmin can cause some heartache for the one installing ePO (as was the case here), as this requirement isn't noticed until half-way through the process.
- NtfsDisable8dot3NameCreation: In general terms, allowing for 8.3 names presents a low risk to the system and can slow down high-use systems. However, it should be noted that "turning on" this setting is an FDCC requirement. The problem with this setting being enabled is that Apache, used by ePO, will not install correctly, or if enable later, will not load properly (roughly 100 core load error messages will display on the initial GUI under the log in section).

The other product, the one that inspired this rant, is Symantec's SEP 11. While this product appears to be an improvement in many ways over version 10, there are still some kinks to work out. However, I believe some of these "kinks" could be mitigated, or at least avoided, if some functionality was tested by the installer, specifically LDAP authentication. Buried in a Symantec Forum was the fact that if:
- LDAP Server Signing Requirements must not be required. If this setting is "required," the SEP Manager will NEVER authenticate to the LDAP. Troubleshooting this issue was easier with Wireshark captures than with searching Symantec (or maybe I just felt like being an uber-geek that day). What I decided to do was to start capturing through Wireshark, with a simple filter set for my source ip address. Once I did that and attempted a couple of authentications, it was obvious that the LDAP server was immediately denying the authentication attempt. This was obvious from the fact that the LDAP server was immediately issuing a RST packet after the Hello packet. With this setting changed, the SEPM could easily import from the LDAP server.

So my conclusions are these:
1) Although documented in both cases above, some of the documentation was "bulky" or timely to locate. A better organization of "known issues" in release documentation would be helpful.
2) If the installer called a method to verify these settings, or attempted to "use" these settings during install, and then returned the appropriate error message(s), troubleshooting would be less time-consuming (read: more cost effective).
3) It is still better to look at what the program is actually trying to do on the network, then sift through pages of help forums. (I should add that, although not suprised, tech support at one of these companies, was not aware of the issue or the fix). I guess I would rather spend time looking at the traffic, reading the packets, and using that to decipher what is happening on the network.
4) The SSLF rearing it's ugly head, again, validates once more that careful testing and understanding of the settings is definitely required.