Blog Archives

Browsers’ anti-phishing protections easily defeated

nature__by_pichieart-dce0yeh

While troubleshooting a user’s mac the other day, I happened to come across a curious line in one of the logs:

Screen Shot 2018-06-11 at 16.28.05

After a bit of digging, it occurred to me that this and the other flags being sent in the process command were possibly Preferences or Settings in the Chrome.app. Looking at chrome://settings/privacy revealed, of course, Google’s phishing and malware protection setting, ‘Protect you and your device from dangerous sites’.

Here it is set to ‘On’, which is the default setting:

Screen Shot 2018-06-11 at 16.31.28

A quick test proved that setting it to ‘Off’ produced the `—disable-client-side-phishing-detection’ flag in the browser’s process output. Setting it back to ’On’ and relaunching the browser produced no output, confirming my theory. 

Screen Shot 2018-06-11 at 16.40.39

A quick message to my user also confirmed that he wasn’t aware that phishing protection had been disabled, and to the best of his memory, had not been disabled by himself. 

A simple preference setting
That got me to wondering whether that setting could be turned off programmatically by another, possibly malicious, process. To my surprise, it turns out that it’s trivial to do so. 

All Chromium browsers have a Preferences file located in their Application Support folder. Usually this is within another folder called ‘Default’, but not always. Chrome and Vivaldi, for example, have it there, but Opera (and Opera Developer) store the Preferences file at the root level of their respective support folders. 

The file contains the setting for whether the Phishing protection should be enabled or not. To determine how the preference was encoded in the file, I made a copy of the current Preferences file, toggled the setting, then made another copy. BBEdit’s ‘Find Differences’ function quickly told me the name of the key (if you don’t have BBEdit, you can also use Xcode’s FileMerge to run diffs, though it isn’t as pretty or as full-featured):

Screen Shot 2018-06-11 at 16.56.36

Again, there are differences among browsers. As shown above, Opera uses the key “fraud_protection_enabled” which takes a boolean. Chrome and Vivaldi, on the other hand, use a “safebrowsing” key which takes an array of key-value pairs, with the first item of the array being the key “enabled:”, and taking a bool for its value, like this:

Vivaldi:

"safebrowsing":{"enabled":true,"unhandled_sync_password_reuses":{}}

Chrome:

"safebrowsing":{"enabled":true,"scout_group_selected":true,"unhandled_sync_password_reuses":{}}

With this information, it’s a pretty simple thing for another process running under your username to write to the Preferences file and turn off the built-in protections. 

What about Safari?
Safari isn’t vulnerable to quite the same tactic as it doesn’t store its preferences in the same way. However, it’s even easier to defeat Safari’s ‘Warn when visiting a fraudulent website’ setting:

Screen Shot 2018-06-11 at 17.44.08

Apple hardened some of Safari’s preferences (like setting the Home page) some time ago to stop adware from making unauthorised changes, but this one is still unprotected in the current public release of macOS High Sierra. A one-liner in Terminal removes the preference:

defaults write com.apple.Safari WarnAboutFraudulentWebsites 0

Screen Shot 2018-06-11 at 18.04.48

What can you do?
The ease with which these protections can be surreptitiously turned off in all major browsers is a worry. And let’s face it, who would notice if this setting was quietly turned off? In both Chrome and Safari, the change takes effect immediately and does not even require a restart of the browser.

Fortunately, my shareware app DetectX Swift will warn you if browsing protection is off when you run a search and prompt you to turn it back on. To ensure that all insecure pages have been removed after turning the setting back on, DetectX Swift will continue to show the warning until you restart the browser and execute another search.

Screen Shot 2018-06-14 at 12.24.44

The protection covers all the browsers mentioned above. If you’re running some other browser and would like to know if it’s similarly vulnerable, drop a line in the Comments or contact Sqwarq Support and request support for your browser to be added.

Stay safe, folks! 😀

 

Featured pic: Nature by PichieArt

defending against EvilOSX, a python RAT with a twist in its tail





Intro
EvilOSX is a malware project hosted on GitHub that offers attackers a highly customisable and extensible attack tool that will work on both past and present versions of macOS. The project can be downloaded by anyone and, should that person choose, be used to compromise the Macs of others.

What particularly interested me about this project was how the customisation afforded to the attacker (i.e., anyone who downloads and builds the project, then deploys it against someone else) makes it difficult for security software like my own DetectX Swift to accurately track it down when it’s installed on a victim’s machine.

In this post we’ll explore EvilOSX’s capabilities, customisations, and detection signatures. We’ll see that our ability to effectively detect EvilOSX will depend very much on the skill of the attacker and the determination of the defender.

For low-skilled attackers, we can predict a reasonably high success rate. However, attacker’s with more advanced programming skills that are able to customise EvilOSX’s source code to avoid detection are going to present a bigger problem. Specifically, they’re going to put defenders in an awkward position where they will have to balance successful detection rates against the risk of increasing false positives.

We’ll conclude the discussion by looking at ways that individuals can choose for themselves how to balance that particular scale.



What is it?
EvilOSX is best described as a RAT. The appropriately named acronym stands for remote access trojan, which in human language means a program that can be used to spy on a computer user by accessing things like the computer’s webcam, microphone, and screenshot utility, and by downloading personal files without the victim’s knowledge. It may or may not have the ability to acquire the user’s password, but in general it can be assumed that a RAT will have at least the same access to files on the machine as the login user that has been compromised.

Whether EvilOSX is intentionally malicious or ‘an educational tool’ is very much a matter of perspective. Genuine malware authors are primarily in the business of making money, and the fact that EvilOSX (the name is a bit of a giveaway) is there for anyone to use (or abuse) without obvious financial benefit to the author is arguably a strong argument for the latter. What isn’t in doubt, however, is that the software can be readily used for malicious purposes. Irresponsible to publish such code? Maybe. Malicious? Like all weapons, that depends on who’s wielding it. And as I intimated in the opening section, exactly how damaging this software can be will very much depend on the intentions and skills of the person ‘behind the wheel’.



How does it work?
When an attacker decides to use EvilOSX, they basically build a new executable on their own system from the downloaded project, and then find a way – through social engineering or exploiting some other vulnerability – to run that executable on the target’s system.

There is no ‘zero-day’ here, and out of the box EvilOSX doesn’t provide a dropper to infect a user’s machine. That means everybody already has a first line of defence against a malicious attacker with this tool: Prudent browsing and careful analysis of anything you download, especially in terms of investigating what a downloaded item installs when you run it (DetectX’s History function is specifically designed to help you with this).

EvilOSX doesn’t need to be run with elevated privileges, however, nor does the attacker need to compromise the user’s password. As intimated earlier, it’ll run with whatever privileges the current user has (but, alas, that is often Admin for many Mac users). All the attacker needs to do is to convince the victim to download something that looks innocuous and run it.

Once run, the malicious file will set up the malware’s persistence mechanism (by default, a user Launch Agent) and executable (the default is in the user’s ~/Library/Containers folder) and then delete itself, thus making it harder to discover after the fact how the infection occurred.

After successful installation, the attacker can now remotely connect to the infected machine whenever both the client (i.e., victim) and server (i.e., attacker) are online.







Once the attacker has surreptitiously connected to the client, there are a number of options, including webcam, screenshots, and downloading and exfiltrating browser history.







In my tests, some of the modules shown in the above image didn’t work, but the webcam, screenshots, browser history and the ability to download files from the victim’s machine were all fully functional.



Customisation options
By default, EvilOSX will offer the attacker the option of making a LaunchAgent with a custom name – literally, anything the attacker wants to invent, or to use the default com.apple.EvilOSX.







That in itself isn’t a problem for DetectX Swift, which examines all Launch Agents and their program arguments regardless of the actual filename. The malware also offers the option to not install a Launch Agent at all. Again, DetectX Swift will still look for the malware even if there’s no Launch Agent, but more on this in the final sections below.

If configured, the malware installs the Launch Agent and, by default, points it to run a binary located at ~/Library/Containers/.EvilOSX. There’s no option for changing this in the set up routine itself, but the path to the program argument is easily modified if the attacker is willing to do some basic editing of the source code.







Making matters even more difficult is that with a little know-how, the attacker could easily adapt EvilOSX to not use a Launch Agent at all and to use one of a variety of other persistence methods available on OSX like cron jobs, at jobs and one or two others that are not widely known. I’ll forego giving a complete rundown of them all here, but for those interested in learning more about it, try Jason Bradley’s OS X Incident Response: Scripting and Analysis for a good intro.



String pattern detection
Faced with unknown file names in unknown locations, how does an on-demand security tool like DetectX Swift go about ensuring this kind of threat doesn’t get past its detector search? Let’s start to answer that by looking at the attack code that runs on the victim’s machine.

We can see what the attack code is going to look like before it’s built from examining this part of the source code:







As the image above shows, the structure and contents of the file are determined by the output_file.write commands. Before exploring those, lets just take a look at what the finished file looks like. Here’s the start of the file:







and here’s the final lines:







Notice how the first four lines of the executable match up with the first four output_file.write commands. There’s a little leeway here for an attacker to make some customisations. The first line is required because, as noted by the developer, changing that will effectively nullify the ability of the Launch Agent to run the attack code. Line 4, or some version of it, is also pretty indispensable, as the malware is going to need functions from Python’s os module in order to run a lot of its own commands. Line 3, however, is more easily customised. Note in particular that the output_file.write instruction defines how long the random key shall be: between 10 and 69 (inclusive) characters long. One doesn’t have to be much of an expert to see how easy it would be to change those values.

Line 5 in the executable is where things get really interesting, both for attacker and defender. As it is, that line contains the entire attack code, encrypted into gibberish by first encoding the raw python code in base64 and then encrypting it with AES256. That will be random for each build, based on the random key written at Line 3. We can see this in the next image, which shows the encrypted code from three different builds. Everything from the highlighted box onwards to the last 100 or so characters of the script are random.







However, as one of my favourite 80s pop songs goes, some things change, some stay the same. The first thing that we can note, as defenders, is that when this code is running on a victim’s machine, we’re going to see it in the output of ps. If you want to try it on your own machine, run this from the command line (aka in the Terminal.app):

ps -axo ppid,pid,command | grep python | grep -v python

That will return anything running on your Mac with python in the command or command arguments.

Of course, the victim (and yourself!) may well have legitimate Python programs running. To limit our hits, we can run the file command on each result from ps and see what it returns. Our attack code, being a single, heavily encrypted and extremely long line in the region of 30,000 characters, will return this indicator:

file: Python script text executable, ASCII text, with very long lines

That still isn’t going to be unique, but the test will futher narrow down our list of candidates. We can then use string pattern detection on the remaining suspects to see which contain the following plain text items,

  • import os
  • exec("".join(os.popen("echo
  • -md sha256 | base64 --decode")
  • readlines()))
  • We could arguably even include this:

  • U2FsdGVkX1
  • which occurs immediately after echo, but for reasons I’m about to explain, that might not be a good idea. Still, from the default source code provided by the developer, if we find all of those indicators in the same file, we can be reasonably certain of a match (in truth, there’s a couple of other indicators that I haven’t mentioned here in order to keep DetectX Swift one-step ahead of the attackers).

    Unfortunately for defenders, the attacker has a few workarounds available to them for defeating string pattern detection. To begin with, the attacker could adapt the code to use something other than base64, or indeed nothing at all. Similary, AES256 isn’t the only option for encryption. For these reasons,we can’t assume that we’ll find something like U2FsdGVkX1 in the malicious file. Then, there’s the original source code’s use of the long-deprecated os.popen. That is an odd choice to start with, and someone with a bit of experience in Python would be able to rewrite that line to avoid the telling indicators.



    Skill level and customisation options




    Advanced detection options
    At this point you may be feeling that the attacker holds all the cards, and to a certain extent that is true, but there are some positive takeaways. First, we can be fairly sure of catching the neophyte hackers (aka “script kiddies”) with little to no programming experience who are trying to hack their friends, school or random strangers on the internet. The motivation to adapt the code is probably not going to be there for a large number of people just doing it 4 the lulz.

    Secondly, depending on your tolerance for investigating false positives, and as I’ll explain how below, if you needed to be super vigilant, you could simply check on every python executable running on your Mac which file identifies as having ‘very long lines’. For sure, there are legitimate programs doing that, but the number still isn’t going to be that high on any given machine, and the paths to those legit programs are going to be readily identifiable. If security is of overriding importance, then it’s not much inconvenience, and time well spent.

    By default, DetectX Swift will find instances of EvilOSX running on a mac when it’s used out of the box, and when its used with a modified launch agent and executable path. It will also still find it when the attacker has made certain alterations to the source code. However, a determined attacker who chooses to rewrite the source code specifically to avoid string pattern detection is always going to be one-step ahead of our heuristics.

    We are not out of options though. You can still use DetectX Swift combined with the Terminal.app as a means to making custom detections as mentioned above. Here’s how:

    1. Launch DetectX Swift and allow it to search for the variations of EvilOSX it knows about. If nothing is returned, go into the Profile view.
    2. Click inside the dynamic profiler view, and press Command-F and type python into the search field.
    3. If there are no hits in the Running Processes section, you don’t have EvilOSX running on your machine.
    4. If there are any hits within the Running Processes section, make a note of each one’s command file path by selecting it in the view and pressing Command-C to copy it.
    5. Switch to the Terminal app, type file (with a space) and Command-V to paste. If the path has any spaces in it, surround it in single quotes. Then press return.
    6. If the path doesn’t come back with ‘very long lines’, the file isn’t EvilOSX.
    7. If it does, hit the up arrow on the keyboard to put the previous command back at the prompt, use Control-A to move the cursor to the beginning of the line, and replace the word file with cat (if you’re familiar with Vi or similar command line text editors use one of those instead). Hit return.
    8. Inspect the output from cat with the following in mind:

    9. Does the file end with readlines()))?
    10. Use command and the up arrow to go back up to the beginning of the file. How close does the file look to matching what you’ve seen here? Look for variations like import * from os and import subprocess.
    11. Consider the path that you pasted in. Is it something that looks like it belongs to a genuine program, or is it a completely unfamiliar? Anything that points to ~/Library and isn’t contained within a recognized application named folder should warrant further investigation.

    You’ll need to consider carefully the answers to 8, 9, & 10, with an emphasis on the latter, for each python file you tested to make an assessment. If you’re in any doubt, contact us here at Sqwarq and we’ll be glad to take a look at it and confirm one way or the other.



    Conclusion
    EvilOSX is just one of an increasing number of Python RAT projects that are appearing on the internet. It’s not particularly sophisticated, and this is both a strength and a weakness. With modest programming skills, an attacker can modify the source code to increase the chances of evading automated detections. However, vigilant users can still identify EvilOSX if they know what to look for, as explained in the preceding sections of this post, or by contacting Sqwarq support for free advice.

    Stay safe, folks! 🙂


    What’s the difference between DetectX and DetectX Swift?


    Since releasing DetectX Swift back in January, a lot of people have been asking me how the new ‘Swift’ version differs from the older one, aside from requiring 10.11 or higher (the original will run on 10.7 or higher).

    Well sure, it’s written in Swift — and it’s much swifter, literally, but of course there’s a lot more to it than that.

    I’ve finally had a spare moment to enumerate the feature list and create a comparison chart. Although the image above is essentially the same as the one you’ll see at the link address at the moment, there’s still a bunch of features to be added as we go through development of version 1. Thus, be sure to check the latest version of the chart to get the most up-to-date info.

    Of course, if you have any questions drop me a comment below, or email me either at Sqwarq or here at Applehelpwriter.

    Enjoy 🙂


    scan for malware on the command line

    Screen Shot 2017-12-20 at 19.23.50


    DetectX Swift now has the ability to do command line searches for issues on your mac like malware, keyloggers, browser hijacks and potentially dangerous software, and there’s a number of extra options that are not available when using the user interface. In this post, I’m going to give you a quick tour of the CLI (Command Line Interface) tool with some examples of how to use it (if you haven’t yet grabbed a free copy of DetectX Swift you might want to do that first to play along).

    1. Basic scan
    Let’s start with a basic scan. To use the CLI search, you need to specify the full path to the app executable. In this example, let’s suppose that the app is in /Applications folder. In that case, you’d need to execute this on the command line:

    /Applications/DetectX\ Swift.app/Contents/MacOS/DetectX\ Swift search

    Since that’s a bit of a handful, even using tab completion, you might want to edit your .bash_profile to include a shortcut alias. Here’s mine:

    sphil@sphils-iMac-5:~$ cat .bash_profile

    alias sudo='sudo '

    alias detectx='/Applications/DetectX\ Swift.app/Contents/MacOS/DetectX\ Swift'

    Note the sudo line (and note the extra space in the value). We’re going to need that so that we can pass the alias to sudo when we want to pass certain options to the search. Like…

    2. Scan other users
    Probably the most important benefit you gain with scanning on the command line rather than from the app’s interface is the ability to scan all, or selected, other users. You can search all users by using sudo and the -a option:

    sudo detectx search -a

    If you want to restrict the search to one or more users, the -u option allows you to specify a list of shortuser names (comma-delimited):

    sudo detectx search -u alice,bob

    3. Go deep
    If you’d like more verbose output, including how long the search took, try either the vsearch or vvvv commands:

    sudo detectx vvvv -a

    4. Save the results
    You can specify a path to output the results, either in regular text:

    sudo detectx vvvv -a ~/Desktop/searchtest.txt

    or, by passing the extra -j option, in JSON format:

    sudo detectx search -aj ~/Desktop/searchtest.json

    Here’s an example of what the formatted JSON file looks like:

    Screen Shot 2017-12-20 at 18.05.26

    5. Anything else?
    There’s a help command that will output the documentation to the command line, and also if you get into the habit of regularly running command line checks, don’t forget to launch the app from time to time in the Finder. Like its predecessor, DetectX, DetectX Swift does a lot of other stuff besides searching that can help track down and remediate problems with your mac, and a large part of that revolves around the way it tracks changes to your system every time you launch it. The CLI tool runs independently of that and won’t give you that kind of feedback or record those changes.

    Finally, note that in the release version of DetectX Swift, the CLI tool is only available for a limited period to Home and Unregistered users. Unlimited acccess to the CLI tool requires a Pro or Management license.

    Enjoy! 🙂


    DetectX Swift History

    DetectX Swift beta has arrived

    It’s been unusually quiet on Applehelpwriter these past few months, and the reason is that I’ve been devoting all my time and efforts to the new version of DetectX. The new version is called DetectX Swift because (yeah, you guessed it) I wrote it in Swift and because it’s considerably faster than its older sibling.

    DetectX Swift’s got a new interface, but there’s far more going on under the hood. The Search uses some fancy heuristics as well as hard-coded and live update search definitions to ensure it provides the very best in security threat scanning.

    The new Profile view employs some super cool dynamic highlighting and lets you inspect the contents not only of directories but also of scripts, plists and other files that could execute troublesome code on your mac.

    There’s changes in the History view, too, both in the display and functions. One of the coolest things I like about the new History function is that you can run a diff on any previous run against the latest run, immediately seeing how they differ.

    There’s tons more to DetectX Swift, but the best way to find out about it is just to try it. The beta version is free to use for both Home and Commercial users, so just head off over to its home page and grab yourself a copy!

    Don’t forget to keep us informed of how it goes. The beta is still in an early stage and more features are slated as it develops, but feel free to tell us about anything that you feel could be done better or things that you’d like to see added.

    Share and enjoy! 🙂

    how to reveal hidden users


    With malware big in the news again, and evidence that at least one malware variant that targets macOS creates hidden users on the victim’s system, here’s a timely tip on how to check for unwelcome guests.

    For this tip, we’re going to use the Terminal, which you can find in the /Applications/Utilities folder. If you’re not a frequent visitor to the land of the command line, you might want to see my 3-part series “Learning the Terminal”.

    Regardless, the first thing we’re going to do in Terminal is about the simplest command you’ll ever type: w. Yep, type a single ‘w’ at the prompt and press return.





    The w utility is a very quick way to see who’s currently logged on to your system and to ensure that there’s no surprises. You should see a couple of entries for yourself: one as ‘console’ and one as ‘s***’. The first represents a login through the usual Desktop GUI login window; the second is there because you just logged into Terminal. Anybody else logged in either via the command line (like a potential remote user) or the GUI will show up here. Notice that on my machine, there’s another user called ‘Developer’ who hasn’t logged in using the GUI, but is logged in via a command line interface. Note that ‘w’ returns the full user name, not the short one.

    While the w utility will tell you if a hidden user is currently logged on, what if there’s a hidden user that isn’t active at the particular time you check? To look for those, we have a couple of options. First, we can use the dscl utility to list all users, and you might be surprised at how many there are:

    dscl . -list /Users

    Look to the end of that list where the names that don’t begin with an underscore start. ‘Daemon’, ‘Nobody’, ‘Root’ and ‘Guest’ are all standard system accounts, as are all those entries that begin with an underscore. Don’t worry about those. However, aside from those, you should only see names that you recognise. To make things a little easier, we can add another command to the dscl command to filter that list. Try this

    dscl . -list /Users | grep -vE ‘_|root|nobody|daemon|Guest’

    That should now only return the names of real users. There shouldn’t be any names in there you don’t recognise. In my example, I know the last three, but the first one ‘dev’ isn’t familiar to me. Note that unlike ‘w’, this command returns short user names, and that ‘dev’ looks very much like it’s the same account as ‘Developer’ that I saw earlier.




    However, what we have so far is a list of users, not a list of hidden users. To see specifically if any accounts are hidden, we need a longer command:

    defaults read /Library/Preferences/com.apple.loginwindow

    Normally, when there are no hidden users, this will return the contents of a property list file that may look something like this:

    {
    GuestEnabled = 1;
    OptimizerLastRunForBuild = 31898816;
    OptimizerLastRunForSystem = 168494592;
    SHOWFULLNAME = 1;
    lastUser = loggedIn;
    lastUserName = imackim;
    }




    That tells us that there’s no hidden users on this mac. How so? Because if there were it would return something very different, like this:





    We can see not only the list of hidden users, but also that the preference for hiding users has been set to ‘1’ (in plist syntax, ‘1’ means true and ‘0’ means false). Note again that unlike the dscl command above, this returns the account’s full name, not the short user name.

    If we’d like to ‘unhide’ that user, so the account appears in the login window GUI and in System Preferences’ ‘Users & Groups’ pane, we’ll need admin privileges. To do that, cut and paste the following into Terminal:

    sudo defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool NO

    Supply an admin user password at the prompt and hit ‘return’, but type slowly as the display doesn’t register your key presses, which makes it easy to fat finger your password.

    Next, we need to change the IsHidden key in dscl for that user, so

    sudo dscl . -change /Users/dev IsHidden 1 0

    In the above command, substitute my user’s shortname dev for the shortname of the user on your machine. The 1 0 is the old value (hidden) followed by the new value (unhidden). The line can be read as “change User dev’s IsHidden value from hidden to unhidden.”



    For the more advanced
    We can save ourselves some typing by putting much of this into a script so that we can run it whenever we want. If you’re not familiar with how to create and use bash scripts, take a look here.

    Our script will basically do the same as all the commands we listed above (except changing the prefs for Hide500Users) in one fell swoop, and there’s a couple of little twists that I’ll leave as an exercise for the reader to figure out. To save on the typing, you can copy the whole script from my pastebin here.



    The script’s output is illustrated in the shot at the top of this post.

    Enjoy! 🙂

    how to recover from OSX/Dok malware – updated





    Last updated: May 10th, 2017 to include Dok.B variant.

    There’s been a lot of drama the last few days over a new malware attack on macOS.

    There’s FOUR steps to removing the malware.

    1. Remove the installed files
    Both my apps, DetectX and FastTasks 2 will detect this malware, and remove the appropriate files. For those of you that like to do things by hand, here’s the list of things to look for. You may find some and not others. Any you do find need to be removed:

    ~/Downloads/Dok.zip

    ~/Downloads/Dok/Dokument/Contents

    ~/Library/Containers/.bella/Bella

    ~/Library/Containers/.bella/bella.db

    ~/Library/LaunchAgents/com.apple.iTunes.plist

    ~/Library/LaunchAgents/com.apple.Safari.pac.plist

    ~/Library/LaunchAgents/com.apple.Safari.proxy.plist

    /Library/Containers/.bella/Bella

    /Library/Containers/.bella/bella.db

    /usr/local/bin/SafariProxy

    /Users/Shared/AppStore.app

    You might also want to remove the dead ‘AppStore.app’ login item (if it’s still there) from System Preferences | Users & Groups | Login Items.


    2. Remove the network proxy redirecting your internet traffic
    Victims also need to remove the sneaky proxy that’s redirecting their internet traffic from System Preferences’ Network pane. While this can be done manually, it’s a lot of clicking, especially since you must do it for all services. Easier, then, to use this AppleScript. Note it will need an Admin password.

    Get the script from my pastebin (if you copy and paste from a webpage like this and the script won’t compile, get the source from pastebin).


    ###########################################################
    -->> ABOUT
    ###########################################################
    (*

    Phil Stokes -- 2017
    applehelpwriter.com
    sqwarq.com

    *)
    ###########################################################
    -->> DESCRIPTION
    ###########################################################
    (*

    Turn off the Automatic Proxy Configuration in Network System Preferences.

    *)
    ###########################################################
    -->> USAGE
    ###########################################################
    (*

    Requires Admin password.
    This script was developed primarily as part of a remedy for victims of OSX/Dok malware.

    *)
    ###########################################################
    -->> COMMANDS
    ###########################################################

    set services to paragraphs of (do shell script "networksetup -listallnetworkservices")
    set autoproxyURL to " 0.0.0.0"
    set autoproxySERVICE to ""
    repeat with i from 2 to (count of services)
    set autoproxySERVICE to item i of services as text
    do shell script ("networksetup -setautoproxyurl " & (quoted form of autoproxySERVICE) & autoproxyURL) with administrator privileges
    do shell script ("networksetup -setautoproxystate " & (quoted form of autoproxySERVICE) & " off") with administrator privileges
    end repeat

    ###########################################################
    #EOF

    If you’re not comfortable running AppleScripts, you can do it manually as shown in the screenshot below, but remember you need to go through and do the procedure for every one of your services (Ethernet, Wi-Fi, Bluetooth Pan, etc) individually.






    3. Remove the fake certificate
    Thirdly, you’ll want to get rid of the fake certificate in the System keychain. In Terminal, search to see if the ‘cert.der’ certificate file still exists:

    cd /tmp; ls -alF

    If you see ‘cert.der’ listed, then issue the following command in the Terminal window:

    security remove-trusted-cert -d /tmp/cert.der

    Then, go back to Terminal and do

    rm /tmp/cert.der

    If not, then try both this

    security remove-trusted-cert -D

    and check in Keychain Access.app by searching for ‘Comodo’ and looking for a certificate that has the fake Comodo serial number:
    00 EB 08 6A 4F 53 BE BA 4D.



    4. Remove permissive admin access set by the malware
    Back to Terminal for this one, and mind your typing. You don’t want to make any mistakes here…

    At the command line prompt, type

    sudo visudo

    and provide an Admin user name. You won’t be able to see what you type, so type slowly, but at least you get 3 goes at it.

    When you’ve got that in correctly, you should see the sudoers file, it’ll look something like this:





    Use the arrow key to move the cursor down to the beginning of the line that says

    %USER_NAME_HERE%  ALL=(ALL) NOPASSWD: ALL

    On your keyboard hit the ‘d’ key twice (i.e, type dd). The line should magically disappear*.

    Finally, type

    :wq!

    (that’s a semi-colon, a lowercase w, lowercase q and an exclamation mark) to save your changes and quit. That’s it!

    And with that, you should be done with OSX/Dok malware! 🙂



    *If anything went wrong in visudo, you can press the u key once to undo your last action (the ‘u’ key only undoes the last keyboard action, so if you press it twice it’ll undo the undo = redo, so beware!)


    news: DetectX v2.14 released

    Screen Shot 2016-02-14 at 23.03.29

    Yes, two in two days! We’ve added a Preference Pane since yesterday, and improved the performance of the search function. Note that the new Sparkle Vulnerability check we introduced in v2.13 is now off by default. It can be turned on from the Preference Pane (see above).

    Other changes are listed in the release notes.

    DetectX is still free, fully-functional, and without time-limit for home users. Available for download from here.

    🙂

     

    %d bloggers like this: