Wednesday, 7 October 2015

Don’t throw away your old Boarding Pass, it may contain personal information

 Did you have habit of throwing your boarding pass?read it

After finishing your trip, the boarding pass becomes useless, but does that mean that you should throw it in the garbage? Certainly not.
Have you ever thought about what information is contained inside a barcode? No ?
The popular investigator Brian Krebs has published an interesting post on the topic explaining that a Boarding Pass Barcode contains a lot of data.
Airlines use the boarding pass barcode for every single boarding pass, but what happen if someone tries to read the information it contains?
Krebs reported the attempt made by one of its readers, named Cory, who saw a friend posting his boarding pass on Facebook so decided to analyze it.
boarding pass barcode 2
“I found a website that could decode the data and instantly had lots of info about his trip,” said Cory,  “Besides his name, frequent flyer number and other [personally identifiable information], I was able to get his record locator (a.k.a. “record key” for the Lufthansa flight he was taking that day,” “I then proceeded to Lufthansa’s website and using his last name (which was encoded in the barcode) and the record locator was able to get access to his entire account. Not only could I see this one flight, but I could see ANY future flights that were booked to his frequent flyer number from the Star Alliance.”
It’s frightening what someone could do with this information, I used the barcode reader website myself to read an old boarding pass barcode, and the information I could get.
The boarding pass barcodes are widely available for years, the International Air Transport Association (IATA) published a details document  on how the barcode standards have been implemented by the organizations on the industry.
Coming back to Cory’s story, he was able to use the info available in the barcode to enter in Lufthansa website site and access his friend’s phone number, the name of the person who did the booking, and see future flights connected to the frequent flyer account.
What do you think about the possibility to conduct a targeted attack with this data? For example an attacker can send a spear phishing email to the victim reporting information on his flights.
The situation goes worse if we consider that accessing the list of future flights he is able to cancel them or change seats.
An attacker could also reset the PIN number associated with Star Alliance frequent flyer account, in the case of Cory, he tried to use the “Forgot Pin” reset and his friend question was, “What is your Mother’s maiden name?” An information like this, it’s not that difficult to extract and probably can be found in social media.
This is just an example of what can be done with a barcode, and the amount of information it can be extracted. Often people consider that the information revealed is harmless, but its because they don’t think like an criminal.
“Interested in learning what’s in your boarding pass barcode? Take a picture of the barcode with your phone, and upload it to this siteThis blog on the same topic from several years back includes some helpful hints on how to decode the various information fields that get dumped by the barcode reader.” States Brian Krebs.
My advice to our dear reader are:
  • Do not leave your old boarding pass in the airplane
  • Avoid putting the boarding pass in the garbage in one piece
  • Don’t publish the boarding pass in social media

What’s contained in a boarding pass barcode?

Anyone who has flown within the past few years would have seen the now ubiquitous barcode on the boarding pass that’s scanned upon boarding the aircraft.
Over the years I have seen many people post images of these boarding passes online, often while reviewing new technologies such as mobile or web check-in. In most cases any personally identifiable plain-text information has been obfuscated yet the barcode has been left intact.
Eventually curiosity got the better of me and I decided to find out more information on the barcode standard, and the information contained within them.

History of the barcode

In 2005 the IATA (International Air Transport Association) commenced a five year project to deploy Bar Coded Boarding Passes (BCBP) across its member airlines to eliminate magnetic boarding passes. This change would allow airlines to use cheaper boarding pass stock, and even enable technologies such as web and mobile check-in – an advancement estimated to save the industry US$1.5bn annually.

What information do they contain?

When writing this article I sat out collecting various boarding pass barcodes both from my own archived web check-in and other boarding passes found on the Internet.
Using freely available software utilities, I decoded the barcodes and had a look to see what’s there. Here’s an example from a Qantas flight of mine taken last month (decoded from the barcode on the web check-in document):
That information translates to:
  • M1: Format code ‘M’ and 1 leg on the boarding pass.
  • EWING/SHAUN MR: My name.
  • 1A11A1: My booking reference.
  • BNESYDQF: Flying from BNE (Brisbane) to SYD (Sydney) on QF (Qantas).
  • 551: Flight number 551.
  • 107: The Julian date. In this case 107 is April 17.
  • Y: Cabin – Economy in this case. Others including F (First) and J (Business).
  • 26J: My seat.
  • 37: My sequence number. In this case I was the 37th person to check-in.
  • 00: Field size of airline specific data message. 00 as there isn’t any.
In this instance, Qantas are using the minimum data fields as required by the IATA BCBP standard, but what about other boarding pass types?
The next step was to try a real boarding pass issued at the airport.
There’s more information in this boarding pass barcode, which is as follows:
  • M1: Format code ‘M’ and 1 leg on the boarding pass.
  • EWING/SHAUN: My name.
  • E1AAAAA: Electronic ticket indicator and my booking reference.
  • SYDBNEQF: Flying from SYD (Sydney) to BNE (Brisbane) on QF (Qantas).
  • 0524: Flight number 524.
  • 106: The Julian date. In this case 106 is April 16.
  • Y: Cabin – Economy in this case. Others including F (First) and J (Business).
  • 23A: My seat.
  • 0073: My sequence number. In this case I was the 73rd person to check-in.
  • 3: My “passenger status”.
  • 59: There is a various size field. This is the size
  • >: Beginning of the version number
  • 2: The version number.
  • 18: Field size of another variable field.
  • 0: My check-in source.
  • B: Airline designator of boarding pass issuer.
  • 2: Another variable size field.
  • 9: Airline code.
  • 0: International document verification. ’0′ as I presume is not applicable.
  • QF: The airline my frequent flyer account is with.
  • 1245678: My frequent flyer number.
  • 128: Airline specific data.
After this I checked an iPhone boarding pass. This contains the same information as on an airport issued boarding pass.

What could you do?

Most of the information contained within the boarding pass is fairly mundane, and the main point to this exercise is – if you’re going to post an image of your boarding pass online and obfuscate your name – also obfuscate the barcode.
The booking reference is however contained within the barcode and someone could use that to manipulate your booking (if you have more flights to go).

Who is Eddy Chiu?

Qantas have an example web boarding pass on their web site for “FYSH/WILLIAM MR” – a name frequently seen on the sample Qantas cards and other literature.
Intriguingly the barcode on this boarding pass doesn’t match up with the details, and instead shows:
While Mr Chiu is on the same flight as on the boarding pass, he is not sitting in the same seat as Mr Fysh yet shares the same sequence number.
I suspect an easter egg or “calling card” from a developer.

Source : securityaffairs,


Tuesday, 6 October 2015

Headphone checklist : Tech 101

Source : Tech101 ndtv gadgets

Buying headphones can be daunting. Here are some of the commonly used terms you should know.
Whether it's the cheap plastic pair that comes bundled with your smartphone or the big expensive cans with a giant 'b' on the side, we've all used headphones at some point of time. Getting the sound right can make all the difference between a boring bus ride and an emotional journey. But there's more to headphones than what you see.There's a lot of science and engineering that goes into making a pair of headphones sound a particular way. The sound can be tuned in an infinite number of ways, and enjoying the audio experience is more about matching a pair of headphones to the music you're used to listening to, rather than simply picking by brand or looks.
Our guide will help you get a better understanding of what to look for in headphones, and how to make an informed choice when you're actually shopping for a pair. In case you're confused by any of the terms used, jump down to check out our jargon buster. And in the following weeks, we will even help you pick a pair depending upon how much you are looking to spend.
headphones101_main_cc0.jpgTypes of headphones
Also known as IEMs (In-Ear Monitors), in-ear headphones are the smallest and most portable of all the different kinds. Each earbud fits into your ear canal and is powered by small drivers (see below), usually 8-10mm in size. It can be quickly and easily wrapped and stored, which makes it ideal for use when commuting and traveling.
Pros: Thanks to the small size and light weight, these in-ears are usually comfortable to wear for hours on end.
Cons: Many users do not like the invasive nature of the fit and prefer to use larger on-ear or over-ear headphones.
Also known as supra-aural headphones, on-ears literally sit on your ears, and are therefore much bigger than in-ears. This style of headphones uses larger driver casings, along with a headband that keeps the ear cups in place securely on your ears. Typically, on-ears headsets use 30-40mm drivers.
vmoda_xs_folded_headphones101_ndtv.jpgPros: Typically more comfortable than in-ears for short periods use, can usually be folded up to pack away when not in use.
Cons: Not as portable as in-ears. Since the ear cups sit atop your ears, may not be too comfortable over long hours of use.
Also known as around-ears and circum-aural headphones, over-ears are the largest and often the most comfortable kind of headphones. Like on-ears, over-ears have large driver casings and a headband, but the ear cups wrap completely around your ears, rather than resting on them. Because of the large size of the casing, the drivers can be much larger at 45mm and above, which allows for a louder and more detailed sound signature.
audio-technica_ath-m50x_headphones101_ndtv.jpgPros: Usually louder and having a more detailed sound signature. It's also the most comfortable kind of headphones, and even offers passive sound-isolation by completely enveloping your ears.
Cons: Usually the least portable, over-ears are more suited for home or office use.
Specialised Headphones
Noise Cancelling
These headphones work on active noise cancelling technology, where certain sounds are drowned out to offer peace and quiet to the listener. Active noise cancelling headphones use small microphones that pick up on outside noise, and produce noise in the opposite frequency, to cancel out the outside sound. The technology does not work with sounds that vary too much, as the microphone cannot quickly pick up and adjust to different frequencies. Instead, noise cancelling headphones are useful in drowning out regular droning sounds, such as airplane engines, factory machinery, air-conditioner hum and other such uniform frequency sounds.
bose_qc25_headphones101.jpgPros: Good for some peace and quiet in factories, airplanes and noisy environments.
Cons: Noise cancelling requires additional power, so charging/batteries will be needed. Additionally, noise-cancelling technology only works with certain kinds of sounds and cannot block out all sound entirely.
Gaming headphones are designed to be used when playing video games computers, consoles or portable devices, to enhance the in-game audio experience. Some, such as the Steelseries Siberia Elite Prism, are designed to provide a virtual surround sound experience, while others like the Razer Tiamat provide a true 7.1 channel surround experience. This helps gamers identify the direction of the audio. For example, in first person shooters, a good headset will let you identify which direction the enemy is firing at you from. These headphones are usually tuned to enhance dialogue and sound effects, and also have powerful microphones for multiplayer voice chat.
steelseries_siberia_elite_prism_headphones101_ndtv.jpgPros: Gaming headphones provide for an excellent surround sound effect, and are tuned for picking up direction and detail in the sound.
Cons: Usually not good enough to listen to music, gaming headphones are too specific with regards to their usability.
These headphones are free of cords and cables, and can be used comfortably without worrying about cable length and tangling. Wireless headphones usually work on one of three major transmission technologies: radio frequency, infrared and Bluetooth. The first two require a dedicated base unit which connects to the source device and transmits the frequency to the headphones, while the third uses the popular Bluetooth technology and can be paired wirelessly with a wide range of smartphones, tablets and computers. RF headphones usually work over larger distances, while infrared headphones rely on line-of-sight, and Bluetooth has a 30m range limit in most cases.
jabra_sport_pulse_headphones101_ndtv.jpgPros: Better portability and more suitable for outdoor use. Also useful for home use when the source device is placed at a large distance, such as when watching TV or listening to music in the living room.
Cons: Sound quality is usually not as good as wired headphones. Range issues and battery life can also create problems in the sound and listening experience.
These are the main types of headphones you'll be looking at in the market, but if you're confused by some of the jargon you come across in the shops, don't worry. There are a few basic terms you should know about, and you can probably ignore the rest. You'll find most of these mentioned on e-commerce websites, or on the box of the set you're buying.
Headphone Jargon
The core components of any headphones, the drivers are used to convert the electrical signal fed to the headphones into an audible sound signal that can be perceived by the human ear. There are various types of drivers used in headphones, including the most commonly used moving coil (dynamic) drivers, balanced armature drivers, planar magnetic drivers and electrostatic drivers, among others. They use different technologies to power the sound, with some technologies offering better, more powerful sound than others. Dynamic drivers are used in all kinds of headphones, balanced armature drivers are general used in in-ear headphones due to the small size, while planar magnetic and electrostatic drivers are the largest and are usually used in built-for-home over-ear headphones.
audeze_lcd_lcd3plugs_headphones101_ndtv.jpgSome headphones, known as hybrids, use a combination of two drivers (most commonly a combination of dynamic and balanced armature drivers). Generally speaking, bigger drivers don't necessarily mean better as there are other factors as well, but they are a contributing factor, particularly for bass. However, it's best to audition headphones before buying, or read reviews to make sure the product is suited to you. Typically, earphones like the ones bundled with your phone will be around 15mm, while over-ear sets will be around 30-50mm.
Closed- and open-back
Headphones can be either closed or open at the back of the driver enclosure. Since a driver fires both into and away from your ear, an open-back headset will allow the sound to escape outside, while a closed-back headset will block the exit of the outward sound. There are pros and cons to both.
Closed-back headphones prevent others from listening to what you're listening to and are therefore more suited for public places as opposed to open-back headphones which leak sound and are perceived as inconsiderate to use in public. However, open-back headphones (like the ones pictured below) have a much more open sound, giving a more comfortable and realistic listening experience, while closed-back headphones sound more 'in-your-head'. Suitability depends on the purpose for which you need the headphones, and auditioning or reading reviews is recommended.
audeze_lcd_both_headphones101_ndtv.jpgFrequency response
The frequency response range of headphones denotes the full range of sonic frequencies that a pair of headphones can achieve. The human ear can only hear frequencies ranging from 20-20,000Hz, so most headphones try to stick to this range. However, some headphones extend the range at both ends in order provide deeper responses. Although these can't be heard, they can be felt to a small extent along with the audible range, and a wider range often allows for better tone, responses and handling in the midrange, lows and highs. Check the frequency range on the box for an indication of how those particular cans will handle frequencies.
Soundstaging and imaging
These terms represent the ability of headphones to create an accurate sonic stage and image within your mind. Good soundstaging and imaging will create the impression of a live performance, where individual elements of the sound are distinct and feel like they are originating from specific locations on the virtual stage. Separation of sonic elements is also a function of imaging, where better separation represents a more realistic, true-to-life sound. This is best judged by listening and keeping your ears open for separation and clarity, so you won't find it on the specifications of the headphones, but you'll often see it mentioned in reviews.
In simple terms, headphone impedance represents the amount of power needed to drive a pair of headphones. Low-impedance headphones require less power to drive, and can therefore easily be used with source devices with weaker amplification, such as smartphones, media players, and other portable devices. They are also more susceptible to blowouts, if too much amplification is delivered to them.
High-impedance headphones require dedicated amplifiers or increased amplification to drive, and deliver a more powerful, driven performance as a result. They are less susceptible to blow-outs, as they are designed to handle more amplification. When choosing headphones, it's important to note the impedance and buy according to the source device you intend to use. Look out for the impedance figure on the box, and choose as per your source devices. Impedance of 15Ohms and under is low and easy to drive, while impedance 50Ohms and above may require some amplification for best results. However, most smartphones and media players are designed to be able to drive headphones with impedance as high as 80Ohms, so higher-side impedance may not be a serious issue.
headphones101_main4_cc0.jpgThese are the main "specifications" that manufacturers tout, and all of them have a different impact on the audio you're listening to, as we explain above. When you're buying a headset, apart from the design types, these specifications are some of the important things you should know about.
What are the features that you normally look for in your headsets? Is there any jargon you've come across that doesn't make sense? Let us know via the comments.

Friday, 17 July 2015

Javascript Cryptography Beginners guide

Hi All ,

The following would resolve the list of clarification with respective to javascript cryptography :


We mean attempts to implement security features in browsers using cryptographic algoritms implemented in whole or in part in Javascript.
You may now be asking yourself, "What about Node.js? What about non-browser Javascript?". Non-browser Javascript cryptography is perilous, but not doomed. For the rest of this document, we're referring to browser Javascript when we discuss Javascript cryptography.


The web hosts most of the world's new crypto functionality. A significant portion of that crypto has been implemented in Javascript, and is thus doomed. This is an issue worth discussing.


You have a web application. People log in to it with usernames and passwords. You'd rather they didn't send their passwords in the clear, where attackers can capture them. You could use SSL/TLS to solve this problem, but that's expensive and complicated. So instead, you create a challenge-response protocol, where the application sends Javascript to user browsers that gets them to sendHMAC-SHA1(password, nonce) to prove they know a password without ever transmitting the password.
Or, you have a different application, where users edit private notes stored on a server. You'd like to offer your users the feature of knowing that their notes can't be read by the server. So you generate an AES key for each note, send it to the user's browser to store locally, forget the key, and let the user wrap and unwrap their data.


They will both fail to secure users.


For several reasons, including the following:
  • Secure delivery of Javascript to browsers is a chicken-egg problem.
  • Browser Javascript is hostile to cryptography.
  • The "view-source" transparency of Javascript is illusory.
  • Until those problems are fixed, Javascript isn't a serious crypto research environment, and suffers for it.


If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code. The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.


There are three misconceptions embedded in that common objection, all of them grave.
First, although the "hijack the crypto code to steal secrets" attack sounds complicated, it is in fact simple. Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request. Intercepting requests does not require advanced computer science. Once an attacker controls the web requests, the work needed to fatally wound crypto code is trivial: the attacker need only inject another <SCRIPT> tag to steal secrets before they're encrypted.
Second, the difficulty of an attack is irrelevant. What's relevant is how tractable the attack is. Cryptography deals in problems that intractable even stipulating an attacker with as many advanced computers as there are atoms composing the planet we live on. On that scale, the difficulty of defeating a cryptosystem delivered over an insecure channel is indistinguishable from "so trivial as to be automatic". Further perspective: we live and work in an uncertain world in which any piece of software we rely on could be found vulnerable to new flaws at any time. But all those flaws require new R&D effort to discover. Relative to the difficulty of those attacks, against which the industry deploys hundreds of millions of dollars every year, the difficulties of breaking Javascript crypto remain imperceptibly different than "trivial".
Finally, the security value of a crypto measure that fails can easily fall below zero. The most obvious way that can happen is for impressive-sounding crypto terminology to convey a false sense of security. But there are worse ways; for instance, flaws in login crypto can allow attackers to log in without ever knowing a user's password, or can disclose one user's documents to another user.


You can. It's harder than it sounds, but you safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography. Meanwhile, the Javascript crypto code is still imperiled by other browser problems.


You can't simply send a single Javascript file over SSL/TLS. You have to send all the page contentover SSL/TLS. Otherwise, attackers will hijack the crypto code using the least-secure connection that builds the page.


In a dispriting variety of ways, among them:
  • The prevalence of content-controlled code.
  • The malleability of the Javascript runtime.
  • The lack of systems programming primitives needed to implement crypto.
  • The crushing weight of the installed base of users.
Each of these issues creates security gaps that are fatal to secure crypto. Attackers will exploit them to defeat systems that should otherwise be secure. There may be no way to address them without fixing browsers.


We mean that pages are built from multiple requests, some of them conveying Javascript directly, and some of them influencing Javascript using DOM tag attributes (such as "onmouseover").


This won't work.
Content-controlled code means you can't reason about the security of a piece of Javascript without considering every other piece of content that built the page that hosted it. A crypto routine that is completely sound by itself can be utterly insecure hosted on a page with a single, invisible DOM attribute that backdoors routines that the crypto depends on.
This isn't an abstract problem. It's an instance of "Javascript injection", better known to web developers as "cross-site scripting". Virtually every popular web application ever deployed has fallen victim to this problem, and few researchers would take the other side of a bet that most will again in the future.
Worse still, browsers cache both content and Javascript aggressively; caching is vital to web performance. Javascript crypto can't control the caching behavior of the whole browser with specificity, and for most applications it's infeasible to entirely disable caching. This means that unless you can create a "clean-room" environment for your crypto code to run in, pulling in no resource tainted by any other site resource (from layout to UX) , you can't even know what version of the content you're looking at.


We mean you can change the way the environment works at runtime. And it's not bad; it's a fantastic property of a programming environment, particularly one used "in the small" like Javascript often is. But it's a real problem for crypto.
The problem with running crypto code in Javascript is that practically any function that the crypto depends on could be overridden silently by any piece of content used to build the hosting page. Crypto security could be undone early in the process (by generating bogus random numbers, or by tampering with constants and parameters used by algorithms), or later (by spiriting key material back to an attacker), or --- in the most likely scenario --- by bypassing the crypto entirely.
There is no reliable way for any piece of Javascript code to verify its execution environment. Javascript crypto code can't ask, "am I really dealing with a random number generator, or with some facsimile of one provided by an attacker?" And it certainly can't assert "nobody is allowed to do anything with this crypto secret except in ways that I, the author, approve of". These are two properties that often are provided in other environments that use crypto, and they're impossible in Javascript.


You could. It's harder than it sounds, because you'd have to verify the entire runtime, including anything the DOM could contribute to it, but it is theoretically possible. But why would you ever do that? If you can write a runtime verifier extension, you can also do your crypto in the extension, and it'll be far safer and better.
"But", you're about to say, "I want my crypto to be flexible! I only want the bare minimum functionality in the extension!" This is a bad thing to want, because ninety-nine and five-more-nines percent of the crypto needed by web applications would be entirely served by a simple, well-specified cryptosystem: PGP.
The PGP cryptosystem is approaching two decades of continuous study. Just as all programs evolve towards a point where they can read email, and all languages contain a poorly-specified and buggy implementation of Lisp, most crypto code is at heart an inferior version of PGP. PGP sounds complicated, but there is no reason a browser-engine implementation would need to be (for instance, the web doesn't need all the keyring management, the "web of trust", or the key servers). At the same time, much of what makes PGP seem unwieldy is actually defending against specific, dangerous attacks.


Definitely not. It'd be nice if your browser could generate, store, and use its own PGP keys though.


Here's a starting point: a secure random number generator.


Virtually all cryptography depends on secure random number generators (crypto people call them CSPRNGs). In most schemes, the crypto keys themselves come from a CSPRNG. If your PRNG isn't CS, your scheme is no longer cryptographically secure; it is only as secure as the random number generator.


It's actually hard to say, because in real cryptosystems, bad RNGs are a "hair on fire" problem solved by providing a real RNG. Some RNG schemes are pencil-and-paper solveable; others are "crackable", like an old DES crypt(3) password. It depends on the degree of badness you're willing to accept. But: no SSL system would accept any degree of RNG badness.


How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL.


“Javascript Cryptography. It's so bad, you’ll consider making async HTTPS requests to RANDOM.ORG simply to fetch random numbers."
Imagine a system that involved your browser encrypting something, but filing away a copy of the plaintext and the key material with an unrelated third party on the Internet just for safekeeping. That's what this solution amounts to. You can't outsource random number generation in a cryptosystem; doing so outsources the security of the system.


Two big ones are secure erase (Javascript is usually garbage collected, so secrets are lurking in memory potentially long after they're needed) and functions with known timing characteristics. Real crypto libraries are carefully studied and vetted to eliminate data-dependant code paths --- ensuring that one similarly-sized bucket of bits takes as long to process as any other --- because without that vetting, attackers can extract crypto keys from timing.


That's true. But what's your point? We're not saying Javascript is a bad language. We're saying it doesn't work for crypto inside a browser.


Some of them are; crypto is perilous.
But many of them aren't, because they can deploy countermeasures that Javascript can't. For instance, a web app developer can hook up a real CSPRNG from the operating system with an extension library, or call out to constant-time compare functions.
If Python was the standard browser content programming language, browser Python crypto would also be doomed.


A secure keystore.


A way to generate and store private keys that doesn't depend on an external trust anchor.


It means, there's no way to store a key securely in Javascript that couldn't be expressed with the same fundamental degree of security by storing the key on someone else's server.


That scheme is, at best, only as secure as the server that fed you the code you used to secure the key. You might as well just store the key on that server and ask for it later. For that matter, store your documents there, and keep the moving parts out of the browser.


Check back in 10 years when the majority of people aren't running browsers from 2008.


Compare downsides: using Arial as your typeface when you really wanted FF Meta, or coughing up a private key for a crypto operation.
We're not being entirely glib. Web standards advocates care about graceful degradation, the idea that a page should at least be legible even if the browser doesn't understand some advanced tag or CSS declaration.
"Graceful degradation" in cryptography would imply that the server could reliably identify which clients it could safely communicate with, and fall back to some acceptable substitute in cases where it couldn't. The former problem is unsolved even in the academic literature. The latter recalls the chicken-egg problem of web crypto: if you have an acceptable lowest-common-denominator solution, use that instead.




We meant that you can't just look at a Javascript file and know that it's secure, even in the vanishingly unlikely event that you were a skilled cryptographer, because of all the reasons we just cited.


Nobody installs hundreds of applications every day. Nobody re-installs each application every time they run it. But that's what people are doing, without even realizing it, with web apps.
This is a big deal: it means attackers have many hundreds of opportunities to break web app crypto, where they might only have one or two opportunities to break a native application.


An attacker can exploit a flaw in a web app across tens or hundreds of thousands of users at one stroke. They can't get a hundred thousand credit card numbers on the street.


Nobody would accept any of the problems we're dredging up here in a real cryptosystem. If SSL/TLS or PGP had just a few of these problems, it would be front-page news in the trade press.


It isn't.


AES is to "secure cryptosystems" what uranium oxide pellets are to "a working nuclear reactor". Ever read the story of the radioactive boy scout? He bought an old clock with painted with radium and found a vial of radium paint inside. Using that and a strip of beryllium swiped from his high school chemistry lab, he built a radium gun that irradiated pitchblende. He was on his way to building a "working breeder reactor" before moon-suited EPA officials shut him down and turned his neighborhood into a Superfund site.
The risks in building cryptography directly out of AES and SHA routines are comparable. It is capital-H Hard to construct safe cryptosystems out of raw algorithms, which is why you generally want to use high-level constructs like PGP instead of low-level ones.


SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document.
SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young.
The authors of SJCL themselves say, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser.


People don't take Javascript crypto seriously because they can't get past things like "there's no secure way to key a cryptosystem" and "there's no reliably safe way to deliver the crypto code itself" and "there's practically no value to doing crypto in Javascript once you add SSL to the mix, which you have to do to deliver the code".


DETROIT --- A man who became the subject of a book called "The Radioactive Boy Scout" after trying to build a nuclear reactor in a shed as a teenager has been charged with stealing 16 smoke detectors. Police say it was a possible effort to experiment with radioactive materials.
The world works the way it works, not the way we want it to work. It's one thing to point at the flaws that make it hard to do cryptography in Javascript and propose ways to solve them; it's quite a different thing to simply wish them away, which is exactly what you do when you deploy cryptography to end-users using their browser's Javascript runtime.

Wednesday, 8 July 2015

Fixing a fake USB Flash Disk tutorial

HI All

In this post let me share how to fix a fake usb flash disk/memory card/usb drive :

To deal with the above problem the solution can be breifed as follows :
Step 1 : Identify The Real Size Of Your flash disk :
first thing you need to identify it’s speed class, it is to verify if you can write files to the advertised capacity for your flash memory card.
In order to test it you could use H2testw 1.4
Step 2 : Identifying Software To Repair Your The Real Size Of Your flash disk
You could try on chipgenius which claims that it repairs and inspects if the usb flash controller chip has the wrong VID PID information
Step 3 : Repairing Your Fake Flash disk
If the flash disk was real and not fake You could try on the following to repair the stuff :
Operating System Disk :
It involves removing the existing hard disk from a computer or laptop, booting from the operating system disk, then reformatting the memory card. It appears to be very successful. You can’t use an OEM disk provided with your computer or laptop, it must be a full Windows operating system CD or DVD.
Primary Partitioning For The Reported Flash disk :
The alternative option is to use the information provided by H2testw to build a fence. That is, create a primary partition on the flash disk slightly less then the real capacity reported by H2testw . The balance of the capacity the windows operating system sees as unallocated. You must always remember never to touch or format the additional unallocated capacity, because it is the capacity that is fake, it does not really exist! If people own Acronis Disk Director software, they will use it instead.
Other options to check were you could use testdrive from instructables
Sample test picture
Hope it helps

Monday, 6 July 2015

Security Testing Report Template

Hi All

While browsing internet i came across useful links for preparing security test report

Pen-Test Web Application Report :

Report Template
  • Introduction
    • Date carried out
    • Testing Team details
      • Name
      • Contact Nos.
      • Relevant Experience if required.
    • Network Details
      • Peer to Peer, Client-Server, Domain Model, Active Directory, integrated
      • Number of Servers and workstations
      • Operating System Details
      • Major Software Applications
      • Hardware configuration and setup
      • Interconnectivity and by what means i.e. T1, Satellite, Wide Area Network, Lease Line Dial up etc.
      • Encryption/ VPN’s utilized etc.
      • Role of the network or system
    • Scope of test
      • Constraints and limitations imposed on the team i.e. Out of scope items, hardware, IP addresses.
      • Constraints, limitations or problems encountered by the team during the actual test
      • Purpose of Test
        • Deployment of new software release etc.
        • Security assurance for the Code of Connection
        • Interconnectivity issues.
      • Type of Test
        • Compliance Test
        • Vulnerability Assessment
        • Penetration Test
      • Test Type
        • White-Box
          • The testing team has complete carte blanche access to the testing network and has been supplied with network diagrams, hardware, operating system and application details etc, prior to a test being carried out. This does not equate to a truly blind test but can speed up the process a great deal and leads to a more accurate results being obtained. The amount of prior knowledge leads to a test targeting specific operating systems, applications and network devices that reside on the network rather than spending time enumerating what could possibly be on the network. This type of test equates to a situation whereby an attacker may have complete knowledge of the internal network.
        • Black-Box
          • No prior knowledge of a company network is known. In essence an example of this is when an external web based test is to be carried out and only the details of a website URL or IP address is supplied to the testing team. It would be their role to attempt to break into the company website/ network. This would equate to an external attack carried out by a malicious hacker.
        • Grey-Box
          • The testing team would simulate an attack that could be carried out by a disgruntled, disaffected staff member. The testing team would be supplied with appropriate user level privileges and a user account and access permitted to the internal network by relaxation of specific security policies present on the network i.e. port level security.
  • Executive Summary (Brief and Non-technical)
    • OS Security issues discovered with appropriate criticality level specified
      • Exploited
        • Causes
          • Hardware failing
          • Software failing
          • Human error
      • Unable to exploit – problem area
        • Causes
          • Hardware failing
          • Software failing
          • Human error
    • Application Security issues discovered with appropriate criticality level specified
      • Exploited
      • Unable to exploit – problem area
    • Physical Security issues discovered with appropriate criticality level specified
      • Exploited
      • Unable to exploit – problem area
    • Personnel Security issues discovered with appropriate criticality level specified
      • Exploited
      • Unable to exploit – problem area
    • General Security issues discovered with appropriate criticality level specified
      • Exploited
      • Unable to exploit – problem area
  • Technical Summary
    • OS Security issues discovered
      • File System Security
        • Details of finding
          • Example: A FAT partition was found. FAT by default does not give the ability to set appropriate access control permissions to files. In addition moving files to this area removes the protection of the current ACLs applied to the file.
        • Recommendation and fix
          • Example: Format the file system to NTFS.
      • Password Policy
        • Details of finding
          • Example: LM Hashes found still being utilized on the network.
        • Recommendation and fix
          • Example: Ensure NTLM2 is enforced by means of the correct setting in Group Policy.
      • Auditing Policy
        • Details of finding
          • Example: Logon success and failure was not enabled
        • Recommendation and fix
          • Example: Amend appropriate Group Policy Objects and ensure it is tested and then applied to all relevant Organizational Units etc.
      • Patching Policy
        • Details of finding
          • Example: Several of the latest Microsoft patches were found to be missing
        • Recommendation and fix
          • Example: Ensure a rigorous patching policy is instigated after first being tested on a development LAN to ensure stability. Review the settings on the WSUS server and ensure that it is regularly updated and an appropriate update strategy is instigated for the domain.
      • Anti-virus Policy
        • Details of finding
          • Example: Several workstations were found to have out of date anti-virus software. In addition where it was found to be installed the actual product was found to be mis-configured and did not provide on-access protection.
        • Recommendation and fix
          • Example: Ensure all workstations are regularly updated and configured correctly to ensure maximum protection is afforded
      • Trust Policy
        • Details of finding
          • Example: Users from one domain were unable to access resources on another tree.
        • Recommendation and fix
          • Example: Review transitive and non-transitive trusts and ensure that all relevant trusts have been established.
    • Web Server Security
      • File System Security
        • Details of finding
        • Example: i.e. Incorrect permission on www root Recommendation and fix
        • Example: Apply more stringent permissions or remove various users/groups that currently have access to this area.
      • Password Policy
        • Details of finding
          • Example: Areas of the website that should be Protected did not have any password mechanism enforced.
        • Recommendation and fix
          • Example: Ensure areas that require access to be limited are password protected.
      • Auditing Policy
        • Details of finding
          • Example: Web server logs were not being reviewed for illicit behaviors.
        • Recommendation and fix
          • Example: Regularly review all audit logs.
      • Patching Policy
        • Details of finding
          • Example: The latest patch was not applied to the server leaving it susceptible to a Denial of Service Attack.
        • Recommendation and fix
          • Example: Apply the latest patch after testing on a development server to ensure compatibility with installed applications and stability of the server is maintained.
      • Lockdown Policy
        • Details of finding
          • Example: The IIS lockdown tool has not been applied to the web server.
        • Recommendation and fix
          • Example: Apply the IIS lockdown tool to the server after first testing on a development server to ensure compatibility with installed applications and stability of the server is maintained.
    • Database Server Security
      • File System Security
        • Details of finding
          • Example: Loose access control permissions were found on directories containing important configuration files that govern access to the server.
        • Recommendation and fix
          • Example: Ensure stringent access control permissions are enforced.
      • Password Policy
        • Details of finding
          • Example: Clear text passwords were found stored within the database.
        • Recommendation and fix
          • Example: Ensure all passwords, if required to be stored within the database are encrypted and afforded the maximum protection possible.
      • Auditing Policy
        • Details of finding
          • Example: Reviewing the audit logs from the TNS Listener were not being carried out.
        • Recommendation and fix
          • Example: Ensure all relevant audit logs are regularly inspected. Audit logs may give you the first clue to possible attempts to brute force access into the database.
      • Patching Policy
        • Details of finding
          • Example: The latest Oracle CPU was not installed, leaving the system susceptible to multiple buffer and heap overflows and possible Denial of Service attacks.
        • Recommendation and fix
          • Example: Install the latest Oracle CPU after first testing on a development server to ensure adequate compatibility and stability.
      • Lockdown Policy
        • Details of finding
          • Example: Numerous extended stored procedures were directly accessible by the public role.
        • Recommendation and fix
          • Example: Ensure the public role is revoked from all procedures that direct access is not required or utilized.
      • Trust Policy
        • Details of finding
          • Example: Clear text Link passwords were discovered.
        • Recommendation and fix
          • Example: Ensure all Link passwords are encrypted, review the requirement to utilize these Links on a regular basis.
    • General Application Security
      • File System Security
        • Details of finding
        • Recommendation and fix
        • Password Policy Details of finding
        • Recommendation and fix
      • Auditing Policy
        • Details of finding
        • Recommendation and fix
      • Patching Policy
        • Details of finding
        • Recommendation and fix
      • Lockdown Policy
        • Details of finding
        • Recommendation and fix
      • Trust Policy
        • Details of finding
        • Recommendation and fix
    • Business Continuity Policy
      • Backup Policy
        • Details of finding
        • Recommendation and fix
      • Replacement premises provisioning
        • Details of finding
        • Recommendation and fix
      • Replacement personnel provisioning
        • Details of finding
        • Recommendation and fix
      • Replacement software provisioning
        • Details of finding
        • Recommendation and fix
      • Replacement hardware provisioning
        • Details of finding
        • Recommendation and fix
      • Replacement document provisioning
        • Details of finding
        • Recommendation and fix
  • Annexes
    • Glossary of Terms
      • Buffer Overflow
        • Normally takes the form of inputting an overly long string of characters or commands that the system cannot deal with. Some functions have a finite space available to store these characters or commands and any extra characters etc. over and above this will then start to overwrite other portions of code and in worse case scenarios will enable a remote user to gain a remote command prompt with the ability to interact directly with the local machine.
      • Denial of Service
        • This is an aimed attacks designed to deny a particular service that you could rely on to conduct your business. These are attacks designed to say overtax a web server with multiple requests which are intended to slow it down and possibly cause it to crash. Traditionally such attacks emanated from one particular source.
      • Directory Traversal
        • Basically when a user or function tries to “break” out of the normal parent directory specified for the application and traverse elsewhere within the system, possibly gaining access to sensitive files or directories in the process.
      • Social Engineering
        • Normally uses a limited range of distinct subject matter to entice users to open and run an attachment say. Usually associated with phishing/E-mail type attacks. The main themes are:
          • Sexual – Sexual ideas/pictures/websites,
          • Curiosity – Friendly themes/appealing to someone’s passion or obsession,
          • Fear – Reputable sources/virus alert,
          • Authority – Current affairs/bank e-mails/company e-mails.
      • SQL Injection etc.
        • Basically when a low privileged user interactively executes PL/SQL commands on the database server by adding additional syntax into standard arguments, which is then passed to a particular function enabling enhanced privileges.
    • Network Map/Diagram
    • Accompanying Scan Results – CD-ROM
    • Vulnerability Definitions
      • Critical
        • A vulnerability allowing remote code execution, elevation of privilege or a denial of service on an affected system.
      • Important
        • A security weakness, whose exploitation may result in the compromise of the Confidentiality, Integrity or Availability of the company’s data.
      • Information Leak
        • Insecure services and protocols are being employed by the system allowing potentially allowing unrestricted access to sensitive information i.e.:
          a. The use of the Finger and Sendmail services may allow enumeration of User IDs.
          b. Anonymous FTP and Web based services are being offered on network devices or peripherals.
          c. Disclosure of Operating System, Application version details and personal details of system administration staffs.
      • Concern
        • The current systems configuration has a risk potential to the network concerned though the ability to exploit this is mitigated by factors such as default configuration, auditing, or the difficulty level or access level required to carry out an exploit. This includes the running of network-enabled services that are not required by the current business continuity process.
      • Unknowns
        • An unknown risk is an unclear response to a test or an action whose impact can be determined as having minimal impact on the system. The test identifying this risk may or may not be repeatable. While the results do not represent a security risk per see, they should be investigated and rectified where possible. Unknowns may also be due to false positives being reported, however, do require follow up response.
    • Details of Tools Utilized.
    • Methodology Utilized.
      • Reconnaissance
        • The tester would attempt to gather as much information as possible about the selected network. Reconnaissance can take two forms i.e. active and passive. A passive attack is always the best starting point as this would normally defeat intrusion detection systems and other forms of protection etc. afforded to the network. This would usually involve trying to discover publicly available information by utilizing a web browser and visiting newsgroups etc. An active form would be more intrusive and may show up in audit logs and may take the form of an attempted DNS zone transfer or a social engineering type of attack.
      • Enumeration
        • The tester would use varied operating system fingerprinting tools to determine what hosts are alive on the network and more importantly what services and operating systems they are running. Research into these services would then be carried out to tailor the test to the discovered services.
      • Scanning
        • By use of vulnerability scanners all discovered hosts would be tested for vulnerabilities. The result would then be analyzed to determine if there any vulnerabilities that could be exploited to gain access to a target host on a network.
      • Obtaining Access
        • By use of published exploits or weaknesses found in applications, operating system and services access would then be attempted. This may be done surreptitiously or by more brute force methods. An example of this would be the use of exploit engines i.e. Metasploit or password cracking tools such as John the Ripper.
      • Maintaining Access
        • This is done by installing a backdoor into the target network to allow the tester to return as and when required. This may be by means of a rootkit, backdoor trojan or simply the addition of bogus user accounts.
      • Erasing Evidence
        • The ability to erase logs that may have detected the testing teams attempts to access the network should ideally not be possible. These logs are the first piece of evidence that may prove that a possible breach of company security has occurred and should be protected at all costs. An attempt to erase or alter these logs should prove unsuccessful to ensure that if a malicious attacker did in fact get access to the network then their every movement would be recorded.
      • See Penetration Test Framework for more detail
    •   Apart from the above security testing reports :
  • Sample Penetration Test Report by Offensive Security— An excellent report by an excellent team.
    Writing a Penetration Testing Report — Probably one of the best papers on this subject. It was written by Mansour A. Alharbi for his GIAC certification. The author starts with report development stages, then describes the report format and ends it with a sample report.
    Penetration Testing Report— Sample report by
    Penetration Test Report— Another good sample report
    Penetration Test Report— Sample OSSAR report
    penetration testing report template— Template by
Hope it helps