Category Archives: McAfee

  • 0

Generating Compliance History Reports

Category : McAfee

When you’re managing a large environment with thousands of endpoints, assuring consistency can be a huge challenge. Imagine that you want every endpoint to be upgraded to a specific software version, for example. In many cases, you’re forced to rely on manual tracking, where errors and omissions are commonplace. And, if you want to demonstrate how you’re progressing towards that goal over time, you’re looking at a large manual effort to track which systems have been updated and when.

In my previous blogs, I talked about sometimes-overlooked features in McAfee ePolicy Orchestrator (ePO) that can make managing your endpoint environment a whole lot simpler. Now, I’m going to cover one more: using ePO to show compliance history over time.

Tracking Compliance

Out of the box, you can use ePO to see the percentage of your systems that comply with a given criteria, such as McAfee Endpoint Security (ENS) software version. You may already be using that feature. But what you might not realize is that, in addition to showing a snapshot of systems that do and don’t meet that criteria right now, you can also track compliance over time. Effectively, you can use ePO to set a starting point for your migration project, and then generate reports showing your day-to-day progress towards the project goal.

For example, say you want to migrate all endpoints to McAfee ENS 10.5 by the end of this quarter. And imagine that, right now, 50 percent of your endpoints are running that software version. By next week, 60 percent of endpoints may be in compliance. The following week, you may be up to 75 percent. With ePO compliance history reporting, you can generate hard numbers to track your progress towards 100 percent compliance for that migration.

Software migrations are just one example of when compliance reporting comes in handy. You could use the same reporting to track endpoint systems that have a specific set of McAfee endpoint tools or components installed. Or, you could use it to help enforce a rule that no system should be using antivirus definitions older than 10 days. If you have any compliance goal for the McAfee products and tools on your endpoints, and you can express it as a Boolean query, you can generate a graph showing your progress towards that goal and export it to an Excel spreadsheet.

Creating the Report

Generating a compliance history report in ePO involves three basic steps: creating a Boolean managed system query, creating a server task, and creating a compliance history query.

The first step, a Boolean managed system query, creates a pie chart to show which systems are compliant with your criteria and which are not. ePO features a wizard to take you through the process. To get started, click “Create new managed system query” in the Queries & Reports section of the main ePO dashboard. Select Boolean Pie Chart as the chart type, and click the “Configure Criteria” button. The properties listed here configure which attributes the query will check for compliance. So in our software migration example, if you want to see which systems are running ENS 10.5, you would add that as a compliance attribute. ePO will then show all systems that are not running software version 10.5 as non-compliant for the purposes of this query.

Using the same tool, you can also label the Boolean pie chart with your compliance criteria. And you can configure the Filters tool to exclude any systems that you don’t need to be in compliance for the purposes of your query. (So in the software migration example, you could decide that servers are out of scope for this update and exclude them from your query.)

Finally, save the Boolean Managed System Query. I’d recommend naming the report with “Compliance” in the query name for easier referencing later.

Configuring Server Tasks and Compliance Queries

The next step is to create a new server task. Go to Server Tasks in ePO and click “Create Server Task.” For simplicity’s sake, you may want to include “Compliance” in the server task’s name. For the Action field, select “Run Query.” In the Query field, select the Boolean Managed System Query you created in the previous step. In the Sub-Actions field, select, “Generate Compliance Event.” Then, set a schedule to run the server task once per day, or as often as you’d like to track. Remember: the goal here is not simply to see a snapshot of how many systems are in compliance, but to be able to track your progress towards full compliance over time. So you will want this server task to run on an ongoing basis.

For the final step, you create a new compliance history query. Go back to Queries & Reports in ePO and click “Create Compliance History Query.” For the chart type, select “Single-Line Chart.” Select “Day” for the Time Unit (unless you’ve chosen a different time interval for your server task to run). For the Line Values field, select “Average of,” and in the second field, select “Percent Compliant.” Save the chart. Then, in the filter section, add a filter for “Server Task Used to Generate Compliance Event” and assign it the Server Task that you just created.

View Progress Over Time

Illustrating compliance history over time can be extremely useful for anyone undertaking a large-scale software migration, or seeking to ensure that all systems’ McAfee components are configured consistently. But it can also be helpful for illustrating the progress of a given project to others.

If an executive wants to know how a software migration is progressing, for example, and you show them a point-in-time snapshot showing 70 percent compliance, they may want to know why 30 percent of systems are still running older software. With ePO compliance history reporting, you could demonstrate that just two weeks ago, 60 percent of systems were non-compliant, and you’ve cut that figure in half. It’s just one more way that ePO can make large-scale endpoint management easier.

 

Source: https://securingtomorrow.mcafee.com/business/generating-compliance-history-reports/#sf175360588

Author: Ted Pan

 


  • 0

GDPR as a Business Enabler – Fact or Fiction?

Category : McAfee

The new General Data Protection Regulation (GDPR) will be a big business driver for security solutions in many industries this year. However, the size of the potential fines and the reputation damage of a reported violation could have a negative effect on business digital transformation initiatives. Is it truly possible for GDPR to be a business enabler?

In order to find out, McAfee commissioned a survey of 800 senior business professionals from eight countries and a range of industries. We uncovered insights about their top data protection concerns, strategies around GDPR and other regulatory developments, and how enterprises think data privacy can create competitive advantage. We wanted to know: What drives their decisions and investments in data management? Do they place their faith in cloud providers? Are they prepared to meet regulatory mandates and exceed customer expectations?

In this webcast Raj Samani, Chief Scientist and McAfee Fellow and Emma Wright, Commercial Technology Partner at Kemp Little discuss the findings of our study as well as pose the questions

  • Is the culture of your organization ready for GDPR?
  • Do you have the right people, processes, and technology in place to adhere to data privacy and residency regulations?
  • Will GDPR provide a competitive advantage or cause your business to suffer from brand damage?

REGISTER


  • 0

McAfee and Amazon Web Services: A Secure Relationship

Category : McAfee

As enterprises continue their journey to the cloud, many are using a hybrid model that engages both the private and public cloud.  McAfee has embraced this “hybrid cloud” strategy to enable companies to migrate to the public cloud, and we are investing in the tools and relationships to enable the transition. Working with Amazon Web Services (AWS) is an important part of bringing enterprise-level security to public cloud deployments, and I’m happy to announce two new partner relationships with AWS. Also, McAfee will be joining AWS at the AWS re:Invent Expo in Las Vegas in late November, where we will demonstrate products that customers can use in their hybrid cloud strategy.

McAfee is Now an APN Advanced Technology Partner

For enterprise engagements, McAfee has become an Amazon Partner Network (APN) Advanced Technology Partner. To become an APN Advanced Technology Partner we have demonstrated that our products, customer relationships, expertise and overall business investments on AWS have grown and are meaningful to AWS.

McAfee builds tools that automate the rollout of security controls and security operations consistently across organizations. Our solutions — such as Virtual Network Security Platform, Cloud Workload Security, and Web Gateway — can play significant roles in helping companies adopt AWS securely:

McAfee Virtual Network Security Platform (vNSP): Designed specifically for fully virtualized public and private clouds, vNSP delivers an elastic security control that provides comprehensive network inline intrusion prevention, application protection, zero-day threat detection and visibility into lateral attack movement. The scalable and highly distributed architecture has been certified as “Well Architected” by Amazon. Integration with orchestration and automation frameworks makes this an ideal solution for adoption in DevSecOps environments.

McAfee Cloud Workload Security (CWS): As data center parameters get redefined, the ability to navigate current datacenter workload assets and plot the journey to the cloud requires a map that will safely show the way. Cloud Workload Security provides visibility and protection for your workloads in the cloud with agility and confidence through an integrated suite of security technologies, ensuring control of new parameters.

McAfee Web Gateway (MWG)With its best-in-class malware protection efficacy and policy flexibility, we now have the ability to deploy MWG directly in AWS. This is in addition to the appliance model and SaaS deployment model. MWG boasts the most flexible options in the industry for Web security. With an AWS deployment, customers can not only offload workload from on-premise appliances through hybrid policy enforcement, they can also provide advanced in-line malware detection for SaaS-based apps. This is the same value proposition that McAfee has historically offered for endpoint protection, but we are now able to offer it for SaaS-based applications as well.

To learn more about our solutions that keep you better protected on AWS, visit  mcafee.com/ProtectAWS

McAfee Accepted into the AWS Public Sector Partner Program

In addition to the commercial sector, McAfee knows that Government, Education and Nonprofit customers need quality security in the cloud. AWS has accepted McAfee into its AWS Public Sector Partner Program. This designation reflects McAfee’s strong commitment to support public sector customers in their transition to the cloud. As our presence in the AWS Public Sector Partner Program grows, so too will the value of our solutions specifically targeted for the public sector.

McAfee is a Sponsor at AWS re:Invent

Join us the week of November 27th at the AWS re:Invent event in Las Vegas. Visit the McAfee (Booth 1238) at the Venetian. McAfee experts will share strategies and best practices to help customers secure and manage data on AWS. Plus, you can see live how McAfee vNSP expands network protection across virtualized environments.

Source: https://securingtomorrow.mcafee.com/business/mcafee-amazon-web-services-secure-relationship/?utm_content=sf173952110&utm_source=linkedin&utm_campaign=Enterprise#sf173952110

Author: Raja Patel


  • 0

New Android Malware Found in 144 GooglePlay Apps

Category : McAfee

McAfee’s Mobile Research team has found a new Android malware in 144 “Trojanized” applications on Google Play. We named this threat Grabos because we found this string in several elements of the code, including variable and method names. Grabos was initially found in the Android application “Aristotle Music audio player 2017,” which claimed to be a free audio player on Google Play:

Figure 1. Trojanized music app in Google Play.

At the time Aristotle Music was discovered, the application had a very good rating. According to Google Play, the application was installed between one and five million times and had a recent comment from a user saying that the application was detected as malware:

Figure 2. User reporting the application Aristotle Music being detected as malware.

Grabos on Google Play

McAfee Mobile Research notified Google about Grabos in September and confirmed that Google promptly removed the reported application. After further research, we found another 143 applications (see complete list at the end of this post); all have been removed from Google Play. Six were removed after we reported the first to Google:

Figure 3. Additional Grabos Trojanized apps formerly on Google Play.

At the time of writing this post, 34 applications still had their webpages available in cache, so we were able to obtain additional information such as the approximate number of installs, last updated date, and rating. Most of these apps were last updated in August and October. They had an average rating of 4.4, and between 4.2 million and 17.4 million users downloaded these apps from Google Play:

Figure 4. Malicious apps details from Google Play.

Grabos likely evaded Google Play security measures because the injected code is protected with a commercial obfuscator, making it very difficult to statically analyze without executing the application. Even dynamic analysis to stop its execution is difficult without knowing what the app is checking. However, once we unpacked the code, we proceeded with our analysis.

“Fake” vs. “real” apps

We found Grabos injected in file explorer and music player applications, some of them open source. Every time that the app is opened, it checks if any of the following settings is not true to decide whether to launch the “fake” (legitimate functionality) or “real” (injected packed code) app:

  • isOnline: Checks if the device has Internet connectivity
  • getIsBlacklisted: Checks if the Android debug bridge (adb) and development settings are enabled or if the device is in an emulator. If the latter is the case, the device is blacklisted and the “fake” app is launched.
  • getIsForcedBlacklisted: Flag set by the control server.

The code also has a test mode that allows the execution of the “real” app in case it is running in an emulator or has adb and development settings enabled. These checks detect if the app is currently being dynamically analyzed and prevent the execution of the hidden code if necessary.

In case the app is not being analyzed or is in test mode, the “real” app launches. This hidden music downloader searches for a specific song on YouTube. Once the song is selected, it can be downloaded in MP3 or MP4 format to be played offline.

Figure 5. “Fake” vs “real” app flow. “BL” stands for “blacklisted.”

At this point, the application seems to be just a music downloader hidden in a Trojanized app that checks for dynamic analysis to avoid being removed from Google Play due to its downloading of copyrighted music. In the background, however, more is happening.

Communicating with the Control Server

In addition to the “fake” and “real” app functionality, Grabos is also present in the AndroidManifest as a receiver that executes every time there is a connectivity change or when the app is installed:

Figure 6. Grabos receiver in the AndroidManifest.

If the receiver is executed due to a connectivity change, the execution ends if the device is offline or if fewer than five seconds have passed since the last connection. If more than five seconds have already passed, the method “updateRemoteSettingsSynchronousTask” executes. This method collects and encrypts (Base64 plus Advanced Encryption Standard) the following data from the infected device:

  • Device information:
    • android_version
    • build_model
    • install_referrer
    • network_country
    • sim_country
    • carrier_name
    • language_code
    • country_code
    • time_timezone
  • Device location: Grabos uses free IP geolocation API services to obtain IP address information such as city, country code, ISP, organization, region, and ZIP code.
  • Device configuration:
    • is_emulator
    • is_rooted
    • is_adb_enabled
    • is_dev_settings_enabled
    • allow_mock_location
    • allow_non_market (unknown sources enabled/disabled)
    • is_vpn_connected
    • dp checks (additional root, debug, and emulator checks provided by the commercial obfuscator)
  • Installed Grabos app information: version_code, package_name, and install_time
  • Specific apps installed: Grabos reports if any app in a predefined list is currently installed on the infected device (more on this later).

All the information is encrypted and submitted to a control server. The remote server responds with encrypted data that contains parameters required to download music (URLs, API keys, user agents, client_id, etc.) to show advertainments (nativead_id, interstitial_id, banner_id, etc.) and display customized notifications such as asking the user to rate the app in Google Play:

Figure 7. “Rate this app” parameters provided by the control server.

The rating pop-up appears the first time the app is opened. If the button “Rate 5 Stars” is clicked, the app opens in Google Play so the user can rate the app there.

Figure 8. Rating pop-up.

In a similar way, the remote server also provides parameters to ask the user to share the app with friends and promising faster download speeds:

Figure 9. “Share the app” parameters provided by the control server.

The control server also sends the parameter “is_forced_blacklisted,” which manually blacklists the device if the value is “true”—to prevent the execution of the hidden app.

Mysterious functionality

In addition to reporting an infected device’s location and configuration, Grabos checks if specific social and Google apps are installed using the method isPackageInstalled and the app package name. Depending whether an app is currently installed, the corresponding value is set to true or false and that information is encrypted and reported to the control server:

Figure 10. Social and Google apps reported to the control server.

We reported this finding to Google, who are investigating. At this point we do not know the purpose of this app reporting. However, we believe this information could be very useful to malware authors because Grabos has implemented several mechanisms to trick users into installing applications provided by the remote server. Let’s look into those functions.

Custom Push Notifications and Additional Apps

After the initial settings are obtained from the remote server, the AsyncTask ShowNotificationIfNeeded is executed to check if the parameters n_title, n_description, and n_package were provided by the control server. If that is the case, Grabos checks if the app is available on Google Play (if “pack” is a name and not a URL) or on a remote server (if “pack” starts with HTTP).

If the application is not installed and is available, Grabos gathers additional parameters (for example, icon and bigicon) from the remote server response to create a custom notification and trick the user into installing the app:

Figure 11. Parameters provided by the control server to create a custom notification.

Grabos also checks if the remote server provided the following parameters:

  • interstitial_letang_options: provides values to delay and repeat the display of an activity (initial_delay and min_interval)
  • interstitial_letang: includes the following remote commands:
    • admob: executes method “showAdmobInterstitial”
    • nothing
    • grabos_direct

If the command is grabos_direct, Grabos gets the title, package, and max_times_shown values in the parameter grabos_direct_interstitial to open the app in Google Play or trigger a download:

Figure 12. Downloading an APK from a URL or open app on Google Play.

Both the notification and the interstitial_letang methods, to trick the user into downloading or installing apps, are executed in the background every time there is a connectivity change. However, Grabos also implements another app delivery method when the music downloader executes. This method, ShowGrabosIfNeeded, is very similar to interstitial_letang in that it checks if the required parameters are present and the app is available as well as checking if the app should be opened without the user’s consent:

Figure 13. Grabos checking whether the installed app should be opened.

As soon as Grabos confirms that the device is online, the app is available either on Google Play or a remote server, and the package is not installed, the malware gets the following parameters from the remote server response to create an AlertDialog and trick the user into downloading another app:

Figure 14. Grabos parameters to create an AlertDialog.

Flying Under the Radar: Evading Analysis

In addition to the multiple efforts to detect if the app is being dynamically analyzed (emulator, adb, development settings) and the encryption of the injected code, Grabos updates its remote settings every 24 hours (unless it is in test mode). This restriction can be easily bypassed by changing the date and time of the device used to analyze the app. However, recent versions of Grabos include checks to detect if the automatic date and time and time zone are enabled:

Figure 15. Grabos checks if automatic date and time and time zone are enabled.

The status of this setting is reported to the control server in the fields time_is_auto and time_timezone_is_auto. Although this check is not used in the Grabos code, the information could be used to determine if the app is being dynamically analyzed and decide if an additional payload should be delivered.

The URLs used as control servers indicate that Grabos tries to masquerade its network traffic as legitimate. At first sight the URLs appear to belong to familiar adware companies; the names are identical. However, instead of finishing with .com, Grabos uses domains such as .link and .click, which are not registered by the company.

Finally, Grabos defines an additional mechanism, currently not implemented, to blacklist or whitelist a specific device. For example, the device could be blacklisted or whitelisted in a future version depending on the country code or configured language of the infected device:

Figure 16. Blacklist and whitelist functions based on language and country code.

Grabos also defines (but does not implement) methods to blacklist a device based on IP address:

Figure 17. Blacklist functions based on IP address information.

Conclusion

During our analysis of this threat, the control servers always provided empty parameters for the custom notifications to trick users into installing applications. Taking into account the functionality to display ads and the high number of downloads, we believe the main purpose of Grabos is to make money by promoting the installation of apps.

Grabos gained popularity on Google Play because it allowed users to download music for free while constantly asking them to rate the app. However, users were not aware of the hidden functionality that comes with those apps, exposing them to custom notifications to download and install additional apps and open them without their consent.

Considering that Grabos also reports the presence of specific social and Google apps on infected devices, cybercriminals could use that information to deliver additional apps by tricking users into installing them using any of the notification methods implemented in the code. Although during our analysis the remote servers did not deliver the required parameters to trigger custom notifications, the devices remain exposed to the download of additional Android apps.

McAfee Mobile Security detects this threat as Android/Grabos. To protect yourselves from threats like this on Google Play, employ security software on your mobile devices, check user reviews, and avoid installing suspicious apps with screenshots or functionality that do not correspond to the name of the app.

We would like to thank Sebastian Porst and Jason Woloz from Google’s Android Security for their helpful contributions on this research.

List of Grabos Package Names

  • com.picklieapps.player
  • com.musicaplayer.stonetemples
  • com.mp3musicplayer.playmusicmp3
  • com.densebutter.musicplayer
  • com.airplaneapps.soundmeter
  • com.dinosaursr.musicplayer
  • com.tenuousllc.humneate
  • com.astropie.musicplayer
  • info.chargeshoes.videoplayer
  • com.callsaver.doubtful
  • com.unfestenedsail.freeapp
  • com.extendmilk.freeplayer
  • com.excellentlossapps.playermusic
  • com.AliciaTech.free
  • com.mp3player.musicplayer.freelocalmusicplayer
  • com.freemusicplayer.freemusicplayer.free
  • com.afromusicplayer.fremediaplayer
  • com.info_astro.glider_player
  • com.illfatednotice.humdrum
  • com.headybowl.musicplayer
  • com.musicgratisplayerfree.free
  • com.naturityllc.mp3player
  • info.anothertube.music.player
  • com.startdancingapps.callrecorder
  • com.social.video.saver.pro
  • es.gratis.video.downloader.hd
  • com.sportingapps.copyleft_music.player
  • com.auto_call_recorder.freeapp
  • com.freenewsreader.rssfeed
  • ar.music.video.player
  • com.curatorinc.ringtone.search
  • com.mp3musicplayer.local_files_player
  • com.copyleft.stream.musica.player
  • info_de.mp3.music.player
  • com.nobodybeats.musicplayer
  • com.file.manager.pronessbest
  • info.ark.music.mp3.player
  • com.air.browser.free
  • com.aneeoboapps.playlistmanager
  • com.local_music_player.free_mp3_player
  • com.greenlinellc.voicechanger
  • com.free.playlist.creator.tube
  • com.toporganizer.fileorganizer
  • com.thumb.webbrowse
  • com.aspirator.ringtones.player
  • com.freevideoplayer.musicplayer
  • com.vimfast.videodl
  • com.whimsical.piano.free
  • com.truckneat.freeapp
  • com.crowdedarmy.volume.controller
  • com.arnold_legal.mp3.musica
  • com.descent.shutterfly
  • com.thankyou.arrowplayer
  • com.pocahantasapps.musicplayer
  • com.astroplayer.freee
  • com.couchpotato.musica.play_stream
  • com.abstractly.musica.player
  • com.matsumoto.mp3player
  • com.musicequalizer.freeequalizer
  • com.lifesbad.fileexplorer
  • com.videolunch.free
  • legal.copyleft.cc.mp3.music
  • com.ark.music.mp3.player
  • info.musik.mp3.music
  • com.streamerplayer.stream_videos
  • info.voicerecorder.recordvoice
  • com.snip.browser
  • com.checkrein.musicapp
  • com.mp3musicplayer.freemusicplayer.playmusic
  • com.jadedprogram.mp3player
  • com.preoral.freeborn
  • com.voice.changer.freeappsapp
  • es.streamplay.stream.player
  • com.localmp3music.freeplayer
  • com.drummachine.machinedrums
  • com.coloringbook.freetrynow
  • com.videodownloader.social_video_download
  • com.ElephantApps.FileManager
  • com.scaricare.app.musica
  • com.quicksearch.tube.player
  • com.rooseveltisland.mp3player
  • com.mindprogram.musicf
  • com.freeborn.sdkintegration
  • com.koseapps.tubemusica
  • fr.baixar.videos.gratis
  • info.adeptly.forgoneapp
  • us.musicas.gratis.player
  • com.miniaturef.swanky
  • com.insta.mp3.music.streamer
  • com.anchor.musicplayer
  • com.repeate.mp3musicplayer
  • com.FeisalLLC.MusicPlayer
  • com.shelfshare.freeapp
  • info.simple.streamer.player
  • com.streamplayer.freearnold
  • com.freeturkish.video.downloader
  • com.cowherd.freeapp
  • com.localmp3musicplayer.local_player
  • com.scaricare.apps.musica
  • com.silymove.freeapp
  • com.pinkphone.funfreetube
  • info.tissuepaper.freemusic
  • com.chopsuey.musicplayer
  • com.branchnotice.musicplayer
  • com.fradcip.MasterApp
  • sv.music.player.mp3.ares
  • com.social.video.downloader.for_fb
  • com.frobenius.time.tube
  • com.spelldoom.comeup
  • com.bailymusic.player
  • com.sportifco.musicplayer
  • com.topsaver.video.downloader
  • com.coupleweeks.modcium
  • com.unbecomingllc.videodownloader
  • com.video.for_fb.downloader.saver
  • com.macdrop.apptool
  • com.callsaver.recorderfreeapp
  • com.arnie_legal.mp3.musica
  • com.kikiapps.freeplayer
  • com.pintaapps.expensetracker
  • com.marble.musicequalizer
  • com.artproject.searcher
  • com.UnitTest.FreeApp
  • com.exudedplayer.freemusicplayer
  • com.blackballed.player
  • com.mp3player.decisiveapps
  • com.rusticd.musicplayer
  • com.byunhyeong.jungfree
  • com.voicelessapps.mp3musicplayer
  • com.localmp3player.freeplayer
  • com.kinokunya.free
  • com.socialvideo.downloader_vim
  • com.viastore.video.saver_for_fb
  • com.disarmbit.reache
  • com.crackerbalancellc.mp3converter
  • info.vaskollc.jpfree
  • com.freemusicplayer.musicplayfreetoolpalyer
  • com.combustionapps.musique
  • com.arnold.mp3.musica
  • com.purpleheadphones.audioplayer
  • com.unscalableapps.free
  • com.freefile.organizerfree
  • com.free.mp3.stream_cc_music
  • com.mp3uncle.musiccamera

Source: https://securingtomorrow.mcafee.com/mcafee-labs/android-malware-grabos-exposed-millions-to-pay-per-install-scam-on-google-play/#sf173537767

Author: Carlos Castillo


  • 0

Self-Signed Certificates Can Be Secure, So Why Ban Them?

Category : McAfee

In many organizations the use of self-signed certificates is forbidden by policy. Organizations may ban the use of self-signed certificates for several reasons: It is trivially easy to generate a certificate’s key pair without reasonable entropy, to fail protect the private key of the key pair appropriately to its use, to poorly validate the certificate when used, and to misuse a self-signed certificate when a certificate authority should have been used instead. However, when properly and appropriately used, a self-signed certificate provides acceptable security in some situations.

There is a broadly held misunderstanding that self-signed certificates are inherently bad security. We offer this explanation to expand your understanding of certificate use. At the same time, we explain the circumstances under which McAfee’s use of a self-signed certificate in one of our products provides adequate security for our customers.

For many uses of public key infrastructure (PKI), the correct method for signing a certificate is to use a well-known, trusted third party, a certificate authority (CA). “In a CA-based PKI system, the CA must be trusted by both parties. This is usually accomplished by placing the CA certificates in a whitelist of trusted certificates,” says Wikipedia.

Indeed, self-signed certificates have several key limitations. Most important among these are:

  • Self-signed certificates cannot be revoked.
  • Self-signed certificates never expire.

However, there are cases for which a self-signed certificate may be sufficient, and perhaps a better choice than a certificate that has been signed by a CA.

In a public key infrastructure, in which parties to a communication are unknown to each other (and thus untrusted), the limitations of self-signed certificates presented above are important.

Consider browser-to-website connections. Users, via the browser, must ensure that the site to which they are connecting is indeed the intended site. In this case, having a trusted third party, the CA, is critical to validate that the web server in the connection is the one for which the certificate has been issued.

Establishing website-to-browser identity is the standard certificate use that transport layer security (TLS) pre-encryption authentication employs as well as the typical example for the use of certificates in general. This use case is also the driver for many organizational security policies in which the use of self-signed certificates is forbidden.

In the case where both sides of the communication know each other—often within the same entity—self-signing limitations become advantages. In this case, we can think of the certificate as a credential used to identify a particular entity to itself. This case is not entirely the same as attempting to establish trust between unknown parties.

In fact, when a certificate is used between two components in the same entity—that is, both sides are establishing that the other side is the one, intended component—the certificate is a form of shared secret, like a rather complex password.

In this case, there is no need for a third party to act as a root of trust. All that is required is that the key pair match—or, more precisely, that the public key can be used to verify that the certificate was signed with its private key mate (often called certificate pinning). Any public/private key pair will perform this function; an X.509 certificate happens to be a convenient and well understood “package” for the interaction.

The preceding self-signed use case presupposes that the private key of the certificate’s key pair has been and will continue to be protected with great care, similar to any important credential. One of the advantages of using an X.509 certificate for authentication is that the private key need not be installed (and thus is highly protected!) along with the certificate. The private key is used to generate the certificate. After generation, the private key is no longer needed to validate the certificate; only the public key is required.

Of course, a certificate when used as a credential requires sufficient protection, just as with any form of credential. Still, without the private key, the certificate becomes a one-of-a-kind credential; it can be reused if stolen, but it cannot be regenerated without access to the private key.

A self-signed certificate used for intercomponent authentication for TLS must be protected so that the likelihood of theft is very low. At McAfee, we provide layers of self-protection against the theft and reuse of products authentication certificates.

X.509 is nearly ubiquitous and has a great deal of programming and processing support. Hence, it is faster to deliver authentication based upon certificates than to build alternate software to validate key pairs. Besides, in the case of TLS, the protocol specifies X.509 certificates; certificates must be used to take advantage of TLS’ built-in authentication mechanism.

Because a self-signed certificate cannot be revoked and it does not expire, this reduces update and patching complexities in a connection between components built by the same entity and intended to be used solely within that closed context. However, to replace a certificate, for whatever reason, requires a software update because each self-signed certificate is the credential, rather than relying on trust of a certificate authority.

If the self-signed certificate’s private key were to become compromised in some manner, software could be updated with a new set of certificates and new keys. The compromised certificate would be tossed out, removed from service because it could not be used to establish trust between the parties. Because the old certificate is self-signed, it also will not work for other uses, such as the TLS server-side authentication we have described.

Essentially, once removed from its intended use, a self-signed certificate is useless to any party, malicious or otherwise.

At McAfee, we take our customer’s security seriously. We analyze each cryptography case carefully to identify the best solution that will help to ensure our customers continued protection. The use of self-signed certificates in McAfee products is appropriate to the use to which the self-signed certificate has been applied.

Source: https://securingtomorrow.mcafee.com/mcafee-labs/self-signed-certificates-secure-so-why-ban/#sf148680068

Author: Brook Schoenfield and Ramnath Venugopalan


  • 0

Expiro Malware Is Back and Even Harder to Remove

Category : McAfee

File infector malware adds malicious code to current files. This makes removal tricky because deleting infections results in the loss of legitimate files. Although file infectors were more popular in the 1990s and early 2000s, they still pose a significant threat. The complex disinfection process is usually leveraged by malware authors to ensure systems stay infected for a long period. This may explain why complex file infectors such as W32/VirRansom, W32/Sality, W32/Xpaj, and Expiro are still active today.

The Expiro virus is has been around for more than a decade, and the authors continue to update it with more features. Expiro is unique in that it infiltrates executable files on both 32- and 64-bit Windows systems by appending its viral code to the host. It can be used to install malicious browser extensions, lower browser security settings, and steal account credentials.

Recently we discovered a new variant of Expiro with a significant change in its infection routine. In previous variants, Expiro modified and stole code at the entry point and appended the viral payload only at the end of the original file, typical of an appender virus.

The new variant, however, changes the size of the base relocation table and encrypts the addresses inside, causing traditional appender virus repair routines to corrupt files unless they correctly restore the original base relocation table. By adding the encryption, Expiro increases the complexity of analysis and requires a customized repair routine, which makes it hard to combat.

The following screenshots demonstrate this point: The base relocation table of a file infected by the old variant of Expiro is unaffected and the contents are untouched.

Figure 1: The relocation table remains intact when infected by the old Expiro variant.

Figure 2: The relocation table contents are not modified by the old Expiro variant.

The new variant reduces the size of the base relocation table and encrypts portions of it (outlined in red).

Figure 3: The latest Expiro variant reduces the size of the relocation table.

Figure 4: The relocation table encrypted by the latest Expiro variant.

To fix relocations prior to the execution of the original file’s code, the Expiro virus first executes its own malicious payload. It then decrypts the relocation table and dynamically reloads all addresses to make sure the original file can run correctly.

Decryption involves a simple XOR operation with a key hardcoded within the sample.

Figure 5: Relocation table being decrypted using a hardcoded XOR key.

After the decryption, the rest of original base relocation table is recovered.

Figure 6: The EDI register now contains decrypted relocation data.

In recovery step 2, Expiro computes the address that contains the relocation address using the formula Relocation_Address = NewImageBase + Offset + VirtualAddress.

Figure 7: Calculation of the address to be relocated in Expiro’s code.

As we see in the following screenshot, the formula leads to Relocation_Address = 0x950000 + 0x354 + 0x1000, so the address in 0x951354 should be relocated (stored in eax).

Figure 8: Relocation address being calculated.

In recovery step 3, Expiro computes the relocation value using the formula Relocation_Value = OldValue + (NewImageBase – OldImagebase).

Figure 9: Relocation value being computed by Expiro.

In this case, the formula is Relocation _Value = 0x01001354 + (0x00950000 – 0x01000000), so the relocation value is 0x00951354.

Figure 10: Expiro performing relocations on its own.

Using this technique, we can decrypt and repair the entire relocation table of the files infected by Expiro. This also helps us to calculate and replace the relocation table size in an executable’s optional header with the correct values. These changes ensure the infected files can run properly after removing the malicious payload.

 

McAfee products detect Expiro as W32/Expiro.gen.rd and W64/Expiro.d and repair infected files from DAT Version 8665. Users can find additional information at this McAfee Labs Threat Advisory.

SHA-256 hash

  • f15b8fc3ca117ab38e3074adc6208666b2189259e447db8202ef85b9bbfc4537

Source: https://securingtomorrow.mcafee.com/mcafee-labs/expiro-infects-encrypts-files-to-complicate-repair/#sf138305893

Author: Xiaobing Lin


  • 0

Code Execution Technique Takes Advantage of Dynamic Data Exchange

Category : McAfee

Email phishing campaigns are a popular social engineering technique among hackers. The idea is simple: Craft an email that looks enticing to users and convince them to click on a malicious link or open a malicious attachment. Weight-loss and other health-related phishing emails are common. Package deliveries, bank notices and, in the case of spear phishing, even emails from your coworkers can contain malicious links or documents. With new research related to old Microsoft Office technologies, hackers have found new techniques that makes phishing all that more effective.

Microsoft’s Dynamic Data Exchange (DDE) has been around since 1987. Its purpose is to facilitate data transfers between applications that do not require ongoing user interaction. For example, if you have an item in a document that needs to have up-to-date data from an external source such as financial data, you can use DDE to kick start a process to collect that information. In Word, this could update charts and graphs of your financial data every time you open the document. Its functionality has been superseded by other technologies, notably Object Linking and Embedding (OLE), released in 1990, but due to compatibility reasons DDE is still supported by current Windows versions and Office products. (Microsoft advises that you disable DDE.)

On August 23 SensePost told Microsoft what they saw to be a security concern, if not a vulnerability, in the behavior of DDE. Microsoft determined that DDE behaved as expected and that the issue would be considered for a next-version candidate bug. On September 10 SensePost reported their findings.

The holy grail of phishing is to get arbitrary code execution on the target box. Once attackers can execute code, the hard part is done. At this stage they can load any malicious code on the target box to steal data or hold it for ransom. The Necurs botnet, which delivers the notorious Locky ransomware, has implemented a DDE-based phishing attack. Necurs delivers crafted Word documents, using the DDE protocol upon loading, that infect systems with Locky. (For more technical details on the Necurs botnet please refer to the McAfee Labs Threat Report, June 2017.)

Exploiting DDE for code execution is relatively simple. Attackers insert a calculated field and change the field codes to proper DDE syntax. They can use the DDEAUTO or DDE field identifier to launch executables. A proof of concept shows PowerShell giving an attacker a lot of control. The user is presented with two messages. The first appears innocuous: “This document contains links that may refer to other files. Do you want to update this document with the data from the linked files?” The second message, which hopefully raises more suspicion, identifies the executable being called. However, attackers have some control over this message and may be able to reduce suspicion by changing how they launch the executable. At this time, the user must click “Yes” on both pop-ups for the attack to succeed.

Not only Word documents support this technique. Researchers have shown that Outlook Calendar invites can be crafted to exploit the DDE code execution technique, removing the need to attach a malicious file. An Outlook attack can begin when users merely open their invites.

Attackers are always innovating to trick users and bypass protections. Even old technologies can play a role in new attack techniques. It is important to educate your users on phishing attempts and to pay attention to security messages asking for access to system resources. With the simplicity of this technique and quick adoption from large malware players, we can assume that many new phishing campaigns will implement DDE for initial code execution, delivering both known malware, such as Locky, and new malware to the victims.

For technical details, see “Configuring McAfee ENS and VSE to Prevent Macroless Code Execution in Office Apps.”

Source: https://securingtomorrow.mcafee.com/mcafee-labs/code-execution-technique-takes-advantage-of-dynamic-data-exchange/?utm_content=sf128735689&utm_source=linkedin&utm_campaign=Enterprise#sf128735689

Author: Charles McFarland


  • 0

Ransomware Decryption Framework – Now Available

Category : McAfee

How do I get my files back?  This is probably the first question asked when ransomware strikes. Of course, the answer will depend on whether there is a backup available. Or if a decryption tool exists on the www.nomoreransom.org website.

Developing these tools invariably involve significant effort to identify the decryption keys, but also create a tool that can be tested, hosted and then made freely available to help victims of ransomware. Today however we are pleased to announce the availability of McAfee Ransomware Recover (Mr 2), this framework will allow for the rapid incorporation of decryption keys and custom decryption logic (when they become available) and get help to victims of ransomware a lot quicker.

Now, whilst the availability of a framework is important its probably not something you would say deserves the fanfare of the communications we have produced. However, the key difference here is that this framework is free to use for the security community. So if security researchers have identified decryption keys and custom decryption logic for a ransomware variant, and do not want to spend the time to produce their own tool then McAfee Ransomware Recover (Mr 2) is available to freely use.

Over the course of the next few weeks we will produce more guidance on the tool, including webcasts by the development team. Also, we will remain committed to working with our public and private sector partners to get our hands on as many decryption keys as possible.

Source: https://securingtomorrow.mcafee.com/business/ransomware-decryption-framework-now-available/

Author: Raj Samani

 


  • 0

Go with the flow! Automating and streamlining workflows with OpenDXL

Category : McAfee

Date: Wednesday, October 11, 2017
Time: 3:00PM BST | 4:00PM CEST

We all need some time hacks to help us get more done in our days. We need technologies that work together for faster detection and remediation. Programmatic workflows can help by automating repetitive and time sensitive tasks, as well as sharing intelligence from disparate sources.

Automating IOC ingestion using OpenDXL can tell more than just where those IOCs live in your environment. Integrating with McAfee Threat Intelligence Exchange (TIE) enables faster action across your environment. And integration with McAfee Active Response (MAR) enables automated searches that result in faster remediation.

Join McAfee OpenDXL Developer Advocate Parker Crook to learn more about how OpenDXL can help you make the most of your time and secure better outcomes for your enterprise.

REGISTER NOW!


  • 0

The Hack Back, A Double-Edged Sword

Category : McAfee

Global cyberattacks like Mirai, WannaCry and Petya have left victims feeling helpless and eager to gain back the data they’ve lost at the hands of cybercriminals. This modern threat landscape has everyone looking towards new solutions and strategies—any way they can help protect others while staying secure themselves. So, it’s no surprise that the idea of the “hack back” is gaining some traction. The hack back, a notion that came to light in various congressional proposals that are intended to put tools in the hands of victims to identify alleged attackers, halt an alleged attack, and potentially recover or delete stolen information.

This legislation, first proposed back in May, features policies intended to empower victims of a cyberattack, while still trying to ensure accountability. It states a mandatory reporting requirement for entities that use active-defense techniques, which is intended to help federal law enforcement ensure defenders use these tools responsibly. It also includes an exemption allowing the recovery or destruction of one’s own data if it’s located using the active-defense techniques permitted by this bill and does not result in the destruction of data belonging to another person.

While the objective of the legislation is laudable, helping companies improve their ability to defend themselves, we have to consider some of its risks that could include actions that may well cause damage to parties that either innocently were part of an attack, or through false flag operations that have no direct involvement. For instance, we’ve recently seen that the emerging intent from many attackers is to point the source of attacks to another party, such as was witnessed during the Operation Troy attacks. The use of hacking back in this scenario would have caused damage to a third party.

Our approach, and one we would recommend to others, is to take direct action against malicious actors by utilizing the expertise of law enforcement. A strong partnership between the public and private sector to hold cybercriminals accountable is essential in maintaining a safer society. So, if you do undergo a cyberattack, your first action should be contacting the authorities immediately. From there, experts will handle the situation in a way that ensures safety for all innocent parties involved.

There is a lesson to be learned from the notion of hacking back, however. Instead of hacking back, rather learn how to think like a hacker in order to identify cyberattacks and flag them before the damage is done. By thinking proactively, the need to take reactive measures lessens and the power shifts back to where it belongs: with you.

Source: https://securingtomorrow.mcafee.com/business/hack-back-double-edged-sword/?utm_source=RTI&utm_medium=LN

Author: Raj Samani


Support