30 Jan 2018 @ 9:02 PM 

Software and computer security has always been a rather important topic. As our systems become more interdependent and connected- and we expose ourselves and our important information more and more, it is becoming even more important. Operating System and Software updates are issued to address security problems, and these security problems are given the utmost importance as users are urged to install them as soon as possible. Many Operating Systems- such as Windows 10, disable or restrict the ability to prevent updates (it seems to require Pro to adjust the settings to update only when the user initiates it, for example). This is considered by many to be a positive change; the idea being that this will prevent systems from being compromised through those security exploits.

And, certainly, that is true. Installing security patches will, obviously, prevent the exploits that they resolve from being exploited for malicious purposes. However I think the impact that those exploits have in terms of your typical end user have been overstated.

Based on my own experiences, I an animate that the vast majority of end-user malware infections are not perpetuated or contributed to in any notable way by the sort of issues resolved by security updates. Those updates are more applicable to servers, data centers, and corporate environments. For end-user PCs, it is seldom heard of to find a malware infection that was not caused in some way by trojan horse malware — something which the user explicitly downloaded and ran themselves which had the unintended side effect of releasing malware onto their system. Pirated software; game mods, “keygens”, and so on and so forth. Screensavers, greeting card executables, applications that disguise as images. Something as seemingly innocuous as an aftermarket Windows Theme could very easily contain an unwanted payload, and it won’t matter if the system is fully up to date or not if you allow it to install.

The Security Circus

I call the general concept of overstating those concerns the “security circus”. It infects certain styles of thinking and sort of makes itself a self-perpetuating concept over time. As an example scenario, a user may come to an IT repairperson with issues on their PC; it may be determined that those issues are caused by malware. the “security circus” contribution to this scenario could be that the repair person discovers that the system is out of date and missing a number of critical security updates. Because they have learned, over time, that security updates are critical and prevent infections, they may — and very often do — assume that the malware made it’s way onto the PC via that infection vector. Over time these occurrences pile up and that particular IT staff can state, without any intention of lying, that they have seen plenty of systems that were compromised by vulnerabilities, even though, realistically, they don’t actually know if the vulnerabilities were even responsible.

The “Acts” of this security circus seem to largely stem around Fear, Uncertainty, and Doubt being spread and manipulated. Coincidentally, I notice that oftentimes these efforts work in favour of a number of corporate interests. Forced OS Updates for example benefit the OS manufacturer, particularly as updates may very well provide any number of other pieces of software which provide “diagnostic” information which can be used by that company for marketing efforts. Security updates benefit security firms and security software vendors, who’s products are used to “prevent” the problems that are caused until they receive that critical patch to fix the issue, or who release security “scanners” which analyze and report whether a system is susceptible to the vulnerability.

Some recent security scares come to mind when I think about the “security circus”.

Wannacry

The Wannacry ransomware provides some good examples of the operation of this “security circus”. Articles and postings on the issue are often decidedly vague about the extent of the vulnerability that causes it, and often overstate it’s capability; users are urged to update as soon as possible, and in some cases I’ve seen it argued that the vulnerability allows the malware to be installed over the Internet.

The reality, however, is that Wannacry had a distribution method that could exploit a vulnerability in SMBv1 within a LAN in order to spread to another system that was accessible on a LAN from the infected system. This means that a network that has systems that is vulnerable will have those vulnerable systems spread the infection if one get’s infected, however, that “patient zero” cannot be infected remotely. Wannacry would still only be installed and infect a “patient zero” LAN system through some other infection vector. and that infection vector was almost certainly through trojan-horse malware of some description.

Which is not, of course, to understate that that is certainly a concern. If Little Jimmy runs an infected game mod installer, and their system get’s infected, Other vulnerable computers on the same network would eventually be compromised. However, I think the critical thing is not the security updates, but, in that scenario, the user education to avoid installing malicious software to begin with. In the scenario, for example, Why did Little Jimmy Trust the game mod installer? Should Little Jimmy even have user permissions to install software? What sort of education can be provided to allow users that have “vulnerable” habits to adjust those habits to avoid problems? Installing security Updates, Security software, firewall’s etc is, IMO, largely a way of avoiding that question, and unfortunately it pairs poorly because a user with “vulnerable” habits is often the sort who will happily disable their Anti-virus when say a game modification installer says it is a “false positive”, or who will happily give administrator permissions — if they can — to applications based in promised functionality.

Game “cheat” software often takes that approach, making a promise and then requesting elevation with that promise in mind is enough to convince some users to “take a chance”; thewse same “vulnerable” users are also susceptible to phishing scams or other things such as software programs stealing login information from say online accounts. A specific example of that would be for example simple applications which claim to “give op” to a Minecraft player. All you need to do is give your username and password! But of course it does not give you OP. Instead it simply E-mails your login information to a specified account. It doesn’t work, the user deletes the program, but perhaps never thinks about changing their login information because as far as they know the program just “didn’t work”. Until one day they cannot log in. Or, For MMOs, they suddenly find their character is poorly equipped or perhaps banned for activity because it was used for some nefarious in-game activity.

Speaking for myself, aside from the occasional Malwarebytes scan, I don’t run any sort of background AV software or firewall. In fact, I disable the built-in Windows software that provides those features. To my knowledge, I’ve not been infected in over 10 years.  And even then, what I was infected with, Virut/Sality, wasn’t being picked up by any Security software, even fully updated. Since then I’ve had systems that have lacked important security updates magically not be infected in the ways that the aforementioned “security circus” would have me believe. It seems — at least from where I am standing — that the implications of security vulnerabilities to your typical end-user system are vastly overstated, and the focus on those as a means to prevent people from getting infected may be a focus in the wrong area. Instead, Users should receive education such that their “vulnerable” habits can be eliminated or at the very least they can be made aware of them. Better education for computer systems in general can help as well; knowing the difference between an svchost.exe where it should be and an svchost.exe where it isn’t can make it possible to identify unwanted software even if any installed security software isn’t picking it up.

Spectre/Meltdown

Another topic of some interest that has taken the security world by storm is the Meltdown and Spectre prefetch cache security problems found in many Microprocessors (Meltdown being specific to Intel chips). These security concerns relate to an ability to access memory that would be otherwise unavailable by exploiting speculative cache behaviour. Meltdown involves writing carefully crafted machine language instructions in order to trick the speculative execution into providing access to small pockets of memory that would not otherwise be accessible; there are kernel-mode pages that are part of that applications virtual address space. Spectre functions similarly but requires those carefully crafted machine code instructions in order to try to perform various memory operations and carefully measure them in order to guess at the data found in certain areas of those kernel-mode pages within that processes virtual address space.

I feel, again, that the security circus has somewhat overstated the dangers involved with these security problems; in particular, it is too common to see statements that t his could be exploited through web-based code, such as Javascript, which itself would require escaping the Javascript sandbox which has wider security implications anyway. Additionally, it seems ot presume that this could be used to steal web or system passwords, when realistically it will only enable viewing tiny pockets of driver-related process memory. and things like ASLR could very easily mitigate any directed attack looking for specific data.

But, the reality hardly sells articles, and certainly doesn’t sell security software- which, I might add, by sheer coincidence tends to be either a sponsor or major advertiser for many of the wider publicized security publications. Coincidence, no doubt.

Posted By: BC_Programming
Last Edit: 31 Jan 2018 @ 07:51 PM

EmailPermalinkComments (0)
Tags
 24 Aug 2016 @ 10:32 PM 

User Account Control, or UAC, was a feature introduced to Windows in Windows Vista. With earlier versions of Windows, the default user accounts had full administrative privileges, which meant that any program you launched also had full administrator privileges. The introduction of UAC was an attempt to solve the various issues with running Windows under a Limited User Account to make the more advanced security features of Windows far more accessible to the average user. The effective idea was that when you logged in your security token, which was effectively “given” to any software you launched, would be stripped of admin privileges. In order for a process to get the full token, it would require consent, this consent was implemented via the UAC dialog, allowing users to decide whether or not to give or deny that full security token.

It was a feature that was not well received; users complained that Vista was restricting them, and making them ask for permission for everything- something of a misinterpretation of the feature and how it works, but an understandable one somewhat. Nowadays, it is practically a staple of Windows, being present in the default user accounts through 7, 8, and now 10. Even so, it has had some design changes over the years.

One interesting aspect of the UAC consent dialog is that it will differentiate between a “Verified”, or signed, executable, and an unsigned one, displaying slightly different designs based on the evaluation of the executable. A signed executable effectively includes a digital signature which is able to verify that the program has not been altered by a third party- so if you trust the certificate authority as well as the publisher, it should be safe.

Windows Vista

We start our tour, perhaps unsurprisingly, with Vista.

Vista_Verified

Vista UAC Dialog, shown for an executable with a verified signature.

Vista_Verified_expanded

Vista UAC Dialog, shown for an executable with a verified signature, after expanding the Details option.

When the executable is verified, we see a relatively straightforward request. Expanding the dialog, as shown in the second image, provides access to the application path; There is no way, within the UAC dialog, to inspect the publisher’s certificate- that needs to be checked via other means.

Interestingly, once we start looking at unverified executables, however, we see quite a different presentation:

Vista_Unverified

Windows Vista UAC Dialog displayed for a Unverified executable.

Vista_Unverified_expanded

Windows Vista UAC Dialog shown for an unverified executable, after expanding the details option.

Rather than the more subdued appearance as seen when the application is verified, the dialog displayed for an unverified application is more bold; the options are presented as TaskDialog buttons, and the entire dialog has a very “Task Dialog” feel; additionally, the colour scheme uses a more bold yellow. Interestingly, Expanding the “Details” really only adds in the file location to the upper information region. Kind of an odd choice, particularly since the UAC dialog will usually be on it’s own secure desktop and thus screen real-estate is not as valuable as it might otherwise be.

Windows 7

On Vista, elevation tended to be required more frequently and thus UAC dialogs were rather common for standard Windows operations. Users needed to give consent for many standard Windows tasks such as adjusting Windows settings. Windows 7 adjusted some of the default behaviour and it does not by default present consent dialogs for many built-in Windows operations. The design of the UAC dialog also was adjusted slightly:

Win7_Verified

Windows 7 UAC dialog on a verified/signed executable.

Win7_Verified_Expanded

Windows 7 UAC dialog on a verified executable, expanded.

For verified executables, the dialog is rather unchanged; The biggest changes we see are in the title copy “Windows needs your permission to continue” changes to an ask regarding whether the user gives permission to a particular program. The dialog now includes a hyperlink in the lower-right that takes you right to the UAC settings, and publisher certificate information is now available when the details are expanded.

Win7_Unverified

Windows 7 UAC Dialog for an unverified Program.

Win7_unverified_expanded

Windows 7 UAC dialog for an unverified program, expanded

The Unverified dialog is quite a departure from the Vista version. It takes it’s design largely from the “Signed” version of the same dialog; perhaps for consistency. It dumps the “TaskDialog” style presentation of the options, instead using standard Dialog buttons, as with the “Signed” Appearance.

 

Windows 8

Win8_Unverified

UAC dialog on Windows 8 for an unverified executable.

Win8_Unverified_expanded

UAC Dialog on Windows 8 for an unverified executable, expanded.

Win8_Verified

UAC Dialog on Windows 8 for a Verified executable.

Win8_Verified_Expanded

UAC Dialog on Windows 8 for a Verified executable, Expanded.

 

 

For the sake of completeness, I’ve presented the same dialogs as seen on Windows 8. There have been no changes that I can see since Windows 7, excepting of course that the Win8 Windows Decorator is different.

Windows 10

Win10_Nov_Unverified

UAC Dialog from the Windows 10 November Update, running an Unverified executable.

Win10_Nov_Unverified_Expanded

UAC Dialog from the Windows 10 November Update, running an unverified executable, showing details.

Win10_Nov_Verified

UAC Dialog running a Verified executable on the Windows 10 November Update.

Win10_Nov_Verified_Expanded

UAC Dialog from the Windows 10 November Update, running a Verified executable, showing Details.

 

Yet again, included for completeness, the UAC dialogs shown by Windows 10 in the November Update. These are again identical to the Windows 8 and Windows 7 version of the same, providing the same information.

 

This all leads into the reason I made this post- the Anniversary Update to Windows 10 modified the appearance of the User Account Control dialogs to better fit with UWP standards:

 

Win10_Anniversary_Unverified

Windows 10 Anniversary Update UAC dialog for an Unverified Executable.

Win10_Anniversary_Unverified_expanded

Windows 10 Anniversary Update UAC dialog for an unverified Executable, after pressing “Show Details”.

Win10_Anniversary_Verified

Windows 10 Anniversary Update UAC Dialog for a Verified application.

Win10_Anniversary_Verified_Expanded

Windows 10 Anniversary Update UAC Dialog for a Verified Application, after pressing Show Details.

 

As we can see, the Windows 10 Anniversary Update significantly revised the UAC dialog. It appears that the intent was to better integrate the “Modern” User Interface aesthetic present in Windows 10. However, as we can see, the result is a bit of a mess; the hyperlink to display certificate information appears for unverified executables, but in that case, clicking it literally does nothing. The information is presented as a jumble of information with no text alignment, whereas previously the fields were well defined and laid out. I’m of the mind that updating the dialog to UWP should have brought forward more elements from the original, particularly the information layout; The “Details” hyperlink in particular should be more clearly designated as an expander, since as it is it violates both Win32 and UWP Platform UI guidelines regarding Link Label controls. I find it unfortunate that parsing the information presented in the dialog has been made more difficult than it was previously, and hope that future updates can iterate on this design to not only meet the usability of the previous version, but exceed it.

 

 

 

 

Posted By: BC_Programming
Last Edit: 24 Aug 2016 @ 10:35 PM

EmailPermalinkComments (0)
Tags
 20 Jul 2012 @ 9:13 PM 

Gamers are an enterprisey bunch. You don’t give them enough X, so they go prodding around your game’s memory to try to give themselves more. Programs that have this purpose are called “Cheat engines”. Usually, how they work is a multi-step process.

  1. The obvious first step is for the cheater to decide what they want. Lives? More Gold? Maybe they want to up their players attack power?
  2. This is usually fairly easy, and you can usually tell the data type just by the amount of screen space reserved for a value. Though sometimes you just have to guess. Many cheat engines can search for values regardless of the actual data type, too.
  3. Now, the cheater looks for every value in the game’s memory that has the current value of the item they want to ‘hack’. The results will usually be collosal.
  4. In order to revise the search parameters, the gamer/cheater will now “change” that value somehow; by perhaps losing a life or getting a new one, getting more score, using a “attack upgrade” pill, or what-have-you. Armed with the new value, they can now tell the cheat engine program to show them all the values that were the old value before that have now taken on the new value. If they are lucky, this will be only one entry, and they can use the cheat engine and change it, and BAM they have the new value they hacked in.

The typical, and perhaps smartest way, to deal with this problem is to ignore it. A well architected game system will have any multiplayer values centralized on a server which means that a cheat engine will only mess around with a client of the game, and there are ways of checking for those hacked clients as well, (because they can give players a minor advantage). However it bears an interesting topic of discussion- how do you prevent this?

With some considerations, I have determined a method to do this- each time a value is assigned, generate a new random value, store that, and then only store a version of the original value that was encrypted. The idea being that the existence of the “actual” value- the value the cheater would be able to identify- is transient and only exists in limited scopes, making it nearly impossible to find the correct value to change, and even if they do find it, the method of encryption/hashing means they would need to know the corresponding algorithm and number in order to turn a new value they wanted and store it in memory so the Obfuscated class to which said value is associated will decode it properly.

The trouble with this method lies in the fact that it is anything but transparent, and requires copius code changes all over the place.

Enter Generics & Templates

Generics and Templates are the obvious solution to this problem. With C++, this sort of class nearly writes itself, actually; since templates are a compile time feature. you could then replace values that are int with something like Obfuscated and not have to change anything else.

Being that I work primarily in C#, however, this was the focus of my attentions. And it is not quite as simple, though thankfully the addition of dynamics to the language really helps make the code more concise for this sort of purpose.

Everything seems to work fine initially; you can create a generic class Obfuscated, then define operator methods that can cast a T to an Obfuscated and vice-versa without too many problems. problems start to arise as you realize that the original code is using operators and the implicit casts are not being performed (because there is no reason for the compiler to think that casting the two values from Obfuscated to the type T will make the operation valid). So you define operator overloads. The typical result in C# 3 was rather messy. Since there was no way to define a constraint that said to only allow arithmetic operators, nor is there an interface you could cast to to check if the Type T for which your generic instance was constructed supports arithmetic operators, you were left in the cold. For many types you could use the built-in operator methods themselves, op_Addition, op_Subtraction, etcetera. What you would end up with is a large else-if ladder that checked for all of the primitive types, with an else block that used reflection to call the appropriate operator method that way; and failing that throwing an InvalidOperationException.

Dynamics to the rescue, however. Thanks to C# 4.0’s addition of the dynamic keyword, which introduced late-bound variables, we can actually make the call relatively simple. we can perform operators on dynamic variables and the call will be resolved at run-time, and will be handled appropriately even for the primitive types.

With that out of the way, there was only one question left: the encoding. I decided on a simple interface that allowed to decode and encode a arbitrary set of bytes. I implemented a simple xor encryption and used that for my tests. The tricky portion is of course getting some arbitrary set of bytes representing a variable of your generic type; this isn’t something you can really force with constraints. You really need a Type T that is either a structure or a serializable value. For this purpose I created two general purpose generic methods:

First, the method to convert a given value of a Type P to a array of byte[]:

If it is a ValueType, we use the Marshaller to get the actual in-memory representation of the structure, copy it to a array of bytes of the appropriate size, and then return that. Otherwise, we try to save it to a MemoryStream using a BinaryFormatter, slurp out the contents of that memorystream, and return that array of bytes to the caller. The corresponding function that turns a given array back into the corresponding type is obviously just the reverse of this:

by replacing a variable of a given type T with an Obfuscated, you get almost completely transparent obfuscation of the in-memory representation of that type. Assignments result in the generation of a new random number, encrypt the passed value, and store the encrypted value, and retrieving the value or an implicit cast to the type will deobfuscate the value and return that.

The Full source to my test project which contains and uses this class is attached:
Memory Obfuscation Class

Posted By: BC_Programming
Last Edit: 20 Jul 2012 @ 09:13 PM

EmailPermalinkComments (0)
Tags
Tags: , , ,
Categories: .NET, C#, C/C++, Programming

 Last 50 Posts
 Back
Change Theme...
  • Users » 46989
  • Posts/Pages » 379
  • Comments » 105
Change Theme...
  • VoidVoid « Default
  • LifeLife
  • EarthEarth
  • WindWind
  • WaterWater
  • FireFire
  • LightLight

PP



    No Child Pages.

Windows optimization tips



    No Child Pages.

Soft. Picks



    No Child Pages.

VS Fixes



    No Child Pages.