Mr Sm1th

If you are running external vulnerability scans against hosts that are protected by a perimeter firewall that includes next-generation features, typically referred to as NGFW, chances are you're doing it wrong. Here's why.Typically when using an NGFW product, some form of Intrusion Prevention capability is available. Even some firewalls that aren't considered "next-gen' have basic capabilities that will automatically add external host IP addresses to a "block list" if suspicious activity is detected coming from this host. NGFW capabilities can be as simple as the detection of port scans or as complex as advanced exploit monitoring and blocking. These are great features that, in most cases, should be enabled. But when these features are applied to traffic coming from your vulnerability scanning tool the result is completely invalid vulnerability scanning results. How can that be? Well, first think about the purpose of vulnerability testing. Actually, there are a few purposes. Of course you want to understand what vulnerabilities an attacker might be able to detect and take advantage of. But, more importantly, you want to understand all of the vulnerabilities that actually exist on the target hosts that might be exposed via the ports that are made available on the target host. Running scans against a host with NGFW capabilities enabled does not accomplish the latter.

Typically, as soon as an NGFW product detects suspicious traffic from an external host, some sort of evasive action is automatically carried out by the firewall. So, when an external host seems to be running a port scan against my web server, the source address is added to a block list for a period of time. Until that time expires, any new traffic from that host will automatically be denied. Some of the NGFW products will detect specific streams of traffic that match a signature for exploit traffic and block only that traffic. In both of these cases, if these automated actions are carried by the firewall on traffic that is coming from your vulnerability scanning system then your scanning system is not able to execute all of it's tests agains the destination. And most vulnerability scanning products will just continue to try and run their tests, but will stop receiving responses from the destination host. And these scan tools aren't smart enough to inform you that the scan didn't actually complete. The scan results look pretty clean. But they are also incomplete and invalid. Sure, scanning this way confirms that the IPS features of your firewall are functioning. But that's not the most important reason to run vulnerability scans. Again, the primary reason for doing scans is to understand all of the vulnerabilities that actually exist on the target hosts that might be exposed via the ports that are made available on the target host. If you want to continue to run a set of scans to validate the effectiveness of your IPS features, that's fine. But you must run a set of scans with these IPS features disabled for traffic from your scanning solution for a vulnerability scan to actually complete and be considered valid. The only thing your firewalls should be doing for this vulnerability scan traffic is stateful firewall services. As a matter of fact, if you run PCI scans using an ASV, PCI DSS requires that IPS capabilities be disabled during PCI scans. The best way to accomplish this is to "white list" the source addresses for your vulnerability scanning solution on the firewall so that the IPS capabilities, or any other blocking capabilities other than standard stateful firewall blocking, are not applied to this vulnerability scanning traffic. While you're at it you may as well also limit the logging of this traffic. Vulnerability scanning generates lots of firewall logs that are useless.

Overview

On
February 22, 2016, while visiting a Smokey Bones restaurant, I uncovered a
vulnerability that allows anyone to obtain the name, email address, and
date of birth of any Bones Club rewards program member. You can even change a
Bones Club members phone number on record with Smokey Bones. And all you need
is their phone number.

Details

Anyone
can walk into one of the 65+ Smokey Bones restaurants, sit at a table or at the
bar, and use any one of the table-top Ziosk units to check
their Bones Club points.

One of
the methods to lookup your rewards account is to enter your phone number. Once
you do this, you are provide with the following nifty screen.

Great,
you get to see how many points you have. And some other information is also
shown. This includes your first and last name, email address, an additional
phone number, and your date of birth.

The
problem? You can enter anyones phone number. If they are a Bones Club member,
you are presented with all of their info. Yes, all you need is a phone number.
I pulled out my phone and looked up some random people who I thought might go to
this restaurant. I got a hit on the first try. You can sit at the table in the
restaurant and literally keep entering phone numbers until you find
something interesting.

Phone
numbers are not private and should never be used as a method of authentication.
Especially when that's all that is needed to get access to other sensitive
information about someone like their email address, other phone numbers, and
their DOB (which is personally identifiable information). Oh, and a
bonus here is that once you are on this screen you can change the Bones Club
members listed phone number. That way you can prevent them from getting to
their own rewards account and you might be able to do something more
interesting.

Status

I
notified Smokey Bones and have exchanged emails with (and spoken multiple times
with) their Director of Marketing. I have been informed that a fix for this was
rolled out on March 15.

Note
that it was somewhat difficult to contact anyone who could help me or
understand what I was talking about. These attempts included sending them a
note on the issue right from the Ziosk unit at the store, calling them by
phone, leaving a message on their web site, calling them again. I did get in
touch with someone late on February 24.

It's unclear how long this "feature" has been in place and for how long this exposure has existed. As a Bones Club member myself, I am glad that I provided an incorrect DOB and not my direct mobile phone number, as I usually do in situations where it's not absolutely required. But most people do provide this information when asked for it. And I'm sure they never expected it to be made available to anyone who knows their phone number.

This event was obviously contrary to the Smokey
Bones Terms and Conditions and Privacy Policy, which states:

"Smokey Bones will not disclose the information that you
provide in connection with your membership in the Bones Club to
anyone else, but may use your information and other members’ information
internally and externally as part of its marketing research."

The derailment of Northeast Regional Train 188 was a terrible tragedy that we are responding to with every resource we have available. The National Transportation Safety Board is leading the investigation to determine the cause of the incident, and Amtrak is providing full cooperation.

With truly heavy hearts, we mourn those who died. Their loss leaves holes in the lives of their families and communities. On behalf of the entire Amtrak family, I offer our sincere sympathies and prayers for them and their loved ones. Amtrak takes full responsibility and deeply apologizes for our role in this tragic event.

We recognize that for everyone onboard the train, including those who suffered injuries, the healing process may be long. Within 24 hours of the incident, Amtrak set up a Family Assistance Center in Philadelphia to work closely with the family of passengers and crew on the train. We are also working with the individuals and families affected by this event to help them with transportation, lodging, and of course, medical bills and funeral expenses.

Amtrak is ever grateful to the City of Philadelphia—its first responders who bravely worked in difficult conditions, including the dark of night, to rescue and provide aid to hundreds; its hospital personnel who went into full alert as patients arrived at emergency rooms; its officials who quickly implemented a response plan; and its citizens who opened their doors to offer assistance.

Although our current focus is on the passengers and employees affected by this incident and the resulting service disruption along the Northeast Corridor, we must also take time to learn from this event. Passenger railroading is at its core about people; the safety of our passengers and employees was, is and always will be our number one priority. Our goal is to fully understand what happened and how we can prevent a similar tragedy from occurring in the future. We will also continue to focus on completing Positive Train Control implementation in the Northeast Corridor by December of 2015.

Thank you for your support of America's Railroad during this difficult time.

So you took your picture at that cool looking kiosk at the Marriott Marquis in San Francisco while out at the RSA Conference. You know, the one setup there by Pacific Digital Signs? Cool. Then you get the email that includes a link to www.isnap.com so you can get your picture. Nice!

When you view your picture it looks pretty good. Check out mine.

This page also informs you of the following:

Well, thats not exactly true. Here is the URL to my picture:

http://www.isnap.com/desktop/picture.php?id=1362658

Yes, it's as silly as you think it is. Change up the "id=" value and you will see everyone else before and after me that took their picture on this kiosk. Neato!

http://www.isnap.com/desktop/picture.php?id=[######]

As a matter of fact, if you play around a bit you will see that you can access pictures of people taken at other places like the Luxor in Las Vegas and even a few Cruise Lines! Back .... like.... years ago.

For Pacific Digital and Isnap, I suggest you fix this. And no, this is not hacking. This is a poorly designed service that is far from "private" or "not publicly viewable."

There are some quirks when it comes to integration between the Windows and Mac version of Outlook. For example, the normal “request access to calendar” process in the Windows version doesn’t work when you want to view a Mac users calendar. I figured out an easy fix though. If you can’t see the calendar of an Outlook Mac user in your environment then follow these instructions.

A Mac users name won’t appear by default in your list of calendars you can open. You must open the Mac users calendar first using the “open calendar” button in the ribbon at the top of the screen. The icon is a calendar with a green plus sign. Then choose "open calendar using address book” and then look up the person and select them from the list. Then near the bottom of this screen click on Calendar. Now that persons name will appear in your list of available calendars and you should be able to see the persons calendar information.