Archive

Author Archive

LizaMoon Is Back On The Security RADAR

April 1st, 2011 No comments
LizaMoon is a Mass-Injection Attack that is not new, but is currently getting security attention again. Using Google’s security results as a weak indicator of scope and severity, LizaMoon is indicated as asignificant threat to beware. Over 1.5 million URLs have links with the same attack mechanisms as the original attack, and a half million have an included script to the lizamoon.com site, which Google has listed as harmful.
GOOGLE WARNINGS
If you browse to a website that Google has previously listed as harmful, you may see the following warning before any content is loaded.
Google Harmful Web Site Warning for LizaMoon

Google Harmful Web Site Warning for LizaMoon

Read more…

Categories: Uncategorized Tags:

Top Ten Most Critical Web Application Security Vulnerabilities

March 22nd, 2010 No comments

Web application security is often viewed incorrectly as a set of server and host-based security issues, rather than code-level and configuration-based security vulnerabilities. Although servers and hosts may still be the cause for exploitations, it is critical that security professionals recognize the major impact of poorly written web applications as well as how their applications and servers are configured separately and in combination. The Internet is increasingly responsible for handling and storing information and files of a sensitive nature requiring security and protection. Keeping hackers at bay and assuring the privacy of private and proprietary documents is paramount. Below are the top ten security vulnerabilities and how Security Programmers mediate these to prevent exploitation.

Security Web Programmers are often not given the clout nor the attention they deserve. Security programmers apply a much higher degree of attention, detail, and time to programming. Secure software may require more time and money than insecure software. A comparison must be made between the cost of securing web applications, and an insecure web application bringing the business down or releasing sensitive information to potentially nefarious hackers.

Don’t be misled by security misnomers or be mistaken about your security requirements. Security factors can be well-defined and explained at any level of your corporate structure. Emagined Security employs security programmers who are trained and experienced to develop secure software, including web and database applications. Our proven security programming techniques and multi-layered security development protocols ensure your web applications are protected and your sensitive information secured. Read more…

Categories: Uncategorized Tags:

Secure Web Programming

July 10th, 2009 No comments

Web Programming in and of itself is not the issue, so much as the Security of the Web Programming. Over the years there have been many people involved in “programming websites.” The distinction must be made here between a real web programmer and a web page designer. It is the dynamic back-end systems that typically create security vulnerabilities on web servers. Static web pages that do little more than show some content are not likely to cause havoc.

A Web Programmer is typically involved in a server-side language such as PHP, ASP, and other languages that are optimized for web applications. My specialty is Secure PHP & MySQL programming, especially for web and database programming applications. This does not negate the ability to comment on web security for ASP and other languages, as they all operate pretty much the same, just with different command structures and spellings. Data flows the same way, and potential security vulnerabilities are about the same. The only exceptions are associated with a Microsoft Web Server, which inherently provides regular security flaws and problems. Read more…

Categories: Uncategorized Tags:

A Short and Shortsighted History of Hacks: Part 2 – The Internet Sniffing Attacks

May 15th, 2009 No comments

My last blog entry was an attempt to fill in critical missing pieces from Computerworld’s “A short history of hacks.” Unbelievably, this otherwise well-written piece missed two of the major series of cybersecurity attacks that have ever occurred. The first was the Operation Desert Storm/Desert Shield attacks that occurred in the early 1990’s. I’d like to now focus on the plethora of Internet sniffer attacks that occurred between 1994 and 1996.

Some attacks are dramatic. Attackers may write brilliant scripts to exploit a not very well-known vulnerability, or may play “cat and mouse” with a technical staff trying to defend a network. The sniffer attacks that were so widespread between 1994 and 1996 were not dramatic, and the effort required on the part of the attackers was far less than any time before. But during this period more hosts were compromised than at any previous time in Internet history.

By the mid-1990’s Ethernet was a household word; token ring networks and other alternatives were becoming far less prevalent. Ethernet technology has many practical advantages, but it has a property that until the time widespread sniffer attacks were discovered was largely overlooked. This technology is “shared media” technology, meaning that any host or device connected to a local Ethernet segment can capture any data that traverse that segment. Attackers exploited this property by breaking into one host or device on an Ethernet and then changing the network interface to go into promiscuous mode. The “bad guys” then harvested the mostly cleartext content of the traffic traversing Ethernets to obtain an untold number of passwords. The attackers focused on network segments owned by Internet Service Providers (ISPs) on which external routers were placed. Consequently, frequently all network traffic coming in and out of the ISP’s networks was gleaned—a mindboggling nightmarefor the “white hat” community. Dr. Matt Bishop of the University of California at Davis, who had been closely following these attacks, surmised that attackers had obtained so many passwords that they were unable to use them within a reasonable period of their having obtained them and thus had to stockpile them.

I left CIAC in 1992, so I learned of most of the sniffer attacks with which I became acquainted through word of mouth. However, in the mid-1990’s I still had an account on one of CIAC’s machines. One day I discovered that my password for this account did not work, so I called the system administrator, who quickly reset the password. I was confident, however, that I knew the password and that somehow it had been changed. What I did not realize at that time was that just a few weeks earlier one of the members of the then current CIAC team went to Brookhaven National Laboratory to respond to the pandemic sniffing attacks there. After this person collected log data and other information, this person then did a cleartext login back to the same CIAC server to which I had access. Worse yet, this person also entered the password required for root access. After gaining unauthorized superuser access, the perpetrator then almost certainly set the network interface in promiscuous mode and then used captured passwords to gain unauthorized access to many other Lawrence Livermore Lab hosts. The number of compromised systems must have been embarrassing both for CIAC and Livermore Lab. I am also quite sure that this person for some reason also changed the password to my account. About the only good thing out of this ugly episode is the realization of the need to avoid terrible mistakes of this nature when handling incidents!

Today, secure shell (ssh) is widely used, something that precludes the kind of sniffing attacks that occurred in the mid-1990’s. Terminal (tty) sniffing is now far more common. But the sheer number of systems that were compromised by sniffing attacks in the mid-1990’s should have deserved mention in “A short history of hacks,” which should thus be renamed “A short and shortsided history of hacks.”

Categories: Uncategorized Tags:

What Is A Secure Code Audit And Do I Need One?

May 13th, 2009 No comments

Secure Code Auditing is a structured approach to identifying, evaluating and mitigating programming and database security risks to web applications, databases and general network security. The majority of programmers are not security-minded, let alone security experts. Applications and infrastructure are typically designed with security vulnerabilities that can lead to security exploitations and potentially catastrophic results for your servers, network, and your business overall. When the programming team lacks security expertise and experience, and where security vulnerabilities may be an important issue for your business, a subsequent secure code audit is required. Different security consulting companies approach secure code audits differently, but essentially have the same goals in mind. This article is my description of what a secure code audit is, how we approach code inspection, and how to balance the factors that influence secure code audits. Read more…

Categories: Uncategorized Tags:

A Short and Shortsighted History of Hacks: Part 1 – The Desert Storm/Desert Shield Attacks

May 12th, 2009 No comments

A few days ago I discovered a Web posting with a fascinating title, “A short history of hacks,” on the Computerworld site. A nicely written piece, it covered events such as the Morris and ILoveYou worms, as well as the distributed denial of service attacks in February, 2000 that ended up being so costly for companies such as ZDnet, Amazon, e-trade and eBay. Amazingly, however, this history did not mention two of the most dramatic and severe series of cyber attacks that have ever occurred, the Operation Desert Storm/Desert Shield attacks against the US military in 1990 and 1991 and the widespread Internet sniffer attacks between 1994 and 1996 (to be covered in the my next blog entry).

The Operation Desert Storm/Desert Shied attacks occurred at a time when the Internet was still very young and not all that widely used. You may recall that soon after the Morris Worm struck in 1988, the US Department of Defense (DoD) split the Arpanet into two separate networks, the NSFnet (later to be called “the Internet”) and the Milnet. The DoD’s motivation was to protect the military’s main unclassified network from events such as widespread worm infections originating from the public network. At the time, the NSFnet the Milnet were only two of a number of wide area networks used for long haul communications. Among the other networks that existed at the time were NASA’s SPAN network, IBM’s BITnet, and the Department of Energy’s ESnet, The DoD did not want to totally isolate the Milnet, however. Accordingly, gateway machines that enabled traffic to get to and from networks such as ESnet were put in place. What the DOD did not anticipate was the possibility that attackers might be able to gain unauthorized access to hosts in other networks and then go right through the gateways to gain unauthorized access to Milnet hosts.

The first indications of the widespread break-ins into Milnet hosts were from log entries in Department of Energy (DoE) machines. The attackers broke into DoE machines using what now seems like very rudimentary attack methods, including password guessing (or sometimes even using null passwords), exploiting a VMS vulnerability in the SYSMAN utility, exploiting trust relationships between hosts, and a few others. Once they gained access to a host, they often already had super-user privileges, but if they did not, they exploited other vulnerabilities to take complete control of the victim systems. They then installed back doors. By breaking into hosts at DoE sites such as Los Alamos National Laboratory, Lawrence Livermore National Laboratory, Fermi National Laboratory, Sandia National Laboratory, and Brookhaven National Laboratory, the attackers had more than enough springboards from which they could launch attacks against Milnet hosts at military centers such as US Navy Headquarters, the Pacific Fleet Command,, Rome Air Force Base, Kelly Air Force Base, the Pentagon, and many more, which they did successfully day after day for well over a year.

Once the attackers broke into DoD hosts, they used commands such as grep in Unix systems to discover files that contained the information they desired: information about military equipment, weapons systems, troop and warship movements (especially in connection with Operations Desert Storm and Desert Shield) and much more—they often even searched for “nuclear!” The attackers stole so much information that they quickly filled the hard drives of their own machines. They then resorted to downloading huge amounts of information onto systems at the University of Chicago and Bowling Green University.

Incident response was a very new function when these attacks occurred. The DoE’s Computer Incident Advisory Capability (CIAC) first noticed the attacks and reported them to officials at both DoE and DoD. CERT/CC also received reports of attacks with similar patterns from Internet users. At one point the DoD, DoE, U.S. Navy’s incident response team, the National Security Agency, the US State Department, the National Institute of Standards and Technology (NIST), the Central Intelligence Agency, the Air Force Office of Special Investigations, Army Intelligence, the Federal Bureau of Investigation, CIAC and CERT/CC were involved. Cooperation and coordination were extremely difficult to obtain, but despite many obstacles (most of them political and bureaucratic in nature), these entities managed to conduct reasonably successful investigation efforts.

The gang of attackers was led by a rather harsh ringleader who taught his understudies how to hack into systems in return for his receiving the information they were able to glean. I knew the names of all the principal attackers, and because of a successful CIAC effort to tap their electronic talk sessions, I even learned where they lived at the time. The attacks, which originated from the Netherlands, were ostensibly financially motivated. The ringleader wanted to find a buyer for the information, but to the best of my knowledge he was never successful in doing so. The State Department pressed the Netherlands to charge the identified individuals, but this country declined to do so on the basis that at the time, breaking into systems was not a against Dutch law. To at least some degree, however, justice was served—the ringleader reportedly ended up going to prison for credit card fraud.

The news of the attacks did not reach the public until John Markoff of the New York Times published a front page story describing the attacks in the fall of 1990. How he pieced together the bits and pieces of information that he had amassed was simply amazing. Additionally, about the same time ABC News ran a lead story about the attacks. Later, NIST had me publish an unclassified account of the attacks.

In all, little changed as a result of the attacks. The DoD and DoE did not really improve their cyber security, nor did US legislators propose or pass any national legislation that required better security within the government. As you undoubtedly know, cyber security within the government has improved somewhat over time, but it still has a long way to go. If powers-that-be within the US government had taken the lessons learned from the Desert Storm/Desert Shield attacks more seriously, however, the government would without question be way ahead of where it is now.

Categories: Uncategorized Tags:

The Five Phase Approach of Malicious Hackers

Hackers typically approach an attack using five common phases. It is important to understand these phases of hacking attacks in order to better defend against them. Here we’ll discuss the five hacker phases to better understand them and how they relate to each other. This information is useful for network administrators, and essential for network security consultants. Read more…

Categories: Uncategorized Tags:

Are My Website Forms At Risk For Being Hacked?

One of our readers wrote in to ask, “My website has forms in it and I want to know how to tell if they can be hacked.” The website is using a standard processing language and a back-end MySQL Database. Multiple forms exist in the website including a newsletter form, a user fedeback form, and a New Membership signup form. Although versed in programming, the reader does not have a background in security programming or network security in general. Realizing that web forms can be a port of entry for hackers, the question of website application security arose and inspired contacting me. Lets discuss web form application security for your network. Read more…

Categories: Uncategorized Tags:

Is Your Programmer or Network Admin A Hacker? Better Ask!

With the large number of hackers and the increasing threat from overseas hackers, more and more business are at risk for attack and exploitation. There are many types of hackers and certainly many degrees of intent and purpose. The majority of hackers are usually programmers and network security specialists, who likely have a day job under the guise of the 9-to-5 John Doe. Your business could be vulnerable to attack from internal sources as well as external. The question remaining to present to your programmers and network administrators: “Is anyone here a skilled hacker?” Read more…

Categories: Uncategorized Tags:

An Overview of Web Application Security

April 30th, 2009 No comments

With the web and business web sites accessible by everyone (including malicious hackers) the security of your web application is at the top of the list of security issues on experienced PHP web developers’ minds. Lets look at some security concerns of PHP Security Developers, and what they can do to make their web applications more secure. Read more…

Categories: Uncategorized Tags: