Kapersky and Jackie Chan: Odd Security Advertising
Gizmodo, via Animal NY points out an odd Kapersky ad with Jackie Chan on a Segway, Eugene Kapersky, and a trip through "Cyberworld" protected by Kapersky AV in the form of a crash helmet.
Gizmodo, via Animal NY points out an odd Kapersky ad with Jackie Chan on a Segway, Eugene Kapersky, and a trip through "Cyberworld" protected by Kapersky AV in the form of a crash helmet.
Posted by David at 12:30 PM 0 comments
Labels: Kapersky, security advertising
NACUBO has released the results of their National Campus Safety and Security survey. The survey had a broad group of project members, covered 342 colleges including a broad range of 2 to 4 year public and private colleges. The results say a number of interesting things about the physical security of the average college campus including the following:
Posted by David at 10:20 PM 0 comments
Labels: NACUBO, security survey
Krypted covers the basics of managing and controlling the MacOS application layer firewall from the commandline. The provide just the right details to get MacOS users up to speed, providing details on how to allow a single application, how to start and stop the service, and how to set preferences.
If you're a MacOS administrator who prefers the command prompt, or if you're trying to script your firewall management, this is a handy reference.
Posted by David at 12:30 PM 0 comments
Labels: MacOS, MacOS application layer firewall
Public webcams aren't something that most public institutions would consider a significant threat - they're typically in open spaces without sensitive data or activities in front of them. The Register's coverage of Ashton Lundeby and his fellow conspirators might make those organizations reconsider. The Register quotes the indictment, noting that "The conspirators created a 'channel' over which members of the conspiracy could broadcast their misdeeds to as many as three hundred (300) individuals simultaneously".
This moves swatting into the field of mass entertainment - the website advertising the videos was apparently set up to charge fees to view them. With caller ID spoofing and the sensitivity of public institutions to bomb threats, this may become a threat that we are all too familiar with.
For many sites, a simple search of common camera URLs will find Axis and other network cameras:
intitle:”AXIS” | inurl:view/view.shtml
A larger list of search URLs can be found here.
How would your organization handle a false bomb threat? Do you have publicly accessible web cameras? Do you know where they are? This may be yet another worthwhile Google alert search string to build.
Posted by David at 12:30 PM 0 comments
Labels: swatting
Kees Leune pointed out the utility of Google's SMS two factor authentication earlier today. Using this becomes an interesting potential vulnerability when combined with the much discussed Nokia 1100 cloning vulnerability discussed in recent months. The threat model used by criminals in Europe is described in the Ultrascan article:
Further investigations revealed that, in particular East European gangs, were buying this German Nokia 1100, were able to hack this model to insert any mobile phone number and use it for criminal purposes, especially to intercept the mobile (sms) TAN code during on-line banking fraud.This doesn't mean that you shouldn't use the two factor authentication for your password resets - an additional hurdle to attackers resetting your password is a good one. Instead, you simply need to remain aware that any service that allows resets could be attacked. The Nokia 1100 is only a first example of what will likely be an ongoing threat as we use SMS and other technologies for more of our transactions.
Posted by David at 5:30 PM 0 comments
Labels: password resets, two factor authentication
Posted by David at 8:00 AM 0 comments
Labels: social engineering
"For example, an astute consular officer in Hermosillo recently used Facebook to determine a visa applicant’s ineligibility based on information contained on the applicant’s Facebook page, proving its value as an anti-fraud tool."While many college advisers have been counseling students to avoid posting information on Facebook, and articles noting that businesses are checking out potential employees using it, this should serve as a warning to those applying for a visa, or a government job - at least some government agencies are paying attention to social media sites. Of course, if your profile isn't public, you're likely safer for now, unless the cute girl you added turns out to be a government agent.
Posted by David at 8:45 PM 0 comments
TechCrunch reports that the Twitter search product interface was accessible with username "Jack" and password "password". Their take is that this is part of a culture of lax security at Twitter. For screenshots and more detail, click through to the article.
The best part? The screenshot with Twitter's own interface noting that the password is obvious.
Posted by David at 12:30 PM 0 comments
1 US ( visa,master) = 2$/1cvv ( buy > 50 Price $1.5/1cvv)In general, prices for non-US countries were higher, as were prices for a credit card with full details on the owner, or one with a date of birth associated with it.
1 US (Amex,dis) = 3$/1cvv ( buy > 50 price $2/1cvv)
1 US with DOB = 12$/1cvv
1UK = 6$/ ( Buy > 50 price 5$/1cvv)
1UK CVV with DOB = 15$/CVV ( Buy > 50 CVV Price 12$ = 1CVV)
1 Ca CVV = 8$/CVV
1 CA CVV(Amex,dis) = 7$/cvv
1 EU CVV = 15$/CVV
1 EU CVV(Amex,dis) = 15$/cvv
1 US CVV full info = 80$/CVV
1 UK CVV full info = 100$/CVV
Posted by David at 12:00 PM 0 comments
Labels: Credit card theft, CVV2, identity theft
The Guardian describes South African ATMs designed to help combat the high incidence of ATM theft and destruction - over 500 in a single year. The article describes a variety of methods used to break into ATMs including explosives.
Pepper spray seems like a poor deterrent for thieves willing to use explosives to break into an ATM - but it may at least deter more casual criminals. Of course, the article notes that technicians have been amongst those who have suffered from the pepper spray, which they inadvertently activated. This also creates a hazard to those in the surrounding area, as pepper spray can spread and effect customers or others downwind.
In a highly hostile environment, self defending ATMs seem like an obvious step - but pepper spray may not be the best solution for others in the area. For now, law enforcement can look for the ATM using customers wearing gas masks.
Posted by David at 9:58 PM 0 comments
Labels: ATM security, physical security
Display Login Window as Name and Password FieldsThis script does a few simple, but clever things - first:
DISPLOGIN=`defaults read /Library/Preferences/com.apple.loginwindow SHOWFULLNAME` ## should return 1
if [[ "${DISPLOGIN}" != 1 ]] ; then
DISPLOGIN="List of Users"
SecStandardCompliance="false"
echo " ** SecStandardCompliance failed: Login Window displays as List of Users. Please set to \"Name and Password\" in Accounts System Preference."
arrSecurityStandardExceptions=( "${arrSecurityStandardExceptions[@]}" "1011" "${DISPLOGIN}" "Name and Password Fields" ) ## Login Window as Name and Password fields
fi
DISPLOGIN=`defaults read /Library/Preferences/com.apple.loginwindow SHOWFULLNAME`This checks the preferences - basically a true/false check for the name display. Each step in the script uses a similar check to verify one or more settings related to a configuration option required by the standard. These steps are then used to build a true/false answer to the question: is the system compliant with the setting required by the standard?
DISPLOGIN="List of Users"
SecStandardCompliance="false"
This sets a variable to a string describing the non-compliant setting, and sets the overall compliance of the system to false - any single setting can take a machine out of compliance. For some organizations, this might be a score based approach, but in our environment, we want to flag any setting that doesn't match.
echo " ** SecStandardCompliance failed: Login Window displays as List of Users. Please set to \"Name and Password\" in Accounts System Preference."The important action here is that a local user would be told what was wrong, where to find it, and what the required setting is. This means that printing out the results of this script, or simply leaving the window open will provide the local user or administrator with a checklist and instructions that most users should be able to follow.
arrSecurityStandardExceptions=( "${arrSecurityStandardExceptions[@]}" "1011" "${DISPLOGIN}" "Name and Password Fields" ) ## Login Window as Name and Password fieldsThis code segment simply flags the important issues to add to the database when the wrapper script run around the compliance check script runs.
## Use Encrypted Swap Space
if [[ "${OSVERS}" == "Leopard" || "${OSVERS}" == "SnowLeopard" ]] ; then
ENC_SWAP=`defaults read /Library/Preferences/com.apple.VirtualMemory UseEncryptedSwap`
if [[ "${ENC_SWAP}" != "1" ]] ; then
ENC_SWAP="Disabled"
SecStandardCompliance="false"
echo " ** SecStandardCompliance failed: Please enable the use of encrypted virtual memory."
arrSecurityStandardExceptions=( "${arrSecurityStandardExceptions[@]}" "1028" "${ENC_SWAP}" "Enabled" ) ## Encrypted Swap Space
fi
elif [[ "${OSVERS}" == "Tiger" ]] ; then
ENC_SWAP=`grep ENCRYPTSWAP=-YES- /etc/hostconfig 2>/dev/null`
if [[ -z "${ENC_SWAP}" ]] ; then ## if the string is blank; that is, ENCRYPTSWAP=-YES- was not found
ENC_SWAP="Disabled"
SecStandardCompliance="false"
echo " ** SecStandardCompliance failed: Please enable the use of encrypted virtual memory."
arrSecurityStandardExceptions=( "${arrSecurityStandardExceptions[@]}" "1028" "${ENC_SWAP}" "Enabled" ) ## Encrypted Swap Space
fi
fi
Posted by David at 9:30 PM 0 comments
Labels: MacOS, MacOS compliance, security scripting
Mark Steinmetz has an amazing set of pictures of objects made by German prisoners. These should serve as a reminder that ingenuity and creativity can overcome many physical security precautions - and that even the most secure environment can provide tools.
Posted by David at 10:25 PM 0 comments
Labels: physical security
A paper titled "The Career of the IT Security Officer in Higher Education" by Marilu Goodyear, Gail Salaway, Mark R. Nelson, Rodney J. Petersen, and Shannon Portillo was released on July 1st. The paper details research and results of surveys and interviews with higher education security officers, reviews of job postings, and other data. Of note, over 300 individuals responded to the survey from a total of 1685 institutions, resulting in a large sample group.
Details include the reporting lines of the security officers, their previous employment and skillsets, as well as their education and certification levels. Over 90% of the security officers have at least a bachelor's degree, with over 40% having an advanced degree. CISSPs have the greatest showing, which makes sense for a management position, but GIAC and CISM and CISA certifications also make a strong showing.
Those interested in the field will also find the salary table on page 18 of the report noteworthy, with a median range of $70-90,000 across the full range of schools, and a maximum in the $170-190,000 range.
The paper is well worth a read even if you're not in higher education - the challenges described and the training that these security officers want are the same challenges and training that are needed across the board.
Posted by David at 12:30 PM 0 comments
Labels: higher education security, security jobs
While many corporate laptops are encrypted and passworded, requiring would-be thieves to sell them as-is, to reinstall them after wiping the drive, or to part them out, personal laptops are far less frequently properly secured. In these cases, a remote control application can sometimes help with recovery of a stolen laptop even when they aren't GPS enabled devices.
One incident which I recently dealt with involved a personally owned laptop which the owner regularly accessed via a remote control application. In this case, the user apparently did not use a password for login, and conveniently, the thief or another person who ended up in possession of the laptop proceeded to use the laptop. The user was able to monitor the activity of the person using the laptop and gathered a variety of information, including personal information on the person, as well as their IP address, which they reported to the local police department.
This is where the user ran into a hurdle - the police department that was involved was not sure what to do with this information. This isn't horribly surprising - it is rare that stolen goods report information back about where they are. Fortunately, a little guidance and some cooperation with the ISP that the system was connected to got the right data into the right hands.
While there are a number of theft recovery applications on the market, this was done entirely using standard remote control software. Sadly, stolen laptop tracking applications and remote control applications are only helpful if the system is booted and allowed to contact the outside world, and technically sophisticated thieves, or those who are merely looking for a quick dollar are unlikely to put devices online.
The moral of the story? That's a tough one - first, a properly secured laptop would have likely been lost altogether, but the user's data was exposed when the laptop was stolen. Next, we face the issue of personally investigating crime. This could even prove to be dangerous if the user had been able to locate the thief's actual location. Add in the fact that the person using the laptop might not be the thief and appropriate action can be even more difficult to figure out - once stolen, a laptop is often quickly sold, and having information about an unsuspecting third party could create a difficult situation for user who takes more of a vigilante approach.
In the end, the lessons learned are twofold:
Posted by David at 9:00 PM 0 comments
Labels: laptop theft, theft recovery