CVE-2019-12758 Workaround

I would discuss a workaround in mind to prevent any DLL injection that might be used to execute on windows as part of a legitimate process. I tested this after reading the article of Peleg Hadar on the SafeBreach website. Peleg Hadar discovers a similar issue with multi Antivirus products which mean that issue might not related to antivirus vendor directly.

Symantec addressed this vulnerability as Medium level and advised to upgrade to the latest SEP version, and also they recommend to allow only trusted users to have local admin privilege. And I believe controlling trusted users is not effective and enough as they might become a target of attack especially after the PoC that is available on the website for how it is possible to hijack and evade system protection by using arbitrary Proxy DLL.  

And as Symantec System Administrator, I recommend adding the completed paths in the ADC policy and block creating of the DLL files that belong to the wrong directory.

I tried to collect all DLL files that called by Symantec processes after the boot and here is the list (I will add more later on)

%windir%\System32\ftapihook32.dll

%windir%\System32\wow64log.dll

%windir%\SysWOW64\rpcss.dll

%windir%\SysWOW64\fsllib32.dll

%windir%\SysWOW64\wbem\wbemcomn.dll

%windir%\SysWOW64\wbem\DSPARSE.dll

And here are more list that belongs to legitimate executable files but in DLL extension! and with a wrong directory location as well

%windir%\SysWOW64\NTOSKRNL.EXE.DLL

%windir%\SysWOW64\csrss.exe.DLL

%windir%\SysWOW64\SppExtComObj.Exe.DLL

%windir%\SysWOW64\audiodg.exe.DLL

%windir%\SysWOW64\wbem\unsecapp.exe.DLL

%windir%\SysWOW64\winlogon.exe.DLL

%windir%\SysWOW64\wininit.exe.DLL

%windir%\SysWOW64\SecurityHealthService.exe.DLL

%windir%\SysWOW64\slui.exe.DLL

%windir%\SysWOW64\sppsvc.exe.DLL

%windir%\SysWOW64\services.exe.DLL

%windir%\SysWOW64\dwm.exe.DLL

%windir%\SysWOW64\smss.exe.DLL

%windir%\SysWOW64\spoolsv.exe.DLL

%windir%\SysWOW64\lsass.exe.DLL

%windir%\SysWOW64\LogonUI.exe.DLL

%windir%\SysWOW64\UsoClient.exe.DLL

%windir%\SysWOW64\conhost.exe.DLL

%windir%\SysWOW64\sihost.exe.DLL

%windir%\SysWOW64\taskhostw.exe.DLL

%windir%\SysWOW64\smartscreen.exe.DLL

%windir%\SysWOW64\RuntimeBroker.exe.DLL

%windir%\SysWOW64\consent.exe.DLL

%windir%\SysWOW64\MusNotification.exe.DLL

Screenshot from the test

So the workaround that can be made is by adding the above files in the ADC policy in SEPM and block the attempt to create these files in the wrong directory.

So, when the hacker will try to inject a bad DLL file using any of the above DLL file names, the SEP will prevent this attempt the machine will stay safe as the below screenshot :)

Please with any ADC policy, you have to test in a testing environment, and then pilot it with a small number of PC that runs the business application and then you will be ready to go for rollout.

Download the below pre-define policy and import it into your ADC. unzip it first, then copy the dat file to your SEPM server, and then from the ADC policy tab import this policy and paste the entry into your existing ADC policy.

http://mahouk.net/Downloads/CVE-2019-12758_ADC.zip


Remember, don't forget to test it before apply :)

Amir,

Protect your outbound Emails!

 Level: Basic

Protect your outbound Emails!

Protecting inbound emails were and remain one of the main requirements to secure environments from external threats. At the beginning of the 3rd millennium, bad emails were considered as junk email and then things had developed and turned into a SPAM "bad email". SPAM was wasting employees' valuable time while reviewing dozens of unwanted emails every day which sometimes reached to hundreds. Bad email “SPAM” grows and becomes dangerous! Hackers utilized email technology and start transmitting phishing emails using attachments with an embedded virus or link. Most of the old email scanners at any MTA levels (Gateway, Exchange, Lotus,…) wasn’t designed properly to look for malware inside the file e.g. PDF or DOC. However, new technology such as Sandboxing is the right solution to protect organizations from malware inside legitimate files. Nowadays inbound SPAM controlled by many technologies including IP reputation, content scoring and more. Nevertheless, sometimes phishing technique bypasses the most sophisticated protection technology and targeting top persons in the organization, this called “spear phishing” and its focus on critical business employees such as CxO, HR, IT, Financial.

Many Security companies offer perfect protection against Email Threats (SPAM, Phishing, Sandboxing…) but they mention that protection protect 99.99% of the incoming threat, and unfortunately, the 0.01 always goes to CxO ☹. And I believe having ideal protection is impossible.

The question here is: What about outbound emails? What solutions available to protect emails leaving the organization? In the past most companies were more about secure inbound emails, they only started outbound protection after they become blacklisted or spoofed. Government sector, Financial and other institutions have also concern from leaking of data, so they consider Data Loss Prevention to protect classified data from been lack.

In this article, I will discuss three kinds of anti-spoofing technology (DKIM, SPF & DMARC) those are considered as kinds of outbound protection and used to enforce the integrity of the message. DKIM used to sign emails at gateway level, SPF used to register all outbound email system and DMARC is to see how DKIM and SPF are working and enforced.

DKIM:

I’m going to start with DomainKeys Identified Mail (DKIM), DKIM designed to detect email spoofing “Fake Sender”, DKIM defined in 2011 with RFC 8301 https://tools.ietf.org/html/rfc8301.

DKIM is a Digital Signature solution at Gateway level. The digital signature on user level is similar but it’s different in the detail. The digital signature is a solution offered to sign emails used an organization private key and then the recipient’s system will verify/authenticate email using the public key. DKIM uses DNS to publish the public key, so the recipient checks the public key by doing a TXT query on the DNS for the sender zone. Without DKIM, Organizations have to send their public key first and then the recipient will verify using local trusted keys in order to verify the digital signature. However, this type is manual way and it is not good to use if you have a huge number of users and recipient.

To implement DKIM, you need to do the following:

1. Generate Public and Private key
2. Add the public key in DNS as TXT record
3. Add the private key into your MTA server
4. Configure MTA to sign email for outbound

here is an example of the SPF records:

       

"v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQClKXSnsvrnUQMt9j6rGvLAWpkh" "kOXCHDVI4hDi7em5wkmRoQ/DU6iqpt4MmBxzlLxFO49ZzhiwyvEkFQY+kDdJ38JL"

"41VPI5+swhk7isqKvJDQvmc9clK0sdrfNPb1zuoGesB3Ah9ENZTWXuCVjngC0fpT" "KHQPbdkYKkcDrGceYwIDAQAB")

In above example for domain mahouk.net:

-        The code after P is my domain public key

-        v: is the version of the DKIM

-        t:s means the domain is not sending email using any subdomains

How it works?

1. The public key is defined in the public DNS as txt record.
2. The user sends an email to the public recipient
3. MTA sign the message using the private key
4. Email moved from MTA to destination MTA using SMTP session
5. Recipient MTA check public key that is published in the public DNS
6. Recipient MTA validate the email and then deliver it to the user mailbox

SPF:

Sender Policy Framework (SPF) is another type of email outbound protection. It is simple to understand and easy to implement. The SPF defined in 2014 with RFC 7208 https://tools.ietf.org/html/rfc7208.

SPF is a way that an organization use to tell recipients of the email if the email arrived from servers that belong to the organization or not, and if the email arrived from different servers then consider the email as spoofed.

SPF has four main qualifiers:

• (+) for a pass: it means to authorize the sender
• (-) for fail: means unauthorize sender (if -all is defined in the record then it means the recipient should only receive emails from the pre-defined server, if not then the recipient should not trust the email and consider it as spoofed, this called hardfail)
• (~) for soft fail: it is like the fail option, however, it doesn’t mean a real fail. It is more used for testing purpose
• (?) for neutral: it means that the sender tells to accept the email even if the email came from any source of the network. This is the default configuration if the SPF record is not defined completely.

Here is a recommended website to create SPF record:  https://www.spfwizard.net

An example of the SPF records:

• Single server

v=spf1 ip4:1.2.3.4 -all

It means to accept email only from server 1.2.3.4

• MX servers

v=spf1 mx -all
It means to accept email only from any server that is defined as mx record

• Mix DNS records and IPv4

v=spf1 a mx ip4:1.2.3.4 ~all
It means to accept email from any server, make softfail if the email sent by other than servers mentioned in “A” records or “MX” records or IP:1.2.3.4

Note: if the "? all" is mentioned then it means to accept the email and don’t make it as softfail.

How it works?

1. All servers used to send email to the outside is defined in the public DNS as txt record.
2. The user sends an email to the public recipient
3. Email sent to outside of the organization using server IP or Name that is mentioned in the Txt record.
4. Email moved from MTA to destination MTA using SMTP session
5. Recipient MTA validates IP or name and makes sure it is available in the TXT record that is published in the public DNS
6. Recipient MTA validate the email and then deliver it to the user mailbox
7. The user received an email sent server belongs to the sender domain

DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the most interesting outbound protection technology, this technology was defined in 2015 in RCF 7489 https://tools.ietf.org/html/rfc7489

DMARC is the only solution to know if your domain users are successfully authenticated by email recipient’s system, it can check both SPF or DKIM and send a report every day to you about the authenticated emails. With DMARC, organizations could define policies to tell the recipients how to deal with authenticated/unauthenticated emails coming from their domain. Also, they can enforce alignment policy such as define domain and subdomain to be enforced even if it passes DKIM or SPF. DMARC is easy to implement but hard to maintain! The report messages from other systems are very hard to review and manage. This led security companies to develop tools to make this feature more effective, some companies now have a solution to manage the report emails sent by the recipient’s system. Some example of these companies like DMARC Analyzer, OnDMAR, Agari,.. 

The feedback report is one of the great features of DMARC. DMARC can be configured to send two separate reports aggregate (rua) and Forensic/Failure (ruf) reports. The reporting feature will help the domain owner to know who is trying to spoof their domain and make sure that all of their systems are perfectly working.

You can define three different policies to tell the recipient’s system what to do when receiving an email, it will be a request, not an obligation. Here is a list of policies (P):

• P=None: it used for monitor purpose, rua and ruf will function normally and then you can know if the configuration of DKIM and SPF is correct
• P=Quarantine: this to tell the mail recipient system to put the email into the spam folder
• P=reject: this to tell the mail recipient system to not deliver the email to the mailbox. The best is to delete this at the gateway level.

To implement DMARC, you need to do the following:

1. Make sure you have SPF and DKIM (you can have one but it is not recommended)
2. Define policy (None, Quarantine or reject and define the bounce report email for mua or muf)
3. Use DNS to create TXT record for DMARC that define the policy and bounce report email
4. Start with testing policy and then switch to production.

How DMARC works?

1. SPF + DKIM + DMAC policies are added in the DNS.
2. The user sends an email to the public recipient
3. Email sent to outside after sign using the private key and by using company’s server that is defined in SPF.
4. Email moved from MTA to destination MTA using SMTP session
5. Validate email using public key + check if the email came from the registered server.
6. Recipient MTA validate the email and then deliver it to the user mailbox
7. The user received an email sent server belongs to sender domain and signed by sender’s server 
8. In case of failed authentication, the recipient domain system will send feedback to the email defined in public DNS.

I'm going to demonstrate each part in the future and hope if you send me your comments to improve this article.

thanks

Patch Tuesday & Exploit Wednesday

Risk of Tuesday Patch

Level: Basic

In Computer Systems, the word “Patch” refers to a code correction in Software or Operating System. The correction is mandatory to fix a bug (the bug is a mistake in code logic or syntax) that might cause a security hole which known by Security Professionals as "Vulnerability". The person who discovers a bug could be a cracker or software programmer. However, the vulnerability might not be disclosed to the public which means the number of non-disclosure vulnerabilities is more than the number of discovered one, and there is a big business on the dark web behind on the non-published vulnerabilities.

The crackers might create an exploit to get full benefits from the discovered vulnerability, if this happened then we have a risk. The risk can be explained as this formula: 

Risk = Threat “Exploit” X Vulnerability.

Let's talk about Microsoft updates. The good news with Microsoft is that security updates are releases frequently every second Tuesday from each month. The bad news is when Microsoft releases an update, the attacker might use reverse-engineered technic in order to understand the idea/logic behind the released patch and then he/she can create and use the exploits to take over non-patch systems. This mean, the patch could become a danger if it was not rollout to machines immediately. The fancy name for this is “Patch Tuesday and Exploit Wednesday”.

Here is illustrator show this work

Complete image without animation

(1) Above is an example of a running MS-Apps and next Patch Tuesday and Exploit Wednesday. (2) Patches supposed to be released on Tuesday 9 of April 2019. (3) Organizations take from 1 to 10 days to patch all systems. (4) attacker use reverse-engineer technic to understand or get an idea about the bug. (5) Antivirus companies update their definition signature and HIPS "Host Intrusion Detection System" to protect machines... In the meantime, there is a big question on the time between (4) and (3) as the more time it takes to rollout patches it would be considered as risk on the non-patched systems, and if an incident occurs before (5) then it will be categorized as a zero-day attack. 

It is recommended to classify systems in three or more categorization here is an example: Testing, Critical, and Workstations. The patch should be tested before rollout patch to all servers. Personally, I recommend rebooting the tested server after the patch operation. System admins need to ready for any disaster in case the update makes damage to system/service. 

You can use the free tools “WSUS” for patching Management or use a commercial solution such as Lumension, Microsoft SCCM or Symantec Altiris.

let's waste attacker time and do a real change on the title to be from exploit Wednesday to Happy Wednesday 😄

Amir

Symantec DCS 6.8 new feature demonstration “Anti-Malware”

Symantec DCS 6.8 new feature demonstration “Anti-Malware”

In January 2019, Symantec released a new version for DCS with a great feature for Linux RHEL and Ubuntu. The Linux administrator will not be asked to install AV along with DCS agent anymore! as both are bundled in one agent. The feature still limited to two Linux distribution and limited to release version as well, and I believe this is just the startup and Symantec going to support more version with the later release.

 

I’m going to do some hands-on activity on this feature and review the policy behind It. This demonstration is held in a small lab using VirtualBox for image hosting, also the EICAR test file will be used to see the event and how DCS will protect the system in real time.

In the lab, I have DCS server running under Windows 2016, The testing Linux system is ubuntu 16.04.5.

From the Dashboard, we can see virus detected is migrated from the previous version. However, the virus detection widget was related to the agentless feature that is developed to be used for VM NSX solution.

I installed DCS agent “agent64-linux-ubuntu16.bin” in Ubuntu Linux and then perform a restart. Then I use a text editor to create a file name called Test_virus_@AmirMahouk.com

Here is the file content…

Then I use winscp utility to move the test virus from host machine to Linux image in /home/amir/ folder

I noticed that Malware Protection feature affected immediately, even before configuring a policy or enabling prevention mode. I create a gif file to simulate this activity

And here is the event from DCS portal

Event details

This feature can be customized using DCS java console and it allows administrators to add exclude list as well as configuring local Live update server “LUA”. To customize this setting, from DCS Java console, (1) under configs tab, (2) detection tab, (3) Symantec Folder, (4) then double click on the “Default Detection Parameters”. as shown below

We will get the default detection parameters Window and under AV config tab we will see the setting related to the Malware Protection feature. 

(A) is the general setting that can enable the auto-protect or enable scan of the external drive. 

(B) is the quarantine path to store the detected file. “I add some little details below”. 

(C) is the inclusion path, if no value is added then it will scan all folders. 

(D) is the exclusion list

(E) is the Live update URL, it uses Symantec standard LiveUpdate servers if the URL is blank, or it could use the internal LiveUpdate server if the URL is mentioned.

Malware setting in Linux

The configured setting in the java console is reflecting in AntiMalware.ini file under  /opt/Symantec/sdcssagent/AMD/system

Restore file from quarantine

First, we have to add the file into the exclude list under the DCS java console, then restore the file by using the AMDRestoreTool file under /opt/Symantec/sdcssagent/AMD/tools

As you can see the file name "158989114370783ee.qur" is randomly named and it will be hard to know the exact file in case you have many files in the quarantine as shown in below (A). so the best step to know the exact file is to use grep command by type 

grep -r “AmirMahouk.com” /var/log/sdcsslog/quarantine/  as shown below in (B).

Note: AmirMahouk.com is part of the file name that required to be restored

Then you will see as shown in (C) the exact file name that needs to be used in the restore command above

Issue found during the testing

While doing the test, I noticed that malware function suddenly stopped working. Then I remove DCS agent and reinstall it with no luck. However, I found this error during the installation which means this feature will not work probably if the machine has than 4GB as RAM.

here is all that I have today, I will keep demonstrating new valuable feature in the next posts.

Please leave a comment if you find this valuable for you

Thanks

Windows 10 Insider Program

Be careful when you are using windows 10 Insider Program for testing, as Microsoft having your permission when you accepted the agreement letter, so they will collects information when you are typing a text, collect some data and collects information about files as they mentioned that clearly in their team of service and privacy policy.

to be in safe side, make sure to not use your password, information, business documents while using windows 10 testing version.

Link to privacy policy

http://windows.microsoft.com/en-gb/windows/preview-privacy-statement

Kon-boot

Yesterday I purchased kon-boot utility for testing purpose from PIOTRBANIA.COM, and today I found our Domain Controller in front of me J, our domain controller is windows 2008 R2. Actually the utility worked perfectly and it bypassing the domain administrator Password simply. Kon-boot is awesome utility, it is simple and cheap.

To avoid this kind of bypass, I strongly recommend to do the following:

1.        Disable USB/CD from Bios
2.        Protect access to Bios with password
3.        Disable boot from LAN on all servers
4.        if available, use Secure Boot feature.
5.        Physically lock servers to avoid Bios password reset
6.        Keep monitor servers room entrance

Using this utility will allow hackers to open a door or create a username with full privilege on the network to use it later.

And finally, I like this utility. And would thank the team behind it.

Amir