In this thread, y'all spags can post questions about techy things and I'll try to explain them. If anyone doesn't quite grok that explanation, ask for more! Other tech types are totally invited to jump in with supplementary informations.
Background: I'm not a security researcher or a penetration tester (someone who breaks systems for a living to prepare businesses for real attackers) but I do work tangentially to information security, spend a lot of time at work documenting vulnerabilities in our software and socialise with these types of ne'er-do-wells. I'm looking at moving into this area professionally in the future.
WHAT DO YOU WANT TO KNOW ABOUT HAX?
So I'm just going to tiredly ramble about stuffs until people have questions.
Vulnerabilities in web applications are typically introduced by accepting user input. Showing people a website isn't too hard but as soon as you start caring about what users have to say, you open yourself up to all sorts of trouble. One example of this is the cross site scripting attack.
When the internet gives you browser a page, it sends something like the following.
<html>
<head>
A bunch of meta stuff like the title for the top of the browser, information about how to format the document.
</head>
<body>
Actual content of the page. Pictures and text and all sorts of buttons and shit.
<script>References to scripts that run on the page are also in here between tags like this.
These might be bits of code to tell the page how to animate the dropdown menu or do cool dynamic shit.
It can be as simple as sorting a list of items or as complex as the rules of a browser-based game.</script>
</body>
</html>
The browser hides the head and the script and uses them as instructions.
Now, take a page which has a single name change box for text input on it. It wants to know your name and will then display that name to other users. The developer has an issue here because they've designed the box with the expected input in mind. They haven't considered that the user isn't bound by their expectations. If the user tells the box that their name is "Steve", that's what will appear on the next page. If the user says their name is "<img>link to an image</img>" there's going to be an image on the next page because the browser reads those tags as instructions to display an image.
The real trouble comes when the user says their name is "<script> some malicious code </script>" and this data is dropped into the next page and then interpreted as code to execute. If this is setting your name for a blog or a forum, all users who can see your name have this code executed by their browsers all.
Sometimes the buttons on a blog which tell it to post are coded in JavaScript. If the user can execute script in your browser, they can tell your browser to activate these buttons.
Sometimes the buttons on a blog which tell it to reset your password are coded in JavaScript and suddenly everyone who visits the forum has their password reset.
So is cross site scripting the new sql injection now that a lot of people have a handle on that?
I think cross site scripting has hit enough blogs and forums that developers are pretty aware of it, even if they're not entirely aware of every way the issue can emerge from their code. There are a lot of noble attempts to sanitise input to remove anything that might be interpreted as instructions for the browser, but Pratchett said it best with "Ninety percent of most magic merely consists of knowing one extra fact" which is all an attacker needs to have to thwart your defences.
It's starting to become understood that perfect defence of a system is not possible and all over infosec people are assuming compromise has occurred and putting their focus into detection and mitigation.
I think the new SQL injection is XPath injection, which seems to be becoming more popular and is basically a variation on the same concept.
A bit of background:
XPath is a query language for retrieving data from XML. XML to store login information might be structured like this:
(http://www.soapui.org/images/stories/functionaltesting/xpathInjection_example_part1.png)
So to check whether login input (the stuff you provide in the login form) matches anyone the site knows about, you might supply the following "//user[name/text()='" + request.get("username") + "' And password/text()='" + request.get("password") + "']";
This looks at every user in the database and checks whether the user supplied input matches both the username and the password for any valid user. The addition symbols in this query concatenate terms, so what we wind up with is name/text()="whatever you supplied as username" and password/text()="whatever you gave as your password". Each of these will come back as either true or false depending on whether the supplied values match what's in the database.
"And" is a logical operator which makes the entire statement true only if both expressions are true.
You have a login form using this code to authenticate users. The user gives "Alice" as their username as "password123" as their password. This code will iterate through the database and come up "false" for every entry because none of them match. One of them has the right username but the password is different, so the query as a whole doesn't match. It's asking each of the entries on record whether name="Alice" AND password="password123"
However, if you supply this query with username "Whateveryoulike" and password "fakepassword' or 'a'='a" you automatically get in. This is because when you add this to the original query what you wind up with is:
//user[name/text()='Whateveryoulike' And password/text()='fakepassword' or 'a'='a'];
First it will check whether the username matches. It doesn't, so you've got FALSE AND password/text()='fakepassword' or 'a'='a'].
It's going to use a shortcut here and not check the password because it knows that the AND operator won't ever pass if one of the values is false, so that entire "username matches AND password matches" expression evaluates to false, so now we have:
FALSE OR 'a' = 'a'.
OR is another logical operator but this one will pass if either side evaluates to true. 'a' does equal 'a', so the expression as a whole passes. Essentially what you've done is injected your own query into the existing one and redefined the test for whether a user is valid or not to say that a user is valid if either of the following is true:
a) Username and password match
b) 'a' is the same as 'a'.
A lot of people assume that serialised data (data formatted to be easier to transport between systems, basically) is totally safe to work with and because XML is a fairly simple expression of data, they don't protect it as well as they would a more serious looking database.
XPath 2 is a less used but more modern standard which is actually advanced enough that you can inject into it instructions to open files on the server, which can lead to passwords to the machine being disclosed and the machine itself being totally compromised.
Tech stuff in this post got fairly heavy in some places, so I'm happy to go into things further if anyone wants.
As a reminder to myself, things I am intending to post in this thread in future include:
Information about baseband hacking. Phone operating systems like Android and iOS are pretty advanced. They're good at drawing pretty menus on the screen and handling a whole lot of connected but separate functions like your contacts and clock and snapchat but they're too far away from being binary instructions to efficiently manage communication over radio. Communicating with a cell tower is a very precise interaction and so has to be controlled at a very low level by an entirely separate operating system which is effectively a little black box inside your phone. Android and iOS send signals to it and it sends signals back but very few people know what happens inside it.
Recent research indicates that way down deep in your phone is a mysterious bug-ridden operating system, unexploited because it only listens to cell towers and the source code has only been seen by a select few... but dropping hardware costs and open source cell tower software is starting to make it possible to interact with this part of the phone, using undocumented and poorly understood protocols to tell every cellphone in the area to turn on its microphone, forward all calls, send SMS or execute arbitrary code at a very low level.
Also, more stuff about serialisation formats. JSON, XML, YAML. All designed to make data portable but the parsers and readers which take them and turn them into usable data are much too clever. These parsers contain little known features which mean they're all too happy to execute code supplied to them by users in ways that most developers don't know to be possible.
Can you talk a little about man in the middle attacks on cell phone data? I know that they're a thing but I'd like a little more detail.
Why is our utility and security infrastructure ("our" in my case being the United States) accessible through the Internet at all? Has humankind forgotten that computers can be built to work without being accessible to four billion random humans over a wild west frontier network where no one has ever had a good intention ever?
It honestly strikes me as collusion with hackers in a new world order way, which sucks because all that is nonsense and is not what's going on, meaning I actually have no clue as to why this is so.
Quote from: Q. G. Pennyworth on November 16, 2013, 02:55:56 PM
Can you talk a little about man in the middle attacks on cell phone data? I know that they're a thing but I'd like a little more detail.
Do you mean man in the middle attacks targeting a cell phone's connection to the internet or its connection to anything? Typically if comyou want to intercept a phone's connection to its provider, you need to make an unauthorised cell tower with a stronger signal to the legitimate one. Phones are designed to connect to the strongest signal, so if a local cell tower is set up, it'll connect to that giving an attacker the opportunity to view/modify that communication before forwarding it on to the real tower.
From what I've seen, most phones carrier check consists of nothing more than a simplified vpn style connection back to the mast.
Creating something people could connect to would be relatively simple, getting it to seamlessly forward and spoof that traffic came from that person, and then to receive and return the responses would be the hard part. I'm not sure how easy it is to spoof a sim, I can't imagine it's that bad though.
Quote from: Pæs on November 17, 2013, 12:16:22 AM
Quote from: Q. G. Pennyworth on November 16, 2013, 02:55:56 PM
Can you talk a little about man in the middle attacks on cell phone data? I know that they're a thing but I'd like a little more detail.
Do you mean man in the middle attacks targeting a cell phone's connection to the internet or its connection to anything? Typically if comyou want to intercept a phone's connection to its provider, you need to make an unauthorised cell tower with a stronger signal to the legitimate one. Phones are designed to connect to the strongest signal, so if a local cell tower is set up, it'll connect to that giving an attacker the opportunity to view/modify that communication before forwarding it on to the real tower.
The local tower thing. What could theoretically be done with that traffic and how hard would it be?
I've got no practical experience in messing with cellular phone networks, mainly because it's difficult to play around there without detection or disrupting normal communications for people but as I understand the main roadblock to exploiting there has historically been the lack of documentation around how the network works and the high cost to buy the equipment required. Both of these roadblocks are being steadily broken through.
Mobile communication standards are something I'm looking to understand better at the moment, but I haven't seen any practical attacks yet. We're getting pretty close, though, and the impact of such an attack would be pretty severe because most of the attack vectors hit entire areas where suddenly EVERYONE has a compromised device.
Quote from: Q. G. Pennyworth on November 17, 2013, 02:04:36 AM
Quote from: Pæs on November 17, 2013, 12:16:22 AM
Quote from: Q. G. Pennyworth on November 16, 2013, 02:55:56 PM
Can you talk a little about man in the middle attacks on cell phone data? I know that they're a thing but I'd like a little more detail.
Do you mean man in the middle attacks targeting a cell phone's connection to the internet or its connection to anything? Typically if comyou want to intercept a phone's connection to its provider, you need to make an unauthorised cell tower with a stronger signal to the legitimate one. Phones are designed to connect to the strongest signal, so if a local cell tower is set up, it'll connect to that giving an attacker the opportunity to view/modify that communication before forwarding it on to the real tower.
The local tower thing. What could theoretically be done with that traffic and how hard would it be?
There are open source packages now which can be used to create a base station on about $2000 worth of equipment: http://openbts.org/
Basically if it's closer to you than your local cell tower, your phone can be convinced to use it instead. This is your calls and SMS and internet connection compromised but the baseband stuff I mentioned earlier makes this much more severe because the part of your phone that knows how to talk to the local tower will actually take all sorts of ridiculous instructions from it.
If the tower says "yo, turn on your microphone and tell me what's going on nearby", your phone is like "LOL K". If the tower says "Send an SMS to this expensive number" your phone is all "sure thing bro."
Would the SMS and phone calls and whatever be easily decoded by whoever's got the tower? I assume copying the data is a no-brainer, but is there any kind of encryption in place or is that shit floating plaintext in the ether?
As I understand, there's encryption in place for the radio link but the tower is the intended recipient, so it can read the message. The strength of the encryption differs between countries, some few countries require no encryption in this connection, while others are using crypto which is strong enough for this purpose. There's a limited amount of data being transmitted which makes attacking the encryption less viable.
If you're the base station, I believe you can require the phone to use no encryption, so it's game over at that point in any case.
With recent NSA/Snowden leaks about the NSA potentially compromising Internet encryption standards, is SSL/TLS still considered to be safe/not backdoored? If there are backdoors, how likely would it be that they would be in the implementing application vs in the SSL/TLS standard itself?
Basically, is SSL still theoretically secure against an organization like the NSA?
How in the hell would a virus on a windows vm jump to a linux host or vice versa?
Quote from: Pæs on November 16, 2013, 10:33:24 AM
I think cross site scripting has hit enough blogs and forums that developers are pretty aware of it, even if they're not entirely aware of every way the issue can emerge from their code. There are a lot of noble stupid attempts to sanitise input to remove anything that might be interpreted as instructions for the browser, but Pratchett said it best with "Ninety percent of most magic merely consists of knowing one extra fact" which is all an attacker needs to have to thwart your defences.
It's starting to become understood that perfect defence of a system is not possible and all over infosec people are assuming compromise has occurred and putting their focus into detection and mitigation.
It is possible to sanitize input: HTML encode all user input before putting it in a browser, XML escape all user input before putting it in XML, etc. Every modern language has a nice simple built in function to do this for you correctly. But instead, every single developer things "Oh, I'll just take out <script> tags and we'll be fine" AND GUESS WHAT THAT DOESN'T WORK MORON. ARRRRRG.
<ScrIPt>
< script>
<scr ipt>
<scr\ipt> (forget which browser this works in)
<script> ('s' is 0x115 in Unicode)
<script>
<img src="IsMaliciousScriptNotActuallyPictureLOL.js" /> (for some old, buggy browsers cough cough IE cough cough)
<img onload="<script goes here>" />
<a ref="http://site.with.malware.example" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%; z-index: 1000000000;">
<object>
<meta>
ad infinitum.
Plus you have to know every single browser rendering / parsing quirk - older versions of IE let you put script instead of images, and it would actually run them. And that includes quirks of browsers that haven't been invented yet - if your users have a coffeescript plugin then <coffee> tags will work on them, etc.
Or you might just use TinyMCE for your user text input needs. TinyMCE is an HTML editor in HTML, and guess what? It lets people write HTML, including embedding Flash, Java applets, ActiveX controls, whatever scripts they want, redirects to other sites etc etc etc. The Pagan Place used TinyMCE in its forum software, and yes, I verified that it has script injection vulnerabilities.
Sorry, this is a little of a sore point with me. About ~2 years ago we found a pretty gaping script injection in some software my company uses. For about 3 months their most junior dev would tell me he'd fixed it and I would do a quick google search and "one more fact" them and tell them to do it properly instead. After I showed them the unicode character escape they just started ignoring me.
Quote from: Mome Papess Trivial on November 17, 2013, 04:33:08 AM
How in the hell would a virus on a windows vm jump to a linux host or vice versa?
Exploiting a bug in the VM.
Quote from: PopeSlag on November 16, 2013, 04:43:04 PM
Why is our utility and security infrastructure ("our" in my case being the United States) accessible through the Internet at all? Has humankind forgotten that computers can be built to work without being accessible to four billion random humans over a wild west frontier network where no one has ever had a good intention ever?
It honestly strikes me as collusion with hackers in a new world order way, which sucks because all that is nonsense and is not what's going on, meaning I actually have no clue as to why this is so.
So if a power line shorts, engineers can configure the nearby lines to route the load around it from their office in realtime, rather than having to send guys out into a hurricane to fix it. If enough power lines short you need to turn down the various power plants in the area to avoid overloading the whole grid. They could build a dedicated, secure network for it... but we're talking about an industry that is still being outwitted by squirrels and tree branches.
The larger problem is that nobody ever, ever, ever invests until security until they absolutely have to. The incentives just aren't there, especially if you can pass all the costs of an attack onto someone else.
Quote from: Remington on November 17, 2013, 03:20:36 AM
With recent NSA/Snowden leaks about the NSA potentially compromising Internet encryption standards, is SSL/TLS still considered to be safe/not backdoored? If there are backdoors, how likely would it be that they would be in the implementing application vs in the SSL/TLS standard itself?
Basically, is SSL still theoretically secure against an organization like the NSA?
Yes.*
The NSA had to work very hard to get data that was protected by SSL/TLS. They siphoned a ton of user contacts information from Yahoo! by tapping cables. They got much, much less of that same type of data from GMail, because GMail has users use SSL by default. They actually man in the middled a Google datacenter to bypass their SSL.
You might have seen this slide:
(http://www.telecoms.com/wp-content/blogs.dir/1/files/2013/10/Google-Cloud-Exploitation.jpg)
It was easier for them to sabotage the servers that Google was using to encrypt things than it was to break the encryption.
The weak point in a communication secured with SSL/TLS is everything except the SSL/TLS part. Malware on your computer**, malware on the server, stolen SSL certificates.
*SSL/TLS is a protocol for for two computers to agree on an encryption scheme, not encryption itself. Some of the older encryption algorithms are starting to show weaknesses, so those specific algorithms should be deprecated, but that doesn't affect TLS as a whole.
**Encryption makes it impossible to cache things, which makes thing slow. If you're an IT guy at a company and you have 1000 people hitting the same encrypted external website 100 times a day, you have to make 100,000 requests. If you cache it, you only have to make 1. But if you let the browser and the external server encrypt things, you can't tell when someone is making a duplicate request. So a lot of networks will actually man in the middle themselves to improve performance, by doing all encryption stuff at the point where the internal network connects to the internet. This includes some smartphone networks / browsers, where bandwidth is at a premium. You need less infrastructure, and it only comes at the expense of your user's security!
Yeah, what GA said! Thanks for joining in the thread GA!
Typically, even when the crypto is weak, it's going to be easier for the NSA (or any other attacker) to just bypass the crypto and install malware to take your data before encryption or after decryption.
Edit: I recently attended a talk by crypto heavyweight Peter Gutmann which addressed a lot of the NSA stuff. I'll try and find the slides from it, otherwise will summarise from memory.
Quote from: Golden Applesauce on November 17, 2013, 04:50:43 AM
Quote from: Mome Papess Trivial on November 17, 2013, 04:33:08 AM
How in the hell would a virus on a windows vm jump to a linux host or vice versa?
Exploiting a bug in the VM.
This or exploiting a feature, like shared folders between VM/host or VM access to network + network's access to host.
Some VM escapes are based on that old chestnut input sanitisation, allowing code running on the VM to refer to files on the host.
Quote from: Golden Applesauce on November 17, 2013, 05:18:02 AM
Quote from: Remington on November 17, 2013, 03:20:36 AM
With recent NSA/Snowden leaks about the NSA potentially compromising Internet encryption standards, is SSL/TLS still considered to be safe/not backdoored? If there are backdoors, how likely would it be that they would be in the implementing application vs in the SSL/TLS standard itself?
Basically, is SSL still theoretically secure against an organization like the NSA?
Yes.*
The NSA had to work very hard to get data that was protected by SSL/TLS. They siphoned a ton of user contacts information from Yahoo! by tapping cables. They got much, much less of that same type of data from GMail, because GMail has users use SSL by default. They actually man in the middled a Google datacenter to bypass their SSL.
You might have seen this slide:
(http://www.telecoms.com/wp-content/blogs.dir/1/files/2013/10/Google-Cloud-Exploitation.jpg)
It was easier for them to sabotage the servers that Google was using to encrypt things than it was to break the encryption.
The weak point in a communication secured with SSL/TLS is everything except the SSL/TLS part. Malware on your computer**, malware on the server, stolen SSL certificates.
*SSL/TLS is a protocol for for two computers to agree on an encryption scheme, not encryption itself. Some of the older encryption algorithms are starting to show weaknesses, so those specific algorithms should be deprecated, but that doesn't affect TLS as a whole.
**Encryption makes it impossible to cache things, which makes thing slow. If you're an IT guy at a company and you have 1000 people hitting the same encrypted external website 100 times a day, you have to make 100,000 requests. If you cache it, you only have to make 1. But if you let the browser and the external server encrypt things, you can't tell when someone is making a duplicate request. So a lot of networks will actually man in the middle themselves to improve performance, by doing all encryption stuff at the point where the internal network connects to the internet. This includes some smartphone networks / browsers, where bandwidth is at a premium. You need less infrastructure, and it only comes at the expense of your user's security!
Very thorough, thanks for the reply!
One extra bit about encryption and the NSA:
Encryption increases the time it takes to figure out the fuck you just said. Since the infrastructure is being put in place to make it possible to capture and store that encrypted data basically forever, and computing power keeps increasing, it's possible that encrypted data could be broken into 5 or 10 years from now and used to fuck you over.
From working with the electric grid here, I've discovered they are pretty security concious which is a relief. They avoid networking any system they can. Even routine things like meters don't report back via TCP, it's all old analogue signals and even if you were to tap into that it's all meaningless unless you understand the protocol they are using.
I'd hope the water and gas are similar.
Quote
So if a power line shorts, engineers can configure the nearby lines to route the load around it from their office in realtime, rather than having to send guys out into a hurricane to fix it. If enough power lines short you need to turn down the various power plants in the area to avoid overloading the whole grid. They could build a dedicated, secure network for it... but we're talking about an industry that is still being outwitted by squirrels and tree branches.
The larger problem is that nobody ever, ever, ever invests until security until they absolutely have to. The incentives just aren't there, especially if you can pass all the costs of an attack onto someone else.
I see no reason that the computer network which handles this has to be the Internet. It makes no sense.
Paes/anyone really:
Can I get some facts (or speculations) about how viruses and other malware is/is likely to be affecting cell phones?
I'm guessing that with the rise of app stores and indie developers, there's got to be a couple of popular games or something that are basically phone malware in disguise? I've got a feeling that there's going to be a massive story within a few years that "popular game A" is little more than a data harvesting tool. Moreso than the current Zinga and similar offerings.
Also:
QuoteBasically if it's closer to you than your local cell tower, your phone can be convinced to use it instead. This is your calls and SMS and internet connection compromised but the baseband stuff I mentioned earlier makes this much more severe because the part of your phone that knows how to talk to the local tower will actually take all sorts of ridiculous instructions from it.
If the tower says "yo, turn on your microphone and tell me what's going on nearby", your phone is like "LOL K". If the tower says "Send an SMS to this expensive number" your phone is all "sure thing bro."
Would it be reasonable to speculate that this is exactly what was going on with the UK's fuckup in Germany recently?
More questions later.
There's a lot of keyloggers on cracked apps cydia on rooted iphones and similar for android and have been for a good while. Hearing a bit about browser high jacking on both but not sure what it's beeing used for yet.
The Facebook app while not strictly malware goes beyond it's remit as an app. It bypasses the updating from the app store and updates itself directly from facebook.
There's a load of nasty shit it will do if you misconfiguration it on set up; It will try have access your contacts and photos and make itself the default program for opening a lot of file types. which you can deny but there's some things that it explicitly puts outside your control such as notifications and push and background idling processes. Even if you have forbidden every kind of push things like friend requests still raise events.
QuoteThe Facebook app while not strictly malware goes beyond it's remit as an app. It bypasses the updating from the app store and updates itself directly from facebook.
Thanks Faust, that's added yet another level of personal aversion to facebook in all it's forms.
I assume these glitches and inappropriate access are at least somewhat intentional. There's little point running a data harvesting operation if you let people opt out easily.