Sophos UTM Home / Software Licensed IP Count Explained

May 18, 2015 By

For some users of the Sophos UTM running up to V9.3x at home using the very generous “home license”, the number of IP’s used against the allotted 50 is always a concern.  Some people have a hobby of collecting baseball cards, some fly model airplanes, and some construct an IT lab at home using Vmware’s ESX and hosting Sophos UTM with the Home license. Add a family with each member having from 2 to 4 devices, IOT, and 50 licensed IP addresses does not last long.  For this subset of users of the Sophos UTM, the question of “how long does an IP stay in the Active IP Addresses” and “what has to happen to get an IP address noticed (Read: added to the Active IP list)”.  I recently setup a few scenarios in my lab to answer this question.

How Does An IP Get Noticed?

From my testing, any time an IP address is processed on an interface on the UTM, the source/destination pair is logged in the accounting table. The UTM  uses a postgres database for its packet accounting. During debugging, all IP’s that are included that appear to be within the range of addresses defined in the objects on Interfaces & Routing -> Interfaces, then subtracting off the IP’s of the UTM interfaces. Only packets that have traffic, as a source or destination, within the last 7 days (from the time of the query), are included. Sophos access points and UTM interface IP addresses are subtracted off this list.

I ran some tests, where I setup a network and let the UTM handle DHCP services. I defined the scope to not include a gateway or DNS server settings. The device only received an IP and subnet mask. These devices were also included in the list of Active IP Addresses.

How Long Does An IP Stay Active?

As mentioned earlier, the packet level accounting is kept in a database. Based on the SQL query seen under the hood of the UTM, the query specifies a 7 day look back.

We Have A Guest Wifi Network – Any Tips On Lowering The IP Count?

If you have a guest wifi network and a large amount transit and short lived users, the user count can grow quickly. Imagine a House of Worship or other venue where the number of users have a quick but short lived peek. There is noting you can do to limit the number of IP’s added to the active list apart from “natting” that traffic behind another firewall, you can lessen the impact by making the DHCP lease time as short as the expected duration of that group’s visit. Lets look at an example.

Suppose a House of Worship holds two Sunday morning services and a Sunday night service and the lease is set for 24 hours (the default). Should they have 50 users at the first service, and 75 at the second, and 35 users for the evening service, 110 IP address would result in the Active list.  Now suppose the DHCP scope lease is set for 60 minutes. We would expect the Active list to top out at 75 users.

The DHCP lease time should not be made too short. If all the users have to renegotiate the IP too frequently, a lot of needless overhead would be created.

IOT, Printers, Cameras

How then does one prevent the IP addresses used on IOT, IP based cameras, and printers from burning one of the active IP address slots? It is not hard, but lets restate the question for clarity: How do you prevent ANY device that does not need to be on the internet from taking one of the Active IP address slots? Try one of the following:

  • Manually configure the IP settings on the device and do not include a “gateway of last resort”.
  • Use a DHCP server other than the UTM for your network, configuring the scope for these devices to not set a router.

Conclusion

Keeping the DHCP lease time short enough to prevent the build up of IP addresses in the Active list is one method of reducing the number of licenses for the home or software appliance installation, yet too short of lease creates a waste of resources and could inconvenience the user. Devices that do not need internet access can be configured such that the device has absolutely no interaction with the UTM. The bottom line is that it only takes one packet from a device to get listed in the accounting database, and it is from that database that the UTM checks when building the active ip list.

 

Filed Under: Case Studies, HowTo, Security Tagged With: , , , , , , ,

VU#932044: Choice Wireless Green Packet 4G WiMax modem vulnerability

June 28, 2013 By

Vulnerability Note VU#932044

Choice Wireless Green Packet 4G WiMax modem vulnerability

Original Release date: 28 Jun 2013 | Last revised: 28 Jun 2013

Overview

Choice Wireless Green Packet 4G WiMax modem, model number WIXFMR-111, fails to properly validate ajax requests allowing a remote unauthenticated attacker to view system configuration information or possibly execute commands on the device.

Description

It has been reported that Choice Wireless Green Packet 4G WiMax modem, model number WIXFMR-111, contains a web interface which is listening on both the LAN and WAN side that allows administrators to view or modify the configuration of the device. This web interface fails to properly authenticate ajax requests, allowing a remote unauthenticated attacker to view system configuration information or possibly execute commands on the device.

Example ajax requests include:

    Request to http://<device ip>/ajax.cgi?action=wmxState will provide the current status of the WiMax connection.
    Request to http://<device ip>/ajax.cgi?action=netState will provide detailed information about the current network status, including LAN and WAN IP addresses, interface MAC addresses, etc.
    Request to http://<device ip>/ajax.cgi?action=tag_ipPing&pip=1+%26%26+cat+%2Fetc%2Fsncfg%2Fwmx.cfg will list the device’s WiMax configuration, including username and password in plain text.

Impact

A remote unauthenticated attacker may view system configuration information or possibly execute commands on the device.

Solution

We are currently unaware of a practical solution to this problem.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Choice Wireless Affected – 28 Jun 2013

If you are a vendor and your product is affected, let
us know.

CVSS Metrics (Learn More)

Group Score Vector
Base 9.3 AV:N/AC:M/Au:N/C:C/I:C/A:C
Temporal 7.1 E:U/RL:U/RC:UC
Environmental 5.3 CDP:MH/TD:M/CR:ND/IR:ND/AR:ND

References

Credit

Thanks to Chris Meller for reporting this vulnerability.

This document was written by Michael Orlando.

Other Information

  • CVE IDs:
    CVE-2013-3581
  • Date Public:
    28 Jun 2013
  • Date First Published:
    28 Jun 2013
  • Date Last Updated:
    28 Jun 2013
  • Document Revision:
    11

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/932044

Filed Under: Security Tagged With: , ,

VU#704828: Lookout! Mobile Security contains a denial-of-service vulnerability

June 27, 2013 By

Vulnerability Note VU#704828

Lookout! Mobile Security contains a denial-of-service vulnerability

Original Release date: 27 Jun 2013 | Last revised: 27 Jun 2013

Overview

Lookout! Mobile Security version 8.14.1-7fe5f1, and possibly earlier versions, contains a denial-of-service vulnerability.

Description

Lookout! Mobile Security (version 8.14.1-7fe5f1) crashes if an intent is sent to com.lookout.security.ScanTell intent with no arguments.

Impact

A malicious application installed on the phone may be able to disable the Lookout! Mobile Security software.

Solution

Apply an Update

Lookout! Mobile Security version 8.17-8a39d3f has been released to address this vulnerability.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Lookout Affected 11 Jun 2013 27 Jun 2013

If you are a vendor and your product is affected, let
us know.

CVSS Metrics (Learn More)

Group Score Vector
Base 3.8 AV:L/AC:H/Au:S/C:N/I:N/A:C
Temporal 3.0 E:POC/RL:OF/RC:C
Environmental 2.3 CDP:ND/TD:M/CR:ND/IR:ND/AR:ND

References

Credit

Thanks to china.x.orion for reporting this vulnerability.

This document was written by Adam Rauf.

Other Information

  • CVE IDs:
    CVE-2013-3579
  • Date Public:
    27 Jun 2013
  • Date First Published:
    27 Jun 2013
  • Date Last Updated:
    27 Jun 2013
  • Document Revision:
    7

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/704828

Filed Under: Security Tagged With: , ,

VU#662676: Digital Alert Systems DASDEC and Monroe Electronics R189 One-Net firmware exposes private root SSH key

June 26, 2013 By

Vulnerability Note VU#662676

Digital Alert Systems DASDEC and Monroe Electronics R189 One-Net firmware exposes private root SSH key

Original Release date: 26 Jun 2013 | Last revised: 26 Jun 2013

Overview

Digital Alert Systems DASDEC and Monroe Electronics One-Net E189 Emergency Alert System (EAS) devices exposed a shared private root SSH key in publicly available firmware images. An attacker with SSH access to a device could use the key to log in with root privileges.

Description

The Digital Alert Systems DASDEC-I and DASDEC-II and Monroe Electronics R189 One-Net/R189SE One-NetSE are Linux-based EAS encoder/decoder (ENDEC) devices that are used to broadcast EAS messages over digital and analog channels. IOActive has reported several security issues affecting these devices. The most severe of these issues is the public disclosure of the default private root SSH key. The less severe issues could also contribute to an attacker’s ability to compromise a vulnerable device.

Compromised root SSH key (CVE-2013-0137)
Publicly available firmware images for these devices included a private root SSH key that was authorized to log in to the devices (CWE-798, CWE-321). The fingerprint for the compromised SSH key is 0c:89:49:f7:62:d2:98:f0:27:75:ad:e9:72:2c:68:c3. Although this key is not hard-coded, it may be impractical for less technical users to manually disable or change they key prior to firmware version 2.0-2.

Predictable session ID
IOActive reports that the administrative web server uses a predictable, monotonically increasing session ID. This finding is based on running the web server in a test environment. Testing on a variety of firmware versions on devices both at the factory and in the field, Monroe Electronics could not reproduce this finding.

Log information disclosure
Logs available via the web server provide a variety of information about the configuration, operation, and status of the device (CWE-532). Some of the log information is public and may be required by regulation.

Predictable password generation
The dasdec_mkuser script generates passwords in a deterministic way (CWE-341), however these passwords are not for administrative access, and the script is not used for general user account configuration.

Default password
Like many similar devices, the DASDEC and One-Net ENDECs use default administrative credentials. Some sites fail to change the default administrative password and allow unrestricted internet access.

Impact

An attacker with the private key and SSH access can log in to a device with root privileges.

Predictable session IDs could allow an attacker to take control of an existing administrative web session.

Predictable and unchanged default passwords can allow an attacker to log in to a device with root privileges. Devices exposed to the internet are at particularly high risk, for example, see Secure EAS Codecs Prevent Zombie Attacks and US-CERT Alert TA13-175A.

Logs may disclose configuration information that can benefit an attacker.

Solution

Apply an update

On April 24, 2013, Monroe Electronics and Digital Alert Systems released firmware version 2.0-2 that disables the compromised SSH key, provides a simplified user option to install new unique keys, and enforces a new password policy. Monroe Electronics has taken considerable effort to provide update information to DASDEC and One-NetSE users.

DASDEC users can obtain updated firmware and release notes by contacting <support@digitalalertsystems.com>. R189 One-Net users can contact <eas@monroe-electronics.com>.

Disable compromised SSH key

The compromised root SSH key should be disabled immediately, especially if the SSH service is exposed to untrusted networks such as the internet. If SSH connectivity is required, generate, install, and test new SSH keys before disabling the compromised key. The fingerprint for the compromised SSH key is 0c:89:49:f7:62:d2:98:f0:27:75:ad:e9:72:2c:68:c3.

Manually inspect SSH keys

To identify a compromised key, examine the authorized_keys file at /root/.ssh/authorized_keys2.dasdec and use the ssh-keygen command to show SSH key fingerprints. The following example shows the fingerprint for the compromised key:

$ ssh-keygen -l -f authorized_keys2.dasdec
1024 0c:89:49:f7:62:d2:98:f0:27:75:ad:e9:72:2c:68:c3 wood@endec1 (DSA)

Note that ssh-keygen only shows the fingerprint for the first key/line in the file. If authorized_keys2.dasdec contains multiple keys (multiple lines, one key per line), it will be necessary to extract each key (line) to a separate file and run the ssh-keygen command on each key/file. These shell scripts can be used to list and test multiple SSH keys in an authorized_keys file:

To generate new SSH keys, use ssh-keygen.

Restrict access

If for some reason you are not able to remove and replace the compromised SSH key, restrict access to the SSH service to highly trusted hosts and networks only. As a general good security practice, restrict access to all services to trusted hosts and networks.

Change default passwords

Change any default passwords, and do not deploy production systems without changing default passwords. Search engines like Shodan can index systems exposed to the internet and default passwords are usually documented and well-known. It is often trivial for an attacker to identify and access systems on the internet using default passwords.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Digital Alert Systems Affected 18 Jan 2013 24 Jun 2013
Monroe Electronics Affected 18 Jan 2013 24 Jun 2013

If you are a vendor and your product is affected, let
us know.

CVSS Metrics (Learn More)

Group Score Vector
Base 10.0 AV:N/AC:L/Au:N/C:C/I:C/A:C
Temporal 8.7 E:ND/RL:OF/RC:C
Environmental 6.8 CDP:LM/TD:M/CR:ND/IR:M/AR:ND

References

Credit

Thanks to Mike Davis and Cesar Cerrudo of IOActive for reporting these issues. Thanks also to Monroe Electronics for their efforts to contact affected users.

This document was written by Art Manion.

Other Information

  • CVE IDs:
    CVE-2013-0137
  • Date Public:
    24 Jun 2013
  • Date First Published:
    26 Jun 2013
  • Date Last Updated:
    26 Jun 2013
  • Document Revision:
    75

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/662676

Filed Under: Security Tagged With: , ,

VU#225657: Oracle Javadoc HTML frame injection vulnerability

June 18, 2013 By

Vulnerability Note VU#225657

Oracle Javadoc HTML frame injection vulnerability

Original Release date: 18 Jun 2013 | Last revised: 18 Jun 2013

Overview

Javadoc HTML pages that were created by Javadoc 7 Update 21 and before, 6 Update 45 and before, 5.0 Update 45 and before, JavaFX 2.2.21 and before contain a frame injection vulnerability that could allow an attacker to replace a Javadoc web page frame with a malicious page.

Description

Oracle Java Development Toolkit (JDK) contains a Javadoc toolkit that allows a developer to generate API documentation in HTML format from doc comments in source code.

Javadoc HTML pages that were created by Javadoc 7 Update 21 and before, 6 Update 45 and before, 5.0 Update 45 and before, JavaFX 2.2.21 and before contain JavaScript code that fails to parse scheme relative URIs parameters correctly. An attacker can construct a URI that passes malicious parameters to the affected HTML page that causes one of the frames within the Javadoc-generated web page to be replaced with a malicious page.

For additional information please see Oracle Security Advisory.

Impact

An attacker can cause one of the frames within a Javadoc-generated web page to be replaced with a malicious page. This vulnerability could be used for phishing or social engineering, or it could be used for browser exploitation if combined with another browser-related vulnerability.

Solution

Apply Update

Oracle has released June 2013 Java Critical Patch Update to address this vulnerability. Oracle Java Developers Toolkit (JDK) and Javadoc users are advised to apply June 2013 Java Critical Patch Update and regenerate and republish affected Javadoc HTML pages.

Fix-in-Place Fix Tool

Oracle has released a fix-in-place tool named Java API Documentation Updater Tool. This fix-in-place tool can process directories or folders to search for HTML files to be remediated without having to regenerate existing Javadocs. When presented directories/folders and their sub-directories or sub-folders the Java API Documentation Updater Tool will search for files with the following names:

  • index.htm
  • index.html
  • toc.htm
  • toc.html

For each file that matches the names noted above the Java API Documentation Updater Tool will search the file for the affected JavaScript text and replace it with the remediated version. Note that this tool will not detect Javadoc pages that have been renamed to something other than one of the above page names.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Oracle Corporation Affected – 12 Jun 2013

If you are a vendor and your product is affected, let
us know.

CVSS Metrics (Learn More)

Group Score Vector
Base 5.0 AV:N/AC:L/Au:N/C:N/I:P/A:N
Temporal 4.1 E:F/RL:OF/RC:C
Environmental 4.4 CDP:LM/TD:M/CR:ND/IR:ND/AR:ND

References

Credit

Thanks to Oracle for reporting this vulnerability.

This document was written by Michael Orlando.

Other Information

  • CVE IDs:
    CVE-2013-1571
  • Date Public:
    18 Jun 2013
  • Date First Published:
    18 Jun 2013
  • Date Last Updated:
    18 Jun 2013
  • Document Revision:
    25

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/225657

Filed Under: Security Tagged With: , ,

VU#422807: Adobe Reader and Acrobat memory corruption vulnerabilities

February 14, 2013 By

Vulnerability Note VU#422807

Adobe Reader and Acrobat memory corruption vulnerabilities

Original Release date: 14 Feb 2013 | Last revised: 14 Feb 2013

 

Overview

Adobe Reader and Acrobat 11.0.01 and earlier, 10.1.5 and earlier, and 9.5.3 and earlier contain memory corruption vulnerabilities.

Description

The Adobe security advisory APSA13-02 states:

Adobe has identified critical vulnerabilities (CVE-2013-0640, CVE-2013-0641) in Adobe Reader and Acrobat XI (11.0.01 and earlier), X (10.1.5 and earlier) and 9.5.3 and earlier for Windows and Macintosh. These vulnerabilities could cause the application to crash and potentially allow an attacker to take control of the affected system.

Adobe is aware of reports that these vulnerabilities are being exploited in the wild in targeted attacks designed to trick Windows users into clicking on a malicious PDF file delivered in an email message.
Adobe is in the process of working on a fix for these issues and will update this advisory when a date for the fix has been determined.

Additional details may be found in the full advisory APSA13-02.

Impact

A remote attacker may be able to cause a denial of service or execute arbitrary code on the system in the context of the user running the Adobe product.

Solution

We are currently unaware of a practical solution to this problem. Please consider the following workarounds.

Enable Protected View

Users of Adobe Reader XI and Acrobat XI for Windows can protect themselves from this exploit by enabling Protected View. To enable this setting, choose the “Files from potentially unsafe locations” option under the Edit > Preferences > Security (Enhanced) menu.

Use the Microsoft Enhanced Mitigation Experience Toolkit

The Microsoft Enhanced Mitigation Experience Toolkit (EMET) can be used to help prevent exploitation of this vulnerability. CERT/CC has created a video tutorial for setting up EMET 3.0 on Windows 7. Note that platforms that do not support ASLR, such as Windows XP and Windows Server 2003, will not receive the same level of protection that modern Windows platforms will.

Enable DEP in Microsoft Windows

Consider enabling Data Execution Prevention (DEP) in supported versions of Windows. DEP should not be treated as a complete workaround, but it can mitigate the execution of attacker-supplied code in some cases. Microsoft has published detailed technical information about DEP in Security Research & Defense blog posts “Understanding DEP as a mitigation technology” part 1 and part 2. DEP should be used in conjunction with the application of patches or other mitigations described in this document.

Note that when relying on DEP for exploit mitigation, it is important to use a system that supports Address Space Layout Randomization (ASLR) as well. ASLR is not supported by Windows XP or Windows Server 2003 or earlier. ASLR was introduced with Microsoft Windows Vista and Windows Server 2008. Please see the Microsoft SRD blog entry: On the effectiveness of DEP and ASLR for more details.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
Adobe Affected – 14 Feb 2013

If you are a vendor and your product is affected, let
us know.

CVSS Metrics (Learn More)

Group Score Vector
Base 9.3 AV:N/AC:M/Au:N/C:C/I:C/A:C
Temporal 8.8 E:H/RL:W/RC:C
Environmental 8.8 CDP:MH/TD:H/CR:H/IR:H/AR:H

References

Credit

This document was written by Jared Allar.

Other Information

  • CVE IDs:
    CVE-2013-0640
    CVE-2013-0641
  • Date Public:
    13 Feb 2013
  • Date First Published:
    14 Feb 2013
  • Date Last Updated:
    14 Feb 2013
  • Document Revision:
    7

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

via CERT Recently Published Vulnerability Notes http://www.kb.cert.org/vuls/id/422807

Filed Under: Security Tagged With: , ,

“security” via n8xja in Google Reader 2012-12-27 23:00:34

December 27, 2012 By

Computer security firm McAfee Labs released its annual Threat Predictions report today, taking a look at what we’ll see (and hope not to see) on 2013’s deck of malware and viruses. Interestingly, McAfee’s analysis predicts a decline in Anonymous’ attacks, a rise in the frequency and sophistication of mobile malware, and a rise in large-scale attacks that aim to cause as much destruction as possible.

This time last year, McAfee’s report for 2012 predicted that “Hacktivism and Anonymous will reboot and evolve.” While this year didn’t see anything on the level of the hacks of Sony and HBGary from 2011, Anonymous did execute a number of high-profile attacks and threats. Now McAfee says that in 2013, hacktivisim will be conducted by more homogeneous, politically-motivated groups rather than Anonymous’ pantheon of personalities and pet causes. Still, McAfee suggests that Anonymous may be able to stage a few high-visibility attacks in the coming months despite its predicted decline. The report reads:

Sympathizers of Anonymous are suffering. Too many uncoordinated and unclear operations have been detrimental to its reputation. Added to this, the disinformation, false claims, and pure hacking actions will lead to the movement’s being less politically visible than in the past. Because Anonymous’ level of technical sophistication has stagnated and its tactics are better understood by its potential victims, the group’s level of success will decline. However, we could easily imagine some short-lived spectacular actions due to convergence between hacktivists and antiglobalization supporters, or hacktivists and ecoterrorists.

The analysts go on to say that smaller groups with extremist views will redouble their efforts to hack bastions of democratic societies, improving their tactics “in sophistication and aggressiveness.”

Read 2 remaining paragraphs | Comments

Filed Under: Security Tagged With: , ,

“security” via n8xja in Google Reader 2012-12-27 23:00:34

December 27, 2012 By

Computer security firm McAfee Labs released its annual Threat Predictions report today, taking a look at what we’ll see (and hope not to see) on 2013’s deck of malware and viruses. Interestingly, McAfee’s analysis predicts a decline in Anonymous’ attacks, a rise in the frequency and sophistication of mobile malware, and a rise in large-scale attacks that aim to cause as much destruction as possible.

This time last year, McAfee’s report for 2012 predicted that “Hacktivism and Anonymous will reboot and evolve.” While this year didn’t see anything on the level of the hacks of Sony and HBGary from 2011, Anonymous did execute a number of high-profile attacks and threats. Now McAfee says that in 2013, hacktivisim will be conducted by more homogeneous, politically-motivated groups rather than Anonymous’ pantheon of personalities and pet causes. Still, McAfee suggests that Anonymous may be able to stage a few high-visibility attacks in the coming months despite its predicted decline. The report reads:

Sympathizers of Anonymous are suffering. Too many uncoordinated and unclear operations have been detrimental to its reputation. Added to this, the disinformation, false claims, and pure hacking actions will lead to the movement’s being less politically visible than in the past. Because Anonymous’ level of technical sophistication has stagnated and its tactics are better understood by its potential victims, the group’s level of success will decline. However, we could easily imagine some short-lived spectacular actions due to convergence between hacktivists and antiglobalization supporters, or hacktivists and ecoterrorists.

The analysts go on to say that smaller groups with extremist views will redouble their efforts to hack bastions of democratic societies, improving their tactics “in sophistication and aggressiveness.”

Read 2 remaining paragraphs | Comments

Filed Under: Security Tagged With: , ,

“security” via n8xja in Google Reader 2012-12-23 17:00:07

December 23, 2012 By

Aurich Lawson

2012 was an “exciting” year for OS X security—at least if you’re a security expert or researcher. There were plenty of events to keep people on their toes. Although Apple took some egg on the face for some of them, overall, the company came out ahead when it came down to keeping users safe.

At least that’s the opinion of some security researchers who followed OS X developments throughout the year.

Back to the Flashback

Remember Flashback? That malware first made its way onto the Mac in 2011, but never became widespread enough for most users to even become aware of it—until earlier this year. Suddenly, Apple was faced with arguably the first truly high-profile malware to appear on OS X, right as Apple was appearing more than ever in the media.

Read 23 remaining paragraphs | Comments

Filed Under: Security Tagged With: , , , , , , , , , , ,

“security” via n8xja in Google Reader 2012-12-23 17:00:07

December 23, 2012 By

Aurich Lawson

2012 was an “exciting” year for OS X security—at least if you’re a security expert or researcher. There were plenty of events to keep people on their toes. Although Apple took some egg on the face for some of them, overall, the company came out ahead when it came down to keeping users safe.

At least that’s the opinion of some security researchers who followed OS X developments throughout the year.

Back to the Flashback

Remember Flashback? That malware first made its way onto the Mac in 2011, but never became widespread enough for most users to even become aware of it—until earlier this year. Suddenly, Apple was faced with arguably the first truly high-profile malware to appear on OS X, right as Apple was appearing more than ever in the media.

Read 23 remaining paragraphs | Comments

Filed Under: Security Tagged With: , , , , , , , , , , ,