Gizmodo via CNET's Crave has an interesting overview of BKIS's face recognition software exploits. As described, they modify a relatively low resolution image of a person from Facebook or another site with pictures available. A tweaking process creates an image that is highly compatible with the face recognition software, allowing a malicious third party to log in to that user's system.
As I noted in my last post, Improvised RFID Blocking Wallets: Preventing PayPass Skimming, I have recently been working with an OmniKey Cardman 5321 USB RFID reader in Windows. The reader is compatible with a broad range of RFID cards (From Omnikey's website):
# serial port (can be overridden with -l for Windows)
line= "SERIAL”
# serial port (can be overridden with -l for Windows)A simple re-compile of RFIDIOtconfig.py results in an updated RFIDIOtconfig.pyc, and you're ready to go.
line= "USB”
Many credit card users do not realize that they have PayPass enabled RFID credit cards in addition to the new RFID enabled US Passports. These RFID enabled devices are easily read at distances compatible with casual contact in a crowded environment such as a subway or an airport, and various data can be gathered from them (US passports require key data to decrypt the data stream). More and more people carry fob based RFID PayPass tokens, or have PayPass cards, making the wireless exposure of their card data far more likely.
How can we combat this? The good news is that commercial RFID blocking wallets are available, and various people have created their own versions such as the duct tape and tin foil wallet. The resourceful traveler can easily replicate their functionality on an ad-hoc basis too. We have tested with a number of common objects, such as the cookie bag and tinfoil above, which worked quite nicely for our 13.56 Mhz test tags.
As you would expect, common food packaging is a very easy to obtain improvised RFID blocking material. We have not tested 125 kHz tags, so your mileage may vary if you are attempting to block RFID tags using that frequency.
Our testing was conducted using a commercially available Omnikey Cardman 5321, a USB connected RFID reader, and using Adam Laurie's RFIDIOt package. Longer ranges are possible using custom antennas and readers, with some testing on these passive tags being done at up to 30 feet by NIST - a result that worries the ACLU.
Check your wallet - you may have a PayPass enabled card without realizing that you do. To check, simply check the back of your wallet for the PayPass logo. In addition, many cards have a chip logo on the front, making them easily identifiable.
We've discussed the anatomy of a typical PayPal scam email in the past, and we've analyzed other scams such as credit union member phishing. With that in mind, a recent PayPal scam email has a few little tweaks that are worth noticing.
The first thing to note is that it tells the recipient that the investigation process will take at least 12 hours, and that they recommend that you verify your account then. This means that most users won't try to log in for at least 12 hours, giving the scammer a chance to loot the account.
Second, it was interesting to see that the scammer did not use a very well concealed clickable Paypal URL - a simple mouseover points it to a site easily identified as a non-PayPal site. The most interesting part here for me was that the help link redirects to an alternate site as well - although, again a poorly concealed one.
Finally, the email spends almost a third of its length discussing what PayPal does to address scams and to prosecute fraud. This appears to be an attempt to tap into what Bruce Schneier discussed recently regarding the science of cons.
These incremental improvements - and the lack of sophistication in the links show that PayPal scam email continues to evolve and adapt, and that some of the most common tricks aren't universally used. As users become more savvy, successful scams must become more realistic, and must appear more trustworthy.
The email is reproduced below as a clickable image - click to expand:
If you're doing forensic work, or if you need to do data recovery, you'll likely run into deleted files that you need to match up with actual file types. This is where data carving, or file carving comes into play. Data carving involves searching an input (in this case, a dd image) for content, rather than metadata like filenames.
One of the easiest ways to do this is with an open source tool called foremost. Foremost recovers files using headers, footers, and standard data structures, allowing you to match files on a disk image. Usage is simple:
foremost -v -T -t (type) -i (file)
This enables verbose mode (-v), timestamps the output directory (-T), selects the type of files you want to search for (jpeg, gif, etc), and feeds in your dd'ed input image file (-i).
You can find previous DA posts about digital forensics here:
A recent trip to the ATM resulted in an interesting receipt as the ATM crashed. Note the debugging information providing connectivity details for the ATM. In and of itself, this wasn't a real issue, but it was interesting to see, as the ATM appeared to be working properly.
Once this three foot long error receipt printed however, we noticed something more interesting about the ATM.
That deep dark space to the left of the ATM contained networking devices, including the network uplink. Since this is a third party ATM on private property, it was not connected to the building's network.
The devices appear to include some form of serial or parallel device, an ethernet to PCMCIA bridge with an AT&T wireless cell card, and an antenna with a magnet to provide reception from the top of the ATM. Sadly, the strongest physical security control here is the sheer amount of dirt present. Nothing would prevent a malicious (or curious) person from placing a hub between the bridge device and the ATM's link to capture traffic. The cell network card could even be taken and used quite easily. Best of all, the ATM has no coverage with a camera system, and is in an area that is open at all hours of the day.
A number of very simple actions could be taken to greatly improve the security of this ATM and its operations.
I act as a stand-in instructor for an undergraduate security class a couple of times a year. Typically, I teach an hour or so about physical security, and lecture in coordination with the campus data center manager about data center security and operational security at the university. I tell a number of stories, and offer examples of how security design is done on campuses, as well as in the students' every day lives.
Each time I lecture, I ask the instructor about the feedback from the class. Typically, there is positive feedback, and often there is something interesting that the students will pick up on. The most recent class, however, had something new to say:
"Your friend is scary".
I'm used to scaring our datacenter manager - the security analyst's approach to systems is something I've talked about before. He knows that I analyze based on risk, and that while I may enumerate a wide variety of risks, that I'll work with him on the most plausible, and dangerous risks. The students, however, aren't used to assessing risk in the same manner, and don't think like analysts would.
This points out a problem: people rarely react well to things that are scary, and we don't want to be seen as paranoids. How can we avoid being the scary security analyst?
In general, we need to do three things:
