Showing posts with label hacking. Show all posts
Showing posts with label hacking. Show all posts

Thursday, May 20, 2010

Metasploit 3.4.0 Hacking Framework Released

Good news if you're looking to test your security defenses - the Metasploit framework has updated to version 3.4.0.

You wouldn't use Metasploit for evil purposes, boys and girls. Would you?

More than 100 new exploits have been included compared to 3.3.0, and a slew of bug fixes have also gone into the release.

From Darknet:

This is the first version of Metasploit to have strong support for bruteforcing network protocols and gaining access with cracked credentials. A new mixin has been created that standardizes the options available to each of the brute force modules. This release includes support for brute forcing accounts over SSH, Telnet, MySQL, Postgres, SMB, DB2, and more, thanks to Tod Bearsdley and contributions from Thomas Ring.


Metasploit now has support for generating malicious JSP and WAR files along with exploits for Tomcat and JBoss that use these to gain remote access to misconfigured installations. A new mixin was creating compiling and signing Java applets on fly, courtesy of Nathan Keltner. Thanks to some excellent work by bannedit and Joshua Drake, command injection of a cmd.exe shell on Windows can be staged into a full Meterpreter shell using the new “sessions -u” syntax.

You can get all the details in the release notes.


Thursday, December 31, 2009

Feds Recommend Dedicated PC for Online Banking

The FBI and the American Banking Association are recommending that small businesses use a dedicated PC - not used for web browsing, email, or any other purpose - for online banking.


That's ridiculous.

At some point business owners need to begin holding accountable the vendors who provide inadequate security products, software developers and firms that release buggy, vulnerable operating systems, browsers, and applications, and users who don't follow safe computing and web browsing guidelines. And they need to demand more robust authentication and authorization mechanisms from their financial institutions.

It's absurd that money movement practices have not evolved in the face of increased threats and hundreds of successful exploits. From Wired:

The FBI says thieves have stolen about $40 million in this way in more than than 200 cases they’ve investigated in the last two years involving small to mid-size companies and organizations. Such companies generally do not employ dedicated computer security staff or have extensive knowledge about how to protect themselves with firewalls, anti-virus and other measures and policies.

It's a common attack strategy - aim for the weakest point in the system. Why attack a bank directly when the soft underbelly of naive business owners and employees remains exposed, ripe for the picking?

Small businesses need to come to terms with the fact that computer security is a mandatory cost of doing business. It isn't 1982 anymore. You can't ignore information security any more than you can keep a manual ledger or crank out your financials on an adding machine.

So let's say you take the advice of the FBI and ABA and set up a dedicated computer within your network for online banking only. Guess what? You're still connected to the internet, and you're still not 100% safe.

I can redirect your access to your online banking site via DNS cache poisoning. I can compromise another computer (that's not dedicated) within your network and use it to infect and take control of your dedicated PC.

I'm able to conduct IP address spoofs, or perform a man-in-the-middle attack to snag the traffic going between you and your financial institution.

If these don't work, there's always session hijacking, or replay attacks, or compromising weak encryption keys. And a dedicated PC doesn't prevent attacks via social engineering.

Here's a couple of things every small business should consider:

  • Use a non-Microsoft platform for conducting online banking transactions. Since Windows and Internet Explorer continue to have a dominant market share, they attract the most attention from attackers.
  • Don't use wireless for online banking. It's too difficult to secure for those without the correct technical expertise.
  • Use Mozilla Firefox, Opera, or some other browser.
  • Install good antivirus software and keep it updated.
  • Use a tool like Secunia CSI to make you aware of vulnerabilities and end-of-life software installed on your systems
If you're truly concerned about online banking, follow the guidelines I provided in my October 13, 2009 posting, Safer Online Banking Using a Live CD. It's certainly more manageable than setting up a dedicated PC, because a Live CD can be used for banking transactions from any computer.




Friday, October 23, 2009

Sniffing VoIP in Real Time - iPhone Users Beware

It's been technically possible to plug a laptop into a network and sniff Voice Over Internet Protocol transmissions for quite awhile, thanks to the UCSniff tool. The only caveat was that the attacker needed to wait until the transmission was finished to reassemble the conversation.


Security researchers plan to present a demo this weekend at the Toor hacker conference showing that they can now intercept and playback VoIP conversations in real-time.

As The Register reports:

With a few clicks of a mouse, they will eavesdrop on a call between two audience members using popular iPhone applications that route the calls over the conference network.


Zoiks!

Not only is it possible to intercept conversations, but video conferencing transmissions can also be captured and played back as they happen.

If you're using public Wifi to save money by avoiding usage charges on your carrier's data plan, you should start thinking twice about the possibilities of real-time breaches of confidentiality that could occur through what is essentially a man-in-the-middle (MITM) attack. Unless you're implementing an encrypted transmission or secure tunnel that would foil sniffing tools, you're at a perilously high risk of being compromised.

Tools like this aren't particularly new, but what is changing is how user-friendly they are becoming, which allows fairly unsophisticated hackers with only moderate technical skills to perform tasks previously the domain of hardcore hackers.

You've been warned.

Image via Wikimedia Commons


Wednesday, August 26, 2009

R.I.P. Security on GSM Phones

A security researcher is launching an open-source project to crack GSM cellular phone encryption that will allow attackers to decode phone calls and any data that happens to be in transit via the device.

If you're on T-Mobile or AT&T in the US, you only have a couple of months until you need to begin worrying.

Cell phone security has been woefully lacking for at least twenty years, mainly due to what I describe as a Microsoft-like approach of delivering cool features first and security second, if at all.

Karsten Nohl claims that he's looking to exploit a vulnerability that's been known for 15 years and affects 3 billion phones as a way to prod cellular phone manufacturers and carriers to get serious about security.

Cracking GSM encryption is nothing new, but previously the tools have been very complex, highly technical, and pretty darned expensive. Nohl hopes to change that via his open-source project. Ah, the joys of distributed computing.

Link via CNET

Image via Silicon Valley Sleuth


Wednesday, August 5, 2009

Using a Drive-Thru Display to Steal Credit Card Numbers

We've all pulled up to the massive drive-thru board at our favorite fast food restaurant and been squawked at from the loudspeaker, yelled our order in response, then pulled up to the window to pay for our heat-lamped, paper-wrapped, food-like substances. Little did we know that the whole system might be vulnerable to exploits that could result in customer credit card numbers being illegally harvested.

Network World has the details of how Rick Lawhorn was waiting in the drive-thru line when the display crashed, and a bunch of code popped up on the screen. Like all true geeks, he snapped a picture of the display with his cell phone for later examination.

When Lawhorn used the Google to search for some of the code snippets, he uncovered some disturbing details, such as how the system should be configured to meet certain requirements, such as PCI.

The problem with the set-up he found is that it likely cuts against some basic security requirements concerning network segmentation and wireless devices.

The code revealed configuration details of the LAN running from the drive-thru display to the building, and indicated that the cable ran directly to the restaurant's point-of-sale system, where customer credit cards are entered.
Oops!

It's unlikely that hackers would try to steal credit card numbers using the cable running from the drive-thru display to the LAN within the restaurant, since most drive-thru setups don't have customers swipe their cards at the ordering board. But since the cable does connect to the LAN, it's a convenient way for the crooks to get access to the network and launch all sorts of attacks against the computers on the network, including those that could contain personal information and credit card data.

The level of IT sophistication associated with a typical franchised fast food establishment is such that it's unlikely such an exploit would be discovered short-term, which means a criminal could sit in the parking lot and sniff traffic for an extended period of time. Depending on how the network is segmented and firewalled, it might even be possible to breach other systems not physically located within the restaurant itself.

In light of the many data breaches still occurring among retailers of all types, this type of exploit would be low-hanging fruit for many, especially those associated with organized crime networks. You won't hear much about this in the months to come, but you can bet that a large number of IT security departments are reviewing their architectures and performing assessments to see if similar design defects exists in their configurations.

If they're secure, please give them a hot apple pie.

Image by iirraa via flickr


Monday, July 20, 2009

New Linux Zero-Day Flaw

For all you Linux users who thumb your noses at Microsoft's history of vulnerability and large attack surface, prepare to fend off some attackers of your own.


Brad Spengler released the Linux exploit's source code last week, indicating that it exploits a vulnerability in at least two Linux versions - 2.6.30 and 2.6.18, both 32-bit and 64-bit.

The scary part of this flaw is that it gets around a null pointer protection in the mainline Linux kernel, so if successfully exploited, the attacker could gain root access. Game over.

Red Hat Enterprise Linux 5 uses on of the vulnerable versions - 2.6.18.


According to Spengler, the workaround would be for Linux admins to compile the kernel with fno-delete-null-pointer-checks.

SANS has more.


Tuesday, July 14, 2009

Rainbow Tables for Cracking WPA

If you're looking to play around for research purposes only with cracking some wireless access points that are using WPA for security purposes, you may want to check out the new rainbow tables posted at Offensive Security.

With 49 million records in the WPA-optimized password dictionary file, lots of low-hanging WPA fruit will be cracked in no time.

Cracking keys for fun and profit - it's a wonderful thing.


Tuesday, June 23, 2009

July 2009 - Month of Twitter Bugs

Hey, all you 140-character characters - better hold on to your hats during July.

A nice group of techies has decided to continue the tradition of "Month of 'X' Bugs" to bring you a full month of flaws and vulnerabilities that reside in Twitter.
Each day I will publish a new vulnerability in a 3rd party Twitter service on the twitpwn.com web site. As those vulnerabilities can be exploited to create a Twitter worm, I’m going to give the 3rd party service provider and Twitter at-least 24 hours heads-up before I publish the vulnerability.
Should be an interesting month, given what happened when this occurred for browsers.

Month of Twitter Bugs


Friday, June 12, 2009

Change Those Default Passwords, People!

We have another shining example of how firms spend billions on security products in an attempt to harden their infrastructure, and then fritter it all away by not having two things in place:

  1. Established processes to change default passwords on hardware and applications purchased from third parties
  2. A program of regular assessments to check and remediate defaults that are discovered
The latest fraud was outlined during the unsealing of Justice Department indictments of three Filipinos accused of hacking PBX phone systems by using the default passwords and then re-routing long distance calls through those gateways using call centers in Italy.

Initial estimates put the fraud loss at $55 million. You can change a lot of passwords for $55M.


Does your firm have an established process for changing vendor defaults when you get new hardware and software? If so, is that processes followed and audited to ensure compliance?

Ideally, this should occur while the system is in dev and/or UAT, long before the system ever enters production, but a better rule of thumb would be to replace default passwords and configurations before the system is ever connected to your prod network.


The same is true for home users. How many stories have we seen where wireless routers and access points were compromised by simply providing the factory-default login credentials for the administrator account? Same with cell phones, handheld devices, and your new Internet-ready refrigerator that will send you a text message when you're running low on cheese.


AT&T was one of the companies named as being victimized in this case, and you know they spend millions each year on infrastructure security. I'm guessing they are doing some password assessment tests now, and it's better late than never, but they really missed an opportunity here.


Sometimes in our sophisticated technological world, we overlook the simplest of threats.


Default Passwords Led to $55 Million in Bogus Phone Charges , via Security Fix



Thursday, June 4, 2009

Sniffing Wireless Keyboards

remote-exploit.org has announced the upcoming release of Keykeriki, a hardware/software wireless keyboard sniffing tool.

And you thought your keystrokes were safe there in your office, even though they are being magically transported through the air wirelessly.


Whether testing your own wireless keyboard security (hah!), or demonstrating how easy it is to capture someone else's typing (for educational purposes only!!), Keykeriki is capable of ruining the day of any Microsoft wireless keyboard user.


Breathing a sigh of relief because you're a Logitech wireless keyboard user? You shouldn't, because support for Logitech devices should be ready soon, although it's not included in the first release of Keykeriki.



Friday, May 29, 2009

Army Hacking Sir!

Where's Sergeant Hulka when you need him?

It seems that Turkish hackers breached two U.S. Army web servers and redirected traffic to other pages, including those with anti-American and anti-Israeli messages.


The most recent breach was on Jan. 26 when a server at an ammo plant in Oklahoma was compromised. The other reported breach occurred in Sept. 2007 and involved an Army Corps of Engineers server in Virginia.


Authorities believe that SQL injection attacks were used in both cases, which is not surprising given how often we've seen this in the past, but with vulnerable SQL installations well known, it's surprising that the DoD hasn't mandated vulnerability assessments of Internet-facing servers, using both internal resources and security firms contracted to assess from the outside looking inward.


The reports claims that it's unknown if sensitive information was accessed as a result of this breach, to which I wonder what the heck the Army is doing putting sensitive information on Internet-accessible points of presence without having a robust testing program in place and a layered control approach.


Perhaps President Obama's cyber-security czar could ask the Army that very question.

Report: Turkish hackers breach U.S. Army servers , via CNET


Friday, May 22, 2009

The Cyber Security Sky is Falling!

It's hard to not don a Chicken Little outfit and run around the city warning people of the computer apocalypse developing right before their eyes. Geez, don't you people read the news for free on the Internets?

Some sort of "mystery virus" has infected the computers at the FBI and U.S. Marshals Service. Did anyone swab their USB ports and test for swine flu?

Neither agency was willing to reveal much detail about the event, but based on recent vulnerability management performance reporting on federal agencies, both law enforcement groups may have contracted the Melissa virus from 1999. I'm kidding, but they should really stop clicking on those little blue linky things that keep coming to them in emails while they're surfing for porn.

Also in the news is a distributed denial of service attack against DNS in China that left millions of Chinese users unable to resolve domain names to IP addresses, rendering them unable to evade the Great Firewall of China to watch You Tube videos and rue over how inadequate they are compared to glorious American male adult film stars.

Is their DNS held together with twine and broken twigs, tied seven layers high on the back of a bicycle? How can a DDOS knock the country out if the attack is at only one location?

Inquiring minds want to know.



Tuesday, May 19, 2009

Microsoft Security Advisory on IIS

Microsoft has issued Security Advisory 971492, Vulnerability in Internet Information Services Could Allow Elevation of Privilege.

If you're using IIS, be aware that attackers may be able to elevate privileges by exploiting a vulnerability in the way the WebDAV extension for IIS handles HTTP requests. For example, I could create a special, anonymous HTTP request and leveraging the flaw, gain access to an area that normally requires authentication. Like read some files you don't particularly want me to read.

The Microsoft Security Response Center (MSRC) has more info and advises that they are not aware of any current attacks.

Bottom line: check to see if you need WebDAV in your installation. If not, turn it off, especially if your IIS is Internet-facing, which I'm guessing it is.



Friday, May 8, 2009

UC Berkeley Data Breach

CNET Security is reporting that computers at the University of CA at Berkeley have apparently been hacked, placing the personal information of as many as 160,000 individuals at risk.

At least 97,000 Social Security numbers were accessed, which is a very big deal.

Preliminary investigation seems to show that the attackers gained access through a public-facing web site, then bypassed controls to break into a database stored on the same server. Again, security best practice is to NOT store the db on the same physical or virtual server for this very reason.

This was a Health Services computer, so you can bet there will be all sorts of recriminations. With all the rules surrounding the HIPPA reg, a granular investigation will undoubtedly take place.

I'll keep you posted, so stay tuned.

UC Berkeley computers hacked, 160,000 at risk


Wednesday, March 11, 2009

Those Hacking Aussies

Since good, old fashioned police work doesn't seem to work very well down under, Australian police are asking for permission to hack into computers in their quest for evidence.

There are several troubling aspects of this proposal. It's good that they would still need a warrant, although as we've seen from the FBI here in the states, that doesn't always mean law enforcement has been above-board or followed all of the rules.

If a judge gave their approval, police could hack in, monitor for up to seven straight days, and not have to tell the owners for (conceivably) up to three years. Where's the due process in that?

Most software and security vendors are on record as opposing these kinds of efforts, but you can almost read the writing on the wall - eventually, some enthusiastic group of lawmakers will get involved and enact legislation requiring vendors to build in rootkits and back doors for use by investigative agencies.


Tuesday, January 6, 2009

When Is Hacking OK?

Here in the states, agencies such as the FBI are known to employ some nefarious methods to gather evidence of a crime, such as installing keystroke loggers or other spyware-like code on the computers of suspects. What's less clear is whether law enforcement agencies are required to obtain search warrants or court orders before implementing hacking techniques that would land the rest of us in the pokey.

It's not even a question in the UK anymore, as police there have been given permission to hack into the computers of suspects without the need for a court-approved warrant of any kind.
The technique is known as "remote searching", a nice euphemism for breaking into your personal computer(s) without your knowledge and removing items of interest that can later be used against you in a court proceeding. It follows a European Union (EU) decision to allow police across the EU to significantly expand the use of what had previously been a seldom used power involving warrantless intrusive surveillance of private properties. This would include the ability of MI5 or other police agencies to remotely search the contents of your computer hard drive from hundreds of miles away, whether you were at home, in your office, in a hotel, or working from a conference.

If that's not disturbing enough, consider that this ruling allows other agencies from the EU (French, German, etc.) to ask their counterparts in England to invasively search someone's UK computer and send back to them any information or material obtained in the remote search.
Concerned that the contents of your email, or your web browsing habits might be examined without your permission? You should be. It certainly makes you think twice before you decide to IM with friends, knowing that someone might be reading your keystrokes. Similarly, how about the people with whom you are communicating? Their information becomes part of the data mining too.

What are the requirements that need to be met before your privacy can be violated under this ruling? Well, if a senior officer "believes" that it is “proportionate” and necessary to prevent or detect serious crime, then all bets are off. That seems pretty subjective to me, and anytime you add subjectivity into the mix, the propensity for abuse of power is both real and well documented.

If there are any doubts, examine the American policy of National Security Letters instituted after September 11, in which federal agencies could go to the secret FISC court implemented under FISA - often after the fact - to obtain the needed permission to justify the search of a suspects property or information.

A 2006 US Justice Department report cited "issuance of NSLs [national security letters] without proper authorization, improper requests and unauthorized collection of telephone or Internet e-mail records due to FBI errors or mistakes made by NSL recipients." In 2006, FBI agents using NSL requests sought secret data on more than 11,500 U.S. citizens and resident aliens, compared to 6,500 in 2003, and there were also about 8,600 requests for information about "non-U.S. persons" that included visiting and illegal foreigners, which was actually down from 10,200 in 2003. Quite a black eye for the FBI, who struggled to get into compliance with the NSL requirements even after their abuses became public.

So what did the FBI do? In early 2008, reports surfaced that the FBI had sought approval from the very same Foreign Intelligence Surveillance Court to implement their CIPAV spyware program to support investigations into terrorism or foreign spying. Some of these FBI requests dated back to 2005, while the agency was still trampling the rights of citizens using NSLs.

What's CIPAV? The acronym stands for "computer and internet protocol address verifier," software designed to secretly infiltrate a suspect's computer and collect information, including IP address, MAC addresses (the card your network cable plugs into, as theoretically there are no two NIC cards with the same MAC address anywhere in the world), a list of open TCP and UDP ports, running programs, operating system type and serial number, default browser, the registered user of the operating system and the last visited URL, among other things.

Once this information is collected, it is secretly sent to FBI systems in Quantico, Virginia, where your machine is monitored, checking in regularly with the FBI to report your activity without your knowledge. Very Orwellian.

Civil liberties groups in both the UK and US have howled in outrage over not only the scope of information that can be obtained, but the cloak of secrecy and the lack of adequate oversight to ensure that the new rules are followed in this age of technology-aided sleuthing.

Many are questioning the different rulesets for searches of homes and physical property versus binary data, with good reason. As we're seeing in cases involving online music sharing litigated by the RIAA, intellectual property lawsuits, and other civil and criminal proceedings involving the use and transport of materials via 1s and 0s, there's a significant lack of maturity in the interpretation of laws intended for 20th century property when applied to modern electronic data than can span the globe in an instant.

Given the UK government track record on data breaches involving information in their care and control, there's an additional layer of risk I'd call out. One would hope that since the stated goal is to secretly obtain evidence for use during an investigation, a measure of data security above and beyond what it typically used would be implemented. Time will tell if that's a valid wish.

As someone with a background in investigation and prosecution before coming over to the dark side of information security, I can understand the desire to have many investigative tools available in the constant struggle of good vs. evil. I'm also pragmatic enough to support the theory that "absolute power corrupts absolutely," and I'm a strong believer in the application of oversight and the implementation of frameworks that include checks and balances. There's simply too much evidence that abuse occurs.

The UK implementation of the EU directive is a bad idea, even in a world filled with emerging threats and evolving technologies being put to use by radical elements and terror groups. Are we willing to surrender civil liberties when the tradeoff is a vague, unsubstantiated promise of safety?

Since these kinds of measures are being implemented globally, it sounds like the answer is yes. I hope we don't come to regret that decision any more than we do currently.


Saturday, December 20, 2008

Cardmember since I stole your cookies

I expect American Express to struggle in this economy, with card members cutting back on purchases, which limits the amount Amex can collect from merchants for the privilege of accepting the various American Express cards.

One of the things that I expect them to get right, however, is web security, given it's an exploit vector, and successful compromise could allow all sorts of bad things to happen to innocent site users, like me.

Cross-site scripting, or XSS, is one of the more versatile and useful tools in the black bag of tricks. It's a too-common vulnerability to leverage in web applications, and it allows the bad people to perform code injections using HTML code or client side scripting, which permits them to either bypass existing access controls or to exploit your browser, especially if you're using an inherently poor security browser like Microsoft's Internet Explorer, or if you're not very timely in applying security patches or updating your antivirus signatures.

In some cases, the compromised browser can redirect you to an attacker's site that's set up to look like a real site, and in other cases, the attacker can take full control of your computer, capture your keystrokes (like user IDs and passwords), or turn your machine into a spam-spewing bot that responds to orders from a centralized command & control server owned by the Russian mob or other nefarious characters.


So when Amex was notified (several times) that they had a well-known XSS vulnerability on their site, you would think they would bust their ass to not only close the hole but see what other doors and windows they might have left open.
You would be wrong, of course.

The Register
reported that it took a full two weeks of being pestered by a security researcher who found the XSS flaw on their site, and that Amex had reportedly failed to respond to emails and other communications from the researcher as he tried to be a white-hat and use his powers to battle the forces of evil. Eventually, American Express managed to close the XSS vulnerability that was pointed out to them. Whew.


Except they didn't fix the problem. The fixed an instance of the problem. Two separate sources have reported that the XSS flaw still exists, allowing the crooks to capture americanexpress.com user authentication cookies. So they put a lock on one door, but failed to check the rest of their application to see if this flaw (or others) might exist elsewhere.


Assuming that Amex has a robust info security program, it's difficult to understand why these flaws weren't discovered during normal testing during the application development cycle, or as a result of periodic internal tests by the security or ethical hacking teams.

Certainly, Amex could benefit from occasional reviews of their sites by outside vendors who can do penetration testing and vulnerability assessment scanning as a check & balance to ensure that things are as locked down as possible.
XSS flaws aren't that troublesome to fix, either.

As a customer, I would expect American Express to do more than issue a press release confirming that they take security seriously. They should perform a top-down review of their app dev and vulnerability management programs and do some root cause analysis of their security incident response process to determine how it could take so long for a reported vulnerability to be corrected.


A good information security program involves constantly probing your own networks and evaluating your controls environment to find the gaps before anyone else does. With so many automated exploit frameworks out there, it doesn't take someone with a doctorate in computer science to compromise your network - attacks are point and click now, and if you don't believe me, go spend some time reading about the Metasploit framework.