Security Resources

Archive for the Alarm and Physical Security Category

Another Reason to Keep Keys in Your Pocket!

note_encryptedWe learned this week about an unbelievably bad idea in the way of an online business called “Keys Duplicated” that will copy mechanical keys from a photograph submitted via their site. Users are reassured that this is secure because they require a photograph that includes fingers (supposedly proving ownership – or at least physical control of the key) and the fact that they ship to a street address…

The company decodes the bitting of the key from the photo and cuts a duplicate according to the appropriate manufacturer’s depth and spacing specifications. We have warned for years about the vulnerabilities of standard mechanical keys and the ease of access to code-cut duplicates – but this process seems especially friendly to those with malicious intent.

Hopefully, you are careful about where you leave your keys at the office, and you most certainly use a valet key (or remove house and office keys from the ring) when parking, right?!

Destructive Malware – The New Trend?

newsThe concerning trend of malware being used to create mayhem within an organization or across a large population of disparate devices seems to be here to stay.

Within the security industry, one must think about what the response needs to be if, for example, enterprise security systems were targeted in such a way as to bring them down for days at a time. Whether through a vulnerability in the OS, connected devices (IP cameras, etc…), or software that manages the system(s), the threat is real. It is plausible that targeting physical security systems will be especially attractive due to the potential for capturing “private” video, interacting with the physical world (door control, sounding alarms), or gaining notoriety for breaching systems that are perceived as more secure than others.

More on the topic can be found here.

Theft Deterrent Merchandising Whitepaper

phone_display

Frank Mayer and Associates has a free whitepaper available at their website that provides an overview of the design concepts, benefits, and challenges of theft deterrent merchandise displays. Since Frank Mayer manufactures such products, their perspective includes things not often considered by those who are primarily security-focused, such as the number of product facings and the ways to integrate dummy and demo product into the fixture design.

It is a good primer for anyone interesting in learning about how retailers attempt to create a positive customer experience while managing risk.

Note that a short registration form must be filled out at this link prior to downloading the whitepaper.

 

secure_display

Detex Door-Prop Alarm

Detex_Prop_Alarm

The EAX-300 from Detex is a battery-operated alarm with integrated delay timer. This allows free short-term use of a door, while monitoring for a “propped open” condition. Common applications include:

– Rear Receiving Doors
– Server Rooms and Data Closets
– Vault / Cash Offices
– Employee / Stairwell Doors

The alarm delay is adjustable between one second and four minutes, and the unit can be deactivated via key when necessary. It is important to note that once the alarm sounds, it can be silenced by simply closing the door, unlike similar alarms that require a key to reset. This will be seen as a pro or con, depending on the application.

Since the device requires no cabling, it would be simple to retrofit into existing spaces. For new construction and remodels, a cabled solution would have the advantages of being powered remotely (no batteries to change) and could be partially concealed for better aesthetics and security. It should also be noted that the trend is toward gathering and reporting such events to improve policy compliance and link them to video – which requires a more intelligent system. The Detex device is elegant in its simplicity, comes from a reputable manufacturer, and is definitely worth considering for low-security applications.

Complete specs can be viewed here.

DVR and IP Camera Hacking – Only the Beginning

There have been a number of articles and proof-of-concept hacks in recent years illustrating vulnerabilities in IP camera software, access control systems, and the like. Some have raised awareness about fundamental flaws in technology – like the relative insecurity of common proximity card readers, unprotected programming access to a locking system, and simple methods to access a camera’s video feed. Most of the attention following these announcements is focused on the ability of a device to be bypassed or viewed (in the case of a camera), which misses a critical point.

While it is concerning that a replay attack can spoof an access card, and that an IP camera may not provide adequate security against unauthorized viewing, the real danger lies in the potential of these systems to be hacked and modified to serve some other purpose. Here are a few examples – and a prediction: We will see one or more of these in the wild within 24 months.

Scenario One:  The IP Camera Worm
Many IP cameras are designed using FPGAs, not microprocessors, so their ability to run arbitrary code is limited. This trend is changing, however, and as cameras adopt a more standards-based architecture, they will become powerful edge devices running operating systems that can be attacked like any other. Some higher-end models can already run cron scripts, handle video analytics, and manage local storage of data. They are, without exaggeration, computers with a lens and network connection. They are also commonly thought of as “appliances,” with a plug-and-play approach applied to many projects. It is feasible that a worm or other malware could infect these devices as early as the point of manufacturing, or when they are plugged into the installer’s laptop for programming. The software might lie dormant or attempt to infect other cameras or computers on the same network. Affected devices could even be used to launch a Denial of Service (DoS) attack against the recording server or some other target. The common practice – at least in larger systems – of segmenting cameras onto their own LAN might help to reduce this potential, but since the recording server is usually connected to other network(s) for remote viewing and administration, malware capable of infecting the server is a logical progression of this threat.

Scenario Two:  The surveillance DVR/NVR (Network Video Recorder) as a point of entry into corporate networks
Executives like video surveillance systems – and for good reason. As networks and video quality have improved, these systems have saved organizations tremendous amounts of money. Investigations can be performed more efficiently, guards can be reduced, travel costs can be cut, and the list goes on. This means, of course, that the video systems need to be accessible to various departments via the corporate network. Most implement some type of basic security, like requiring a remote user to connect over a VPN, but few have taken steps to totally isolate the video traffic from other network systems. Since many DVRs and NVRs are full-fledged PCs running Windows or Linux, they are vulnerable to the same kinds of attacks as any other server or workstation, but they are easily overlooked and could become a “zero-day” vulnerability or convenient back door into the network.

Scenario Three:  Unintended “Integration”
Every year, security hardware and software moves closer to delivering on the promise of interoperability. It has been a long road, and there are still miles to go, but today’s systems come equipped with protocols for a variety of devices, in order to enable integration. This means that building a “security network” within an enterprise often makes sense. To gain the full benefit from your systems, they need to be able to interact, and since capabilities are sure to be added later – anything that might need to share data ends up on the same segment. When industrial controllers, manufacturing equipment, or other critical systems make this list, the scene is set for security devices to be used as a launchpad for espionage or manipulation. It can seem logical to group these systems together – after all, the “security network” should be a safe place for any important devices, right?

So, why is a hack inevitable?
Fundamental to the problem is that these systems and devices are routinely installed without sufficient thought given to security, and without a plan for ongoing monitoring and maintenance. Furthermore, some of the latest features of alarm panels, home automation controllers, IP cameras and DVRs require Internet access or remote server connections just to function properly, opening a vector of attack that, again, is not well understood or monitored. This means that segmenting a network or “sandboxing” the application may not be an option unless the owner is willing to sacrifice functionality.

I realize that it is not much of a stretch to predict that a hackable device connected to a network might be used in a new and nefarious way… but let’s hope I’m just plain wrong.

 

For More:

DVRs are being targeted by hackers, says security expert – Article discussing vulnerabilities in consumer DVRs

Bypassing IP Camera Authentication (example)

OpenIPCam site, dedicated to hacking various cameras and the development of custom firmware

Self-Monitoring FAILS in Fort Worth

Following up on an earlier article about self-monitored security equipment, I wanted to share a recent incident that brings to light an important consideration for anyone wishing to pursue such technology.

According to an article in the Star-Telegram, a businessman in Fort Worth, Texas was unable to dispatch authorities to his store for a burglary in progress that he witnessed live via a remote video system. The municipality has a “no permit, no dispatch” policy, and the permit for the business had been expired for almost a year, so the police department is standing by its decision for now.

This is an interesting case for a number of reasons:

1. The business owner, Leroy Reber, is a security equipment reseller and installer, licensed by the State of Texas, so he was likely aware of the local dispatch policy.

2. The remote video connection was manually initiated by Mr. Reber after he received a text message informing him of the alarm. It is not clear whether the text message originated from a monitoring center (central station) or from the equipment at the premise. This could be relevant, since a central station would normally dispatch the alarm immediately upon receipt (or after following verification procedures), so the PD may have already been informed and known that the alarm was triggered by a system with an expired permit.

3. There appears to be some confusion over what was said during the dispatch request. It is plausible that the refusal to dispatch was triggered by semantics. If the PD heard, for example, that “my alarm went off and there is a burglary in progress,” it seems reasonable that they might follow the no dispatch rule. If, on the other hand, they heard “I am viewing my business on a live video feed and I can see someone trying to break in,” their response might have been different. In other words, if the PD believes the dispatch is the result of an alarm system activation, they may automatically treat it differently than if some other security technology (e.g. live video from an owner’s networked camera) is involved.

So what does this mean for those who wish to self-monitor a video camera, alarm panel, or other device that might result in a call to police? Unfortunately, the answer is not clear at all. Most alarm permit statues were written with traditional monitored systems in mind: keypads, door contacts, motion detectors, and the like. Definitions are often loose, however, and it wouldn’t be surprising if some jurisdictions interpret any device that triggers a signal transmission – even if sent directly to a property owner’s cell phone – to be a monitoring system that requires a permit. This is certain to catch users off guard, since the first time they need police may be the first time they realize that a permit is required – possibly years after the equipment was installed. Current and future-generation IP cameras will increasingly be used this way, capturing events and acting as an all-in-one remote video and alarm reporting system.

I suspect that it will be some time before statues are rewritten to address self-monitoring, since it is still in the early-adopter phase. If anything, police departments are much more likely to dispatch in cases like Mr. Reber’s than to refuse, mainly due to the situation the Fort Worth PD is facing today: it is difficult to explain why “no permit, no dispatch” is a good idea to a taxpayer who witnessed their property being damaged and called for help. A police spokesman acknowledged that the department is investigating to determine exactly what was reported, and when. I will post updates as they are available…

 

War Dialing for the 21st Century

You’re probably familiar with the term “war dialing” – but just in case – it refers to the practice of scanning a large block of phone numbers, attempting to connect to a modem or other device – usually for the purpose of hacking into systems. This can be done at random, in the sense that a hacker is just looking for anything they can find, or it can be used as a targeted attack by scanning numbers likely to be associated with a particular target. In the days when almost all connections were handled with dial-up modems, war dialing was a popular sport – but you might assume that in the modern world, there wouldn’t be much left to find… unfortunately, you would be wrong.

In a recent interview broadcast by the online show Hak5, two modern variations were described in detail. The first is the one most are familiar with: scanning the Internet for vulnerable targets. One of the search sites referenced (by link to Matt Krebs’ article) in my recent post about industrial controller vulnerabilities, called Shodan, was discussed as a popular way for hackers to jump-start their work, since a user can search and sort results to look for specific types of systems. The ability to use scripting to interface with Shodan’s database was also given as an example of how a hacker can automate the process of connecting to large numbers of systems. In a creative example of how this is used, the hacker detailed how he set up a script to take a screen shot of each system’s login/connection screen. This allowed, prior to any type of actual hacking, for thousands of sites to be reviewed and sorted. Larger screen shot file sizes, for example, might be found on more interesting targets because they are serving up logos, splash screens and other graphics.

It wasn’t only the enterprise systems that piqued the hacker’s interest, however, since searching through the Shodan data also yielded a number of smaller, unsecured systems – whose operators probably never considered they would be found online. These included red-light cameras, SCADA devices, and in one case, a power plant monitoring system.

The second interview described a method of conducting modem-based war driving scans, using VOIP connections to contact landlines. Of particular concern was the report that enterprise-class routers are often found connected to telephone lines, without adequate security, to allow remote access when IP networks go down. Speculation was that the administrators simply didn’t think about securing these connections, focusing instead on the far more “obvious” network-based attacks.

Aside from the mention of security cameras being a common search on Shodan, there was little attention given to the large number of security devices connected to both networks and telephone lines. Alarm control panels, in particular, have escaped widespread hacking only because most use non-standard connection methods over PSTN and/or require special sequences to initiate a connection. As these systems move onto the Internet, they are certain to become more popular targets.

Definitely more to come…

Software Defined Radio (SDR) as a Security Threat

There have been a number of DIY projects documented recently that transform inexpensive TV tuner dongles into software defined radios (SDRs) capable of receiving a wide range of broadcasts. While this potentially allows someone access to frequencies used for security equipment/communications, our concerns are primarily limited to the interception of data – which can be addressed in a variety of ways.

Now, some projects – like this one – are taking the concept further and adding the ability to transmit. As the hardware becomes more affordable, the likelihood of misuse will rise. These systems could, for example, transmit false GPS information, replay wireless transmitter signals, or mimic a wireless host or monitoring system. Many older wireless platforms use little or no security for transmission validation, and even those that do may be susceptible to certain types of attacks – such as brute forcing and jamming. Of course, the technology to interfere with wireless transmissions is already available, but it is generally cost prohibitive and complicated to operate.

Software projects like GNU Radio promise to simplify the user interface for those exploring SDR, and we will undoubtedly see a range of purpose-built attack tools in the future that can break or compromise various wireless systems. Many of these will be useful to pen-testers, but like all such tools, their existence in the wild must be considered when selecting wireless equipment or evaluating an existing infrastructure.

Self-Monitoring as a DIY Project

While not for the electronics newbie, several recent projects detail ways that you can monitor an alarm system – or any similar device – using text messages and wireless connectivity. Here are two of the more interesting ones:

 

PhantomLink:  http://www.phantomlink.com/

Using the Electric Imp (an great project by itself!):  http://www.swblabs.com/?p=801

As off-the-shelf products allow more devices to be connected and controlled via networks, this concept will almost certainly gain popularity for low-security applications.

Hotel Lock (in)Security: Millions Vulnerable

This hack has been known for a while, but is now being packaged as a DIY project that fits inside a dry-erase marker.

Basically, the affected hotel locks (from Onity, a UTC company) have a port on the exterior side that allows access to the lock controller. Connecting to this port and running some special code allows access to lock functions, as well as master key information. According to the hackers who demonstrated this weakness, this attack does not need to break any encryption – so it is fast and trivial to execute.

Here is the device in action:

There are, reportedly, four million of these locks installed in hotels, and the time to open them once the device is connected? About 200 milliseconds – or, less time than it takes to swipe a working card in the lock…

Here are slides from the hackers presentation that describe the problem and his engineering efforts.

It is difficult to understand how a data port on the secure-side of a lock was not better scrutinized (and protected) by the engineers.  Onity has apparently designed a port cover that blocks physical access, but no software solution is known as of this writing…

UPDATE (11-27-2012)

This article describes burglaries in Houston, Texas using the exploit described above.

Page 1 of 212