Skip to content

Category: Security

Google Responds to GMail Vulnerability Allegations

Google says the recent GMail account breeches were due to typical phishing scams, not a vulnerability in GMail itself.

With help from affected users, we determined that the cause was a phishing scheme, a common method used by malicious actors to trick people into sharing their sensitive information. Attackers sent customized e-mails encouraging web domain owners to visit fraudulent websites such as “google-hosts.com” that they set up purely to harvest usernames and passwords.

They don’t say exactly how the usernames and passwords were harvested, however.  Were people just dumb/gullible enough to type their Google usernames and passwords into some other web site?  Or was there a way for these phishing sites to grab the authentication info from the user’s browser?  Is this the fault of the web browser or a faulty plugin?

While the fingers continue to be pointed, the specific methodology for adding malicious filters to a GMail account by way of a phishing attack remains a threat.

GMail Vulnerability? Watch Your Back.

I’ve been following the story about the domain name hijacking of MakeUseOf.com the last few weeks with interest.  All signs are pointing to the domain thief having cracked the MakeUseOf.com Gmail account in order to retrieve their GoDaddy.com password and transfer the owenership of the domain.

This is not good for any GMail user, let alone domain name owners who have registered their domains through GMail.

Apparently, this one hacker has stolen over 850 domains this way, and holds them for ransom at $2000 a piece.

The latest part of the saga details how the MakeUseOf.com folks think this happened, right down to the hacking of the GMail account.  If there is indeed a security flaw in GMail, which there appears to be, MakeUSeOf.com offers prudent steps to take in order to secure yourself (emphasis added by me):

(1) Well, my very first advice would be to check your email settings and make sure your email is not compromised. Check fowarding options and filters. Also make sure to disable IMAP if you don’t use it. This also applies to Google Apps accounts.

(2) Change contact email in your sensitive web accounts (paypal, domain registrar etc.) from your primary Gmail account to something else. If you own the website then change the contact email for your host and registrar accounts to some other email. Preferably to something that you aren’t logged in to when browsing web.

(3) Make sure to upgrade your domain to private registration so that your contact details don’t show up on WhoIS searches. If you’re on GoDaddy I’d recommend going with Protected Registration.

(4) Don’t open links in your email if you don’t know the person they are coming from. And if you decide to open the link make sure to log out first.

I would add to that list:

(5) Always use secure, encrypted GMail.  There is an option at the bottom of the main Settings page in GMail for “Always use https” under the “Browser Connection” heading.  Select this and leave it selected!  Otherwise, anything you do in GMail is sent unencrypted over the Internet.  Not good!

Keep in mind that this security flaw not only matters to domain name owners, but to anyone who has any sensitive email in their GMail account, whether it be online banking info, love letters, or whatever.

This will be interesting to watch, and I hope Google takes notice of this.

UPDATE:  This fellow here has posted a proof-of-concept on creating malicious filters in someone’s GMail account.

Who’s hogging the pipe?

If you’ve found yourself in a Network/System Admin position without the proper tools, and can’t seem to get them, there’s usually a way to do things for free with Linux or at least using the repos provided under an enterprise support package such as RHEL. 🙂 This is for monitoring who’s chewing up the pipe by IP address.

* Obviously there’s 100 ways to skin a cat in Open Source, but this is one way that can take you from “Who’s hogging the pipe” to “HEY! Stop doing that” in 15 minutes. Granted this isn’t meant for controlling the traffic, that’s another story. *

How To: ( Warning! – You may need to verify this action with your IT Dept – Warning!)

1. On the Core switch just before the “Gateway” hop takes place, and Pre-NAT rules, you’ll need to enable a port for monitoring the traffic (both TX and RX) to and from the “Gateway”. This box could also be used as a SNORT box. (once again another story)

2. You’ll need a Linux box with dual NIC’s (for remote usage) or a single NIC with Physical terminal access for direct access only.

3. Install and run/configure “iptraf” (using sudo or root access) 
#sudo yum install -y iptraf
#sudo iptraf (once the Screen launches, hit any key)
Scroll down to “Configure” (enter)
Set “Force Promiscuous mode” to ON
(You may wish to keep “Reverse DNS Lookups” off as well)
(Adjust “Additional ports” or any other settings if needed)
“Exit Configuration”
Select “IP Traffic Monitor”
Select the interface that’s plugged into the “Monitored” port. (from Step 1.)
Once the monitoring begins you can sort by bytes or packet count etc.

Find the “Hogger”.

Note: I really like the “iftop” tool as well, but it’s not in the RHEL Repos. ;0)

You can’t control the traffic from this app, but at least you can verify if the traffic is legit or not. Once you have the ip you can do the standard ip/arp/mac table lookups etc. to locate the machine.

HTH.

dbcooper

Practical Security: Wireless Network Security & WPA

In light of the latest wireless vulnerability found, which can break “WPA” using “TKIP” for encryption, I thought I would advise everyone to review your home wireless setup.

The subject of securing your wireless (or wired) networks at home could be talked about for hours on end, and depending on what hardware (model/brand) you have, your set-up and configurations may vary. Please see the documentation that came with your device or the company’s website for more information on the specific model you have. Also, don’t hesitate to call or email the vendor for help if needed.

Basically it comes down to these few things:

  1. Don’t broadcast your SSID if possible. (See your manual, and see this link)
  2. Use Wireless MAC filtering if possible. (See your manual, and see this link)
  3. Don’t use WEP for encryption.
  4. Don’t use WPA w/TKIP (this is now breakable).
  5. Change your WPA from TKIP to AES for encryption. (See your manual)
  6. If your hardware (computer and wireless router) supports it, move to WPA2. (See your manual)

General Home Computer Security Info:

  1. Make sure your Anti-virus application is updating/updated and enabled.
  2. At a minimum, make sure the Windows Firewall is enabled (unless you are on a Mac, in which case you should turn yours on too).
  3. Use strong passwords comprised of alpha/numeric/special characters on all your “Admin” level computer accounts.
  4. If you have any files or folders shared over your home network, make sure they are password protected.

There are a million resources for articles on computers and security online, but here are a few good ones if you are new or inexperienced with the subject (or just need a refresher).

Microsoft Security Resource for Home Users:
http://www.microsoft.com/protect/default.mspx

US-CERT.GOV – Home Users:
http://www.us-cert.gov/nav/nt01/
http://www.us-cert.gov/reading_room/home-network-security/

CERT.ORG – Home Users:
http://www.cert.org/homeusers/
http://www.cert.org/homeusers/HomeComputerSecurity/
http://www.cert.org/tech_tips/home_networks.html

With all that said, have a safe, secure, and happy computing day.

Captchas. No, I didn’t sneeze.

Are captchas annoying to you?  They are to me.  I probably fail at solving them about 15% of the time, which is far too often for my liking.  They get annoying, and as spammers find ways to automate solving them, the captchas continue to get more difficult to read.

Someone who knows a lot about combating spam, and has done a pretty darned good job at it, Matt Mullenweg, suggests in a recent Guardian article that “…Captchas are useless for spam because they’re designed to tell you if someone is ‘human’ or not, but not whether something is spam or not.”  I would have to agree.

There are many efforts to improve upon Catpchas, such as the 3-D Captcha.  In my opinion, this is just making things more complicated than necessary, and would be difficult to implement easily on a typical blog or contact form.

I run about 6 to 8 blogs (depending on my mood from week to week), and have been reluctant to use Captchas on any of them, partly out of usability concerns, but also because they are so easy to fail.  Instead, for my blog comments, I rely upon Mullenweg’s own Kismet spam system.  This feature is built into WordPress blogs, which makes it a breeze to set up, and I am constantly amazed at the loads of spam comments that it stops.

As Mullenweg suggests, focusing on the content rather than the submitter, is the way to go in the long term, and Kismet is great at doing that.

However, I also rely on a simpler test to determine if someone is a human or not mainly because it’s not as annoying as a Captcha, and it prevents a lot of spam comments from making it through in the first place.  It’s easy to add a basic question to a form which must be answered correctly in order for the form to be submitted succesfully.  Questions could be as simple as:

  • What color is an orange?
  • What is 3 plus 3?
  • How many wheels does a car have?

There is a great WordPress plugin which provides this capability and is relatively easy to set up called the Secure and Accessible PHP Contact Form.  If you run any WordPress blogs, I recommend you try it out.

By having a list of simple questions that are randomly selected to appear on your forms, you can stop automated scripts from filling out your forms quite easily.  This, combined with Kismet, a content-based filter of what gets submitted, will pretty much stop spammers in their tracks without creating a hassle for your visitors.

Setting up Samba Shares on RedHat Enterprise 5

My goal was to set up a network share on a RHEL5 server using Samba, so that our Windows users could access the shared folder from their desktops.  It was difficult to find any information on doing this and nothing else, such as setting up Samba as a domain controller, which I was not interested in.  Sometimes Google gives you more than you want.

If you are running RedHat Enterprise 5, and are interested in setting up Samba shares for Windows users to access, read on.  This may work for other flavors of Linux, and older versions of RHEL, but I can’t vouch for that.

First, make sure the correct Samba packages are installed:

#> rpm -qa |grep samba
samba-client-3.0.28-1.el5_2.1
samba-3.0.28-1.el5_2.1
samba-common-3.0.28-1.el5_2.1
system-config-samba-1.2.39-1.el5

If these are not installed, use yum to grab them and install them.

You may need to open ports in the system firewall so that all of this will work.  The ports that need to be open for Samba to work are:

139 and 445

It’s easiest to do this from your RedHat gui (System > Administration > Security Level and Firewall).

Next, set up the smb service to run at boot time:

#> chkconfig smb on

In RedHat, this will also cause the nmb service to run, which is fine.

Now, start Samba:

#> service smb start

Now, create the directory you want to share.  For this example, I will make it simple:

#> mkdir /dv1

Set permissions accordingly.  In my scenario, I wanted our developers to all be able to access this directory from Windows, and they were all part of the ‘developers’ group on my RedHat server, so I set the permissions like so:

#> chown developers.developers /dv1
#> chmod 755 /dv1

In order to get Samba to share this directory, I had to add the appropriate policies for SELinux, which are mentioned in the smb.conf file.  Assuming you are running SELinux (it’s default with RedHat Enterprise 5), these can be added at the command line.

Since you created a new directory that will be shared with Samba (the ‘dv1’ directory you created earlier), a label must be set for that as well.  Using ‘dv1’ as the directory name, run this:

To set a label use the following:

#>  chcon -t samba_share_t /dv1

Now to configure the Samba configuration file.  Always make a backup of the original before editing any config file!

#> cp /etc/samba/smb.conf /etc/samba/smb.conf.orig

To edit the config file, do this:

#> nano /etc/samba/smb.conf

Under [global] settings, uncomment the necessary lines and make changes so that it looks something like this:

workgroup = YourWindowsWorkgroupName
server string = YourRedhatServerName
netbios name = YourRedhatServerName
hosts allow = 127.0.0.1 192.168.1.

Leave everything else in that section the way it is.

Note:  the 192.168.1.  address needs to be that of your local network.

Then under Standalone Server Options:

    security = user
    passdb backend = tdbsam

I commented out all Printer sharing crap since I didn’t use any of that.

Lastly, under Share Definitions:

[homes]
        comment = Home Directories
        browseable = no
        writeable = yes
;       valid users = %S
;       valid users = MYDOMAIN%S

;[printers]
;       comment = All Printers
;       path = /var/spool/samba
;       browseable = no
;       guest ok = no
;       writeable = no
;       printable = yes

[dv1]
        comment = My dog has fleas
        path = /dv1/
        valid users = user1,user2,user3
        public = no
        writeable = yes
        create mask = 0765

Obviously, swap out user1,user2,user3 with the users who will be accessing this share.  You put the username for the RedHat box you are on, not the Windows username (unless it’s the same).

Save the file and go back to the command line. Test it out by running this:

#> testparm

You shouln’t see any error reported.  If all is good, run this:

#> service smb restart

You will see smb and nmb stop and restart.  There should be no errors or “FAILED” notices.

Assuming your users already have accounts on your RedHat box, you need to add them to Samba like so:

#> smbpasswd -a username
New SMB password:
Retype new SMB password:

I set a temporary password here, then ask them to change it next time they log into the server at the command line by running this:

#> smbpasswd

It will prompt them for their old password (the temporary one you just gave them), and for the new one.

Once all that is done and you have set your own Samba password, you should be able to do this from Windows:

Go to Start and select Run.  Type in the hostname of your RedHat server (which you specified in the smb.conf file) like so:

\YourRedhatServerName

You will be prompted for a username and password, and you should enter the RedHat server login name and the Smaba password that you just created.

If all goes well, a window will appear which shows the dv1 directory.  You can now drag, drop, copy, and paste to and from this folder as if it were on your Windows machine!