FTC Issues Alert on Tech Support Scams

The Federal Trade Commission has released an alert on tech support scams. Scammers use pop-up messages, websites, emails, and phone calls to entice users to pay for fraudulent tech support services to repair problems that don’t exist. Users should not pay or give control of their devices to any stranger offering to fix problems.

NCCIC encourages users and administrators to refer to the FTC Alert and the NCCIC Tip on Avoiding Social Engineering and Phishing Attacks for more information. If you believe you are a victim of a tech support scam, file a complaint at www.FTC.gov/complaint.

Ubuntu Firewall: Basic Introduction

This is a basic introduction to Ubuntu firewall using the terminal commands.  This tutorial requires you have administrative access to your Ubuntu system.  If you installed Ubuntu the first account created by default has administrative access via sudo.  You will need to type sudo for each command illustrated below.  The system will ask for your login password the first time (it will remember that password for about 15 minutes).  Follow the steps below to check and modify the firewall.

Open a terminal window (ctrl t).  In the terminal window enter:

you@ursystem:~$ sudo ufw status

[sudo] password for you:

Status: inactive

ufw stands for uncomplicated[1] firewall.  It is a very simple interface to get you started.  All modern Linux firewalls are based on the packet filtering framework developed and maintained by the folks at netfilter.org.

In the above example the firewall is not running to enable the firewall enter the command:

you@ursystem:~$ sudo ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y

Firewall is active and enabled on system startup

You have enabled your firewall try the status command again to see the results.  It reports active.  The firewall is active but you have not set any rules.  To allow ssh connections to your system enter the command:

you@yoursystem:~$ sudo ufw allow ssh

Rule added

Rule added (v6) (note this is displayed if you are also using IP v6)

You have just added ssh however you have allowed connection to port 22 from any location on the internet (using both UDP and TCP).  You have also allowed connection using IPv6.  If you are only using IPv4 delete the rule for IPv6 and harden the remaining rule to only allow tcp.  To verify the above rules created enter the status command again.  Look at the “From” column.

you@yoursystem:~$ sudo ufw status

Status: active

To                    Action     From

—                    ——     —-

22                    ALLOW      Anywhere

22 (v6)               ALLOW      Anywhere (v6)

 

Notice the one command generated 2 rules.  It is best to be very specific and allow only the ip addresses you expect to connect from and the protocol to use.  In this case we want to only allow TCP and from one IP address, using IPv4.  I will delete the above rules, using the reset option.

You can reset the firewall by using the reset options as follows:

sudo ufw –force reset

 

Notice the “–force” option, this issues the command without asking for permission.  The firewall is back to defaults.  Issue “sudo ufw status” to verify.

Let’s enable the firewall again only this time to one specific IP address and using the TCP protocol version 4.  To do so gather the IP address you want to ssh from and enter that IP in the command:

sudo ufw allow from {your ip address in here} to any port 22 proto tcp

 

Enter the command for status “sudo ufw status”.  What do you see?  Even though you created a firewall rule the firewall is still disabled from the previous reset command.  Enable the firewall “sudo ufw enable” and run the status command again.  You should see the new rule you just created.

This rule allows only the IP address entered in the brackets to connect to your system, via ssh.

In order to modify the rules you need to list them with numbers so enter the command:

 

you@yoursystem:~$ sudo ufw status

Status: active

To                         Action      From

—                         ——      —-

22/tcp                     ALLOW       10.0.0.20

 

Let’s add another rule to allow connections to your systems web server.

 

you@yoursystem:~$ sudo ufw allow from 10.0.0.20 to any port 80 proto tcp

Rule added

you@yoursystem:~$ sudo ufw status

Status: active

To                         Action      From

—                         ——      —-

22/tcp                     ALLOW       10.0.0.20

80/tcp                     ALLOW       10.0.0.20

Now you have 2 rules.  Let’s list the rules with the associated number.  Listing rules with numbers is needed when deleting rules.

 

you@yoursystem:~$ sudo ufw status numbered

Status: active

     To                         Action      From

     —                         ——      —-

[ 1] 22/tcp                     ALLOW IN    10.0.0.20

[ 2] 80/tcp                     ALLOW IN    10.0.0.20

Notice the numbers 1 and 2 in brackets, on the left before the rule.  That represents the number for that rule.

 

To delete the second rule enter the command:

you@yoursystem:~$ sudo ufw delete 2

Deleting:

allow from 10.0.0.20 to any port 80 proto tcp

Proceed with operation (y|n)? y

Rule deleted

 

UFW verified you wanted to delete rule 2 and it requested you answer yes with a y.  If you do not want to be prompted use the “–force” options as illustrated earlier.  Below is a list of other commands you can issue (copied from the man page).

 

ufw [–dry-run] enable|disable|reload

ufw [–dry-run] default allow|deny|reject [incoming|outgoing|routed]

ufw [–dry-run] logging on|off|LEVEL

ufw [–dry-run] reset

ufw [–dry-run] status [verbose|numbered]

ufw [–dry-run] show REPORT

ufw [–dry-run] [delete] [insert NUM] allow|deny|reject|limit [in|out] [log|log-all] [  PORT[/PROTOCOL]

| APPNAME ] [comment COMMENT]

ufw   [–dry-run]   [rule]  [delete]  [insert  NUM]  allow|deny|reject|limit  [in|out  [on  INTERFACE]]

[log|log-all] [proto PROTOCOL] [from ADDRESS [port PORT | app APPNAME ]] [to ADDRESS [port PORT  |  app

APPNAME ]] [comment COMMENT]

ufw [–dry-run] route [delete] [insert NUM] allow|deny|reject|limit [in|out on INTERFACE] [log|log-all]

[proto PROTOCOL] [from ADDRESS [port PORT | app APPNAME]] [to ADDRESS [port PORT | app APPNAME]]  [com‐

ment COMMENT]

ufw [–dry-run] delete NUM

ufw [–dry-run] app list|info|default|update

 

As you can see ufw provides a plethora of commands and options.  Let’s take the commands apart.

Above you see [–dry-run] which is the option to test the command without enabling it.  The firewall can be enabled, disabled or the rules reloaded.  The default behavior of the firewall can be se with the default option.  You can set the log level to (low, medium, high or full) or turn it on of off.  Reset, resets the firewall as illustrated above.  The status command has the option numbered (illustrated above) or verbose which gives you additional information as to the behavior.  You can add comments to the rules and even specify application names.  The applications are stored in /etc/ufw/applications.d.

 

The show REPORT option gives you details about what the firewall is doing for example try this command:

you@yoursystem:~$ sudo ufw show listening

tcp:

139 * (smbd)

22 * (sshd)

[ 1] allow from 10.0.0.20 to any port 22 proto tcp

 

445 * (smbd)

tcp6:

139 * (smbd)

22 * (sshd)

445 * (smbd)

udp:

137 10.0.0.255 (nmbd)

137 10.0.0.80 (nmbd)

137 * (nmbd)

138 10.0.0.255 (nmbd)

138 10.0.0.80 (nmbd)

138 * (nmbd)

37937 * (dnsmasq)

49595 * (avahi-daemon)

5353 * (avahi-daemon)

631 * (cups-browsed)

udp6:

46295 * (avahi-daemon)

5353 * (avahi-daemon)

 

Notice the firewall is listening on so many ports can you tell if this is a server or desktop os?  It’s most likely a desktop OS since it is listening on the Windows ports.

 

In conclusion ufw has many options and supports a simple and full syntax.  I recommend using the full syntax and be very specific to open the specific port, protocol and ip addresses that need access.

[1] https://help.ubuntu.com/lts/serverguide/firewall.html.en

Macy’s and Bloomingdale’s just announced a data breach that’s exposed sensitive customer info

Here’s what you need to know about the Macy’s and Bloomingdale’s breach
  • Macy’s and Bloomingdale’s (both owned by parent company Macy’s, Inc.) recently sent letters to some of their online customers confirming the retailer had discovered a cybersecurity threat to its systems on June 11, 2018.
  • According to the letters, “an unauthorized third party, from April 26, 2018, through June 12, 2018, used valid customer usernames and passwords to log in to customer online profiles.”
  • Hackers were able to access users’ first and last names, addresses, phone numbers, email addresses, birth dates, and debit and credit card numbers with expiration dates, Macy’s said.
  • See this article for more information.
How to protect your info after this breach
To support you during this time, we’ve put together some guidelines to help you protect yourself:
  • Change your Macys.com or Bloomingdales.com password(s).
  • Monitor your credit/debit card accounts for any suspicious activity.
  • Update any debit/credit cards you’ve used on Macys.com or Bloomingdales.com.
  • Check your credit report regularly to keep an eye on any unauthorized activity.

SplunkLive! DC – 7/19 @ The Convention Center

Our friends at Splunk are pleased to announce that Registration is Now Open for SplunkLive! Washington, D.C. on July 19.

  

SpunkLive! Washington D.C

Date: July 19, 2018

Time: 8:00 am – 4:00 pm

Location: Walter E Washington Convention Center 

801 Mount Vernon Place NW

Washington, DC 20001

Registration page: http://live.splunk.com/splunkliveDC-07192018

Keynote Speaker:

Declan Morris, Splunk CIO

Public Sector Luncheon:

Special luncheon, including a panel discussion exclusively for Public Sector (government, Aerospace & Defense, Higher Education) participants

Breakout Sessions & SE Presenters:

The final agenda including the breakout sessions is listed below. 

 

Agenda:

Time Description
8:00am Breakfast and Registration
9:00am Turn Data into Answers with Splunk
Declan Morris, CIO, Splunk
Overview Track IT Ops Track Security Track Industry Track
10:45am Improve Your Velocity With Splunk Cloud Gain Real Time Insights from Your Data Using Splunk and AWS Cloud Solve Your Security Challenges with Splunk Leveraging Continuous Monitoring with Splunk to Support Compliance Requirements
11:45am Lunch
12:45pm Get More from Your Machine Data with Splunk AI Analytics Through DevOps Lifecycle Intro to Security Analytics Methods Enabling Efficient Government with Splunk
2:00pm Getting Data In Predictive, Proactive and Collaborative ML with Splunk ITSI Accelerate Incident Response Using Automation and Orchestration Keeping Agency Operations Humming with Event Analytics
3:00pm Reception — PartnerZone

 

Installing ClamAV on CentOS 7

Referenced from Linux-Audit:

To get ClamAV on CentOS installed, we have to use the EPEL repository (Extra Packages for Enterprise Linux). Fortunately, the Fedora project provides this with an easy installation. Unfortunately the default configuration is not properly working. In this post we collect some of the issues and required changes.

Let’s start with installing the EPEL support.

  • yum install epel-release

Next step is installing all ClamAV components.

  • yum install clamav-server clamav-data clamav-update clamav-filesystem clamav clamav-scanner-systemd clamav-devel clamav-lib clamav-server-systemd

 

Installing ClamAV with help of EPEL repository

Configure SELinux for ClamAV

If you are using ClamAV on CentOS, together with SELinux, we should configure it a little bit. This way ClamAV can access all files on disk, and update its data definition files.

Enable antivirus_can_scan_system:

  • setsebool -P antivirus_can_scan_system 1

 

Configuration of Clam daemon

Copy a the clamd.conf template, in case you don’t have a configuration file yet.

  • cp /usr/share/clamav/template/clamd.conf /etc/clamd.d/clamd.conf
    sed -i ‘/^Example/d’ /etc/clamd.d/clamd.conf

Change /etc/clamd.d/clamd.conf file and define if you want to run the scanner as root, or a specific user. Check your /etc/passwd file for the related Clam user.

Change the following two options:

  • User clamscan
    LocalSocket /var/run/clamd.<SERVICE>/clamd.sock

Enable Freshclam

Freshclam helps with keeping the database of ClamAV up-to-date. First delete the related “Example” line from /etc/freshclam.conf.

  • cp /etc/freshclam.conf /etc/freshclam.conf.bak
    sed -i ‘/^Example/d’ /etc/freshclam.conf

Check the other options in the file, and change it to your preferred settings.

Missing systemd service file

We didn’t get a systemd service file, so creating a quick file here. The process should be forking itself and start freshclam in daemon mode. In this case we configure it to check 4 times a day for new files.

Create a new file /usr/lib/systemd/system/clam-freshclam.service

# Run the freshclam as daemon

[Unit]

Description = freshclam scanner

After = network.target

 

[Service]

Type = forking

ExecStart = /usr/bin/freshclam -d -c 4

Restart = on-failure

PrivateTmp = true

 

[Install]

WantedBy=multi-user.target

Now enable and start the service.

  • systemctl enable clam-freshclam.service

 

  • systemctl start clam-freshclam.service

Check the status.

[root@centos7 system]# systemctl status clam-freshclam.service

clam-freshclam.service – freshclam scanner

Loaded: loaded (/usr/lib/systemd/system/clam-freshclam.service; enabled)

Active: active (running) since Thu 2015-06-11 11:09:24 CEST; 1s ago

Process: 3158 ExecStart=/usr/bin/freshclam -d -c 4 (code=exited, status=0/SUCCESS)

Main PID: 3159 (freshclam)

CGroup: /system.slice/clam-freshclam.service

└─3159 /usr/bin/freshclam -d -c 4

Change service files

By default, the service files seem to be messy and not working.

These are the files bundled:

[root@centos7 system]# ls -l /usr/lib/systemd/system/clam*

-rw-r–r–. 1 root root 136 Apr 29 20:38 /usr/lib/systemd/system/clamd@scan.service

-rw-r–r–. 1 root root 231 Apr 29 20:38 /usr/lib/systemd/system/clamd@.service

When enabling the clamd service, we would see something like this:

[root@centos7 system]# systemctl enable /usr/lib/systemd/system/clamd@.service

Failed to issue method call: Unit /usr/lib/systemd/system/clamd@.service does not exist.

So let’s fix it. First rename the /usr/lib/systemd/system/clamd@.service file.

Rename the clamd@ file.

mv /usr/lib/systemd/system/clamd@.service /usr/lib/systemd/system/clamd.service

Now we have to change the clamd@scan service as well, as it refers to a non-existing file now. Change this line in /usr/lib/systemd/system/clamd@scan.service and remove the @ sign.

.include /lib/systemd/system/clamd@.service

Next step is changing the clamd service file /usr/lib/systemd/system/clamd.service

[Unit]

Description = clamd scanner daemon

After = syslog.target nss-lookup.target network.target

 

[Service]

Type = simple

ExecStart = /usr/sbin/clamd -c /etc/clamd.d/clamd.conf –foreground=yes

Restart = on-failure

PrivateTmp = true

 

[Install]

WantedBy=multi-user.target

Move into the directory.

cd /usr/lib/systemd/system

Start all services.

[root@centos7 system]# systemctl enable clamd.service
[root@centos7 system]# systemctl enable clamd@scan.service
[root@centos7 system]# systemctl start clamd.service
[root@centos7 system]# systemctl start clamd@scan.service

Checking the status

With all these changes, ClamAV on CentOS 7 should be running now. The easiest way to check, is using the ps command and see if freshclam and clamd are running.

Useful resources for debugging are the systemctl status command, followed by the service. Then there is logging in /var/log/messages, which usually will reveal when and why something is (not) running.

 

Burp to Brute Force a Login Page

Using Burp to Brute Force a Login Page

Authentication lies at the heart of an application’s protection against unauthorized access. If an attacker is able to break an application’s authentication function then they may be able to own the entire application.
The following tutorial demonstrates a technique to bypass authentication using a simulated login page from the “Mutillidae” training tool. The version of “Mutillidae” we are using is taken from OWASP’s Broken Web Application Project. Find out how to download, install and use this project.

First, ensure that Burp is correctly configured with your browser.
In the Burp Proxy tab, ensure “Intercept is off” and visit the login page of the application you are testing in your browser.

Return to Burp.
In the Proxy “Intercept” tab, ensure “Intercept is on”.

In your browser enter some arbitrary details in to the login page and submit the request.

The captured request can be viewed in the Proxy “Intercept” tab.
Right click on the request to bring up the context menu. Then click “Send to Intruder”. Note: You can also send requests to the Intruder via the context menu in any location where HTTP requests are shown, such as the site map or Proxy history.

Go to the Intruder “Positions” tab.
Clear the pre-set payload positions by using the “Clear” button on the right of the request editor. Add the “username” and “password” parameter values as positions by highlighting them and using the “Add” button. Change the attack to “Cluster bomb” using the “Attack type” drop down menu.

Go to the “Payloads” tab.
In the “Payload sets” settings, ensure “Payload set” is “1” and “Payload type” is set to “Simple list”. In the “Payload options” settings enter some possible usernames. You can do this manually or use a custom or pre-set payload list.

Next, in the “Payload Sets” options, change “Payload” set to “2”.
In the “Payload options” settings enter some possible passwords. You can do this manually or using a custom or pre-set list. Click the “Start attack” button.

In the “Intruder attack” window you can sort the results using the column headers.
In this example sort by “Length” and by “Status”.

The table now provides us with some interesting results for further investigation.
By viewing the response in the attack window we can see that request 118 is logged in as “admin”.

To confirm that the brute force attack has been successful, use the gathered information (username and password) on the web application’s login page.

Account Lock Out

In some instances, brute forcing a login page may result in an application locking out the user account. This could be the due to a lock out policy based on a certain number of bad login attempts etc. Although designed to protect the account, such policies can often give rise to further vulnerabilities. A malicious user may be able to lock out multiple accounts, denying access to a system. In addition, a locked out account may cause variances in the behavior of the application, this behavior should be explored and potentially exploited.

Verbose Failure Messages

Where a login requires a username and password, as above, an application might respond to a failed login attempt by indicating whether the reason for the failure was an unrecognized username or incorrect password. In this instance, you can use an automated attack to iterate through a large list of common usernames to enumerate which ones are valid. A list of enumerated usernames can be used as the basis for various subsequent attacks, including password guessing, attacks on user data or sessions, or social engineering.

Scanning a login page

In addition to manual testing techniques, Burp Scanner can be used to find a variety of authentication and session management vulnerabilities. In this example, the Scanner was able to enumerate a variety of issues that could help an attacker break the authentication and session management of the web application.

Refernced from – https://support.portswigger.net/customer/portal/articles/1964020-using-burp-to-brute-force-a-login-page