wicd Privilege Escalation 0Day
Tested against Backtrack 5, 5 R2, Arch distributions
 
Spawns a root shell. Has not been tested for potential remote exploitation vectors.

Discovered by a student that wishes to remain anonymous in the course CTF. This 0day exploit for Backtrack 5 R2 was discovered by a student in the InfoSec Institute Ethical Hacking class, during an evening CTF exercise. The student wishes to remain anonymous, he has contributed a python version of the 0day, a patch that can be applied to wicd, as well as a writeup detailing the discovery and exploitation process. You can find a python version of the exploit and full write up with patch here: http://www.infosecinstitute.com/courses/ethical_hacking_training.html

Two people can interview for a position who look to be nearly equal in terms of experience, yet a hiring manager comes away with a strong recommendation to hire one and not the other. Or sometimes there are even instances in which someone may appear to be even stronger in terms of experience and training, and yet someone else gets the job. Setting aside potential discrimination issues, a very valid difference could be what some would call soft skills, or behavioral skills. These skills are the intangibles that really pull everything together and drive someone’s success or failure in a role.

Read more at:

http://resources.infosecinstitute.com/soft-skills-hiring/

Great work ninja-sec!!

A new write up at InfoSec Institute on circumventing NAT. While the technique presented here is not new, still a lot of people dont know how this works.

The process works in the following way. We assume that both the systems A and B know the IP address of C.

a) Both A and B send UDP packets to the host C. As the packets pass through their NAT’s, the NAT’s rewrite the source IP address to its globally reachable IP address. It may also rewrite the source port number, in which case UDP hole punching would be almost impossible.

b) C notes the IP address and port of the incoming requests from A and B. Let the port number for A equal X and the port number for B equal Y.

c) C then tells A to send UDP packet to the global IP address of the NAT for B at port Y, and similarly tells B to send UDP packet to the global IP address of the NAT for A at port X.

d) The first packets for both A and B get rejected while entering into each other’s NAT’s. However as the packet passes from the NAT of A to the NAT of B at port Y, NAT A makes note of it and hence punches a hole in its firewall to allow incoming packets from the IP address of the NAT of B, from port Y. The same happens with the NAT of B and it makes a rule to allow incoming packets from the IP address of the NAT of A from port X.

e) Now when A and B send packets to each other, these get accepted and hence a P2P connection is established.

http://resources.infosecinstitute.com/udp-hole-punching/

DISCLAIMER: InfoSec Institute received an anonymous submission concerning the leaked pcAnywhere source code. The article is published here, we have redacted any code snippets or other pieces of source code that were included in the original article. Otherwise it has been left unedited/unaltered.

The pcAnywhere source code leaked out onto the internet late January 2012 includes 47,021 files weighing in at 1.3GB. The October 2006 snapshot provides an insight into Symantec development practices, polices, and of course the code itself. Below is a brief assessment of the source code and what it all means for computer users, hackers, and Symantec.

http://resources.infosecinstitute.com/pcanywhere-leaked-source-code/

Thanks!

Android’s increasing popularity, combined with the possibility to create alternative markets, makes this platform a fertile ground for malware authors. While most of these applications just exploit the inexperience of the average user that is looking for free software, others are pretty smart and use more sophisticated techniques to take, and keep, control of the infected devices.

Lately it came to my attention that a new malware was taking advantage of the famous GingerBreak exploit to gain root privileges on infected phones. RootSmart, the name given to the malware by the people who identified it first, is the second application found in the wild making use of an exploit (the first one was GingerMaster detected back in August 2011).

http://resources.infosecinstitute.com/rootsmart-android-malware/

I was showing off a trick to export Firefox SQLite tables to a spread sheet, and while she is a forensics person, she had never ever heard of this trick. It is neat enough to know when working off an image to pull the entire history of a Firefox user by using the SQLite table manager Firefox plugin. You can also find this plugin for Chrome that makes things just as easy. This article though will focus on SQLite and Firefox.

http://resources.infosecinstitute.com/firefox-and-sqlite-forensics/

Whenever there is a query for a domain which is not in the resolver’s cache, the process happens by traversing through the entire DNS hierarchy from the root servers to the top-level domain (e.g., .com). The top-level domain (TLD) then gives us the information about the name server that has been delegated the responsibility of the domain whose IP address we are looking for. We then get the information about that domain from its name server. The results are then cached by the DNS resolver with a particular value of TTL (time-to-live), after which the entry in the cache expires.

The exploit targets a weakness in the cache update logic of some of the DNS servers. The exploit allows the cache to be overwritten in such a way that it is possible to continuously extend the TTL for the delegation data of a particular domain and prevents it from ever expiring. The domain will be completely resolvable indefinitely even though it has been deleted from the TLD servers. These types of domains have been termed Ghost Domain Names.

Read the full article and view a sample Ghost Domain here:

http://resources.infosecinstitute.com/ghost-domain-names/

Hello eh-netters, a new tutorial is available at InfoSec Institute review from Andrew King on writing self modifying code. This is part one of a three part series:

http://resources.infosecinstitute.com/writing-self-modifying-code-part-1/

In subsequent parts, Andrew will demonstrate how this can be used to bypass antivirus and other neat tricks.

Your thoughts?

Thanks to everyone out there on eh net for their support and advice. It was truly appreciated.

I want to let everyone in the eh-net community know that we have posted publicly our offer to peter. Can you please take a look and give feedback?

http://resources.infosecinstitute.com/corelan-public-apology/

Thanks for your sharp eye here. Can we get IPs of these guys? Would be quite interesting to out them publicly, dont you think?

Thanks guys for the advice! Here is a response we have put officially on our blog:

http://resources.infosecinstitute.com/two-sides-to-every-story/

To clarify here, this website material was used ONCE for ONE run of the exploit writing class. Not our advanced/cept class. The class had 7 students in it, and all were refunded and credited. Those guys have spent the last two years trying to contact people in our other classes all the time to find other times it was used, and you can bet if they did they would be writing it all over the place.

Even though it is not "legally" our fault, we have offered to make a public apology as well as pay $5000 to peter. I think this is a fair response, but we will take what you have said to heart.

Seriously, all these guys want is blood. Nothing else.

Hey guys, this is a totally ridiculous slander and defamation of our company. We have the upmost respect for copyright law and would never wish to harm another member of the information security community.   

Let's review the facts as they really are:

1. We hired a contractor to create some courseware for us for this course. Part of our contract, a very important part, is that we require totally original works, and do not allow for copyright violations. Any such violation is cause for termination of the contract and any associated damages. Unfortunately, this contractor basically copied all of the information from that site.

2. When we found out about this situation, we refunded everyone that took that class or offered them full credit towards another class. We also terminated the contractor and looked into legal options for suing for damages. We chose not to sue, as the cost and time spent doing this seemed to outweigh the benefits. We would rather concentrate on delivering great training instead of suing people.

3. When we were alerted via the various legal notices, we offered to issue a public apology as well as pay $5000 to the offended parties. Even though it was not us, but one of our contractors that did the infringement!! They rejected this.

4. We invite a lawsuit or to settle this in the courts, as we have a signed agreement that shows we did not do the infringement, and made a really good effort to make this right (via a public apology and paying $5000).

In short, yes, this is a bad situation. In hindsight, we should have checked to make sure this work was not copyrighted. But, we made a mistake, as everyone does in life, and the important thing is we tried to the right thing here. We offered to make a public apology and pay $5000 but they rejected it.

If there is anything we should be doing differently here, I would be open to suggestions.