On July 11th, an electrical transformer on the 13th floor of the Shaw (Large Canadian ISP) building exploded causing a fire
A number of important services were knocked offline
911 service for 30,000 Shaw Landline customers, Customers told to use Cell Phones to call 911
Repac system – Routes Ambulances to the correct Hospital, Ambulances had to route to the nearest Hospital
IBM operates from the Shaw building, and as also offline
The City of Calgary 311 system (provides access to an extensive set of government services) was offline, a regular backup number was setup
Calgary Transit’s telecommunication system was mostly unavailable
Three radio stations in the Shaw building went offline Q107, QR77 and Country 105
The Calgary Parking Authority and Calgary Fire Department also experienced problems, as well as ATB Financial online banking.
Parts of the Computer Systems for Alberta Justice and Alberta Health Services were taken offline
Alberta Health Services had to postpone non-critical surgeries scheduled for the following days because they could not access electronic health records, Calgary Lab Services was also unable to match up test results with patients due to electronic health records being unavailable
Registry services such as licenses, vehicle, and land title registrations were unavailable
High school transcripts could be processed
Peter Bissonnette, president of Shaw Communications: “It’s not yet clear why the backup system failed to take over, but he said the activation of the sprinkler system might have played a role. He said they have to be careful about bringing services back”
IBM Canada, the province’s IT contractor whose Shaw Court data centre remained blacked out for more than a day, had to fly the analogue backup tapes that stored all Alberta’s vehicle and property registration data to a backup facility in Markham, Ontario, and carefully load them on to new servers. Some systems had “mirror” backups and were restored within 48 hours, but the registries and other systems take up to 72 hours to completely restore
The government hoped to restore the local data center quickly, but when power could not be restored due to water damage, instead had to shift to the Ontario backup, data center operations will not be moved back to the Calgary Servers until later this year
ASLR (Address Space Layout Randomization) was introduced in Android 4.0 but was not fully implemented
Android 4.1 adds PIE (Position Independent Executable) support, Heap randomization and Linker randomization
These additional mitigation techniques, combined with the existing DEP (Data Execution Prevention) and hardware based NX (No eXecution), make it very impractical to exploit buffer/stack overflow and memory corruption attacks
Android has long used OpenBSD’s dlmalloc and cmalloc memory allocators for improved security
Android 4.1 also enables the upstream Linux kernels dmesg_restrict and kptr_restrict that disable unprivileged users from reading the kernel ring buffer and many sensitive parts of /proc
CERT recently approached AMD with information pertaining to what they believed to be a possible video driver vulnerability exposed by non-default settings of the Microsoft Enhanced Mitigation Experience Toolkit (EMET). EMET is a security test tool that allows system administrators to create test conditions to validate correct behavior of system components or indicate potential weak points.
The AMD Catalyst 12.6 driver for the AMD Radeon HD 7000, AMD Radeon HD 6000, and AMD Radeon HD 5000 Series is designed to resolve a possible video driver vulnerability issue and to minimize the occurrence of system crashes
AMD Blog Entry on ASLR fix – AMD explains why it took them until the end of June to fix a bug reported in February
Using a simple 3 step process, users can trick iOS applications into thinking that the user had purchased additional content
The three step process involves:
Installing a CA Certificate (so the following certificate is trusted)
Installing the Certificate of the pirate proxy, in-appstore.com
Changing the DNS servers in the WiFi settings
This is basically a purposeful ‘Man In The Middle’ attack, passing the purchase attempt through the pirate proxy rather than the real Apple app store
It seems that many iOS applications do not actually verify the receipts for purchases using the iTunes API
The developer of the bypass proxy notes that since any attempt to verify the receipt would go through the proxy, it can still be spoofed
The only way to ensure that a receipt is real, is to verify it using a server controlled by the developer of the app, and from there make the call to iTunes
This means that the proxy could still target individual apps and forge responses from those servers
What the iTunes API needs to do, is add an additional layer of security beyond TLS (SSL), by signing receipt checking responses with a private key from Apple, that can then be checked against a published public key
In the interim, Developers could implement such a system themselves, calling their own server to verify the receipt, that serve then passes the request to Apple, and then adds a signature
“The security of the App Store is incredibly important to us and the developer community,” Apple representative Natalie Harrison, told The Loop . “We take reports of fraudulent activity very seriously and we are investigating.”