Tag Archives: Sky

Sky Hub syslogging to Mac OS

Posted on by
Reply

The standard issue Sky Broadband SR102 ADSL router includes the capability to send syslog messages to a remote host.

Unfortunately the plucky little SR102 doesn’t send syslog messages in entirely the right format (checked using ‘syslog -F raw’):

[ASLMessageID 303320877] [Time 1463491448] [TimeNanoSec 0] [Level 2]
 [PID 4294967295] [UID 4294967294] [GID 4294967294] [ReadGID 80] [Host
 1] [Sender 2016-05-17T14] [Facility daemon] [Message 24:08.000Z
 skyhub.ihr syslog - - [skySDID@32666 mac="7C4CA5D9E148"
 sn="A502141D002081"]  Administrator login successful from IP:
 192.168.0.100 .]

You can however still use Mac OS’s syslog daemon to receive these messages, but first you’ll need to enable the socket listener:

cd /System/Library/LaunchDaemons
sudo /usr/libexec/PlistBuddy -c "add :Sockets:NetworkListener dict" com.apple.syslogd.plist
sudo /usr/libexec/PlistBuddy -c "add :Sockets:NetworkListener:SockServiceName string syslog" com.apple.syslogd.plist
sudo /usr/libexec/PlistBuddy -c "add :Sockets:NetworkListener:SockType string dgram" com.apple.syslogd.plist

To restart the syslog daemon:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist

Next go into the Sky Hub web interface, click on the Security tab (default admin credentials are admin / sky), select Logs and then enter the IP address of your Mac in the Syslog server address.

You can check for Sky Hub syslog entries in /var/log/system.log

To filter out the Sky Hub messages into a separate log file, add these two lines to /etc/asl.conf and then restart the syslog daemon again:

# Sky SR102 broadband router saved to skyhub.log
? [S= Message skyhub.ihr ] file skyhub.log mode=0640 format=bsd rotate=seq compress all_max=50M

The query-action rule tells syslogd to match on the “skyhub.ihr” substring in the Message key and then save those entries to /var/log/skyhub.log. The options are for log file rotation, retaining up to 50MB of files.

Typical Sky Hub log entries will include connection retraining, web interface logins and NTP synchronisations.

Apps Publishing Security Policy

Posted on by
Reply

BSkyB has become the latest high-profile victim of a security blunder which has caused them to suspend all their Sky Android applications from the Google Play app store.

The hackers would appear to have used a combination of phishing and social engineering techniques to compromise a trusted computer and steal corporate login details for third-party sites such as Google and Twitter.

The storefront for Sky’s Android mobile apps was defaced, with the app descriptions changed and screenshots replaced.

Sky Go defaced

To make a bad situation even worse for Sky, one of their official Twitter accounts was also compromised and the hackers used it to draw more attention to their handywork.

skyhelpteam

Fuelled by the ‘official’ Twitter misinformation, customers were led to believe that the apps had also been tampered with, although this has been subsequently denied by Sky on their Help Forum:

We have temporarily removed our Apps from the Google Play store following a security alert.

All Sky Apps were unaffected and any Sky Android apps previously downloaded by customers are safe to use. There is no need to remove them from your android device.

As soon as we have restored the apps on Google Play we will post up an update.

In a related security breach, Twitter has locked access to @SkyHelpTeam, which is why we are currently unable to tweet from this account. However, help and info is available via @SkyHelpTeam1, Facebook and here on the Sky Help Forum.

The tweet that was made from the @SkyHelpTeam twitter, in the early hours of Sunday morning, advising customers to unistall their apps was NOT an official tweet from Sky. Twitter security immediately detected this vogue messaging and locked account as part of agreed standard security process.

Sky have suffered this humiliation as a result of sloppy security practices. With a robust security policy the damage from this attack could have be limited or prevented entirely.

My recommendations for an apps publishing security policy:

  • Use a dedicated Google account for the Google Play Developer Console, not an account used for other Google services. Do not divulge the email address of this account.
  • Enable 2-Step Verification on your Google account and use Google Authenticator to login. Make sure that you properly sign out of your Google account when you have finished each session.
  • Only use a bookmarked https link to access the Developer Console. Never click on links contained in emails or on other web sites.
  • Tightly limit access to the Developer account. Only permit access to those directly involved with apps publishing, usually just the Apps Manager and their deputy.
  • Wherever possible use discrete private keys to sign each application – see the Signing Strategies section of Android Developer Tools. This limits the damage should the private key for an individual app be compromised.
  • Store your signing keys securely, preferably using a hardware-encrypted USB flash drive (such as an IronKey). Physically store the keys in a locked safe.
  • Use a standalone computer for code signing and never connect it to a network. Treat all networks as untrusted, even your corporate LAN.
  • Have a well rehearsed contingency plan to ensure business continuity if the worst does happen.