By a very nice coincidence I have bumped into this interesting paper (dating around 15 Jul 2008) - “BREAKING THE BANK - VULNERABILITIES IN NUMERIC PROCESSING WITHIN FINANCIAL APPLICATIONS” - ENJOY the reading!
Given I currently work in a telecom billing software company - I just cannot find enough words and meanings to confirm with sorrow that pretty-fucking-many of my fellow programmers do not give a shi…ny glass for avoiding this kind of problems. Worst, they don’t even realize it :-S…
PS: …and YES, Bank Of Cyprus (along with its new migrated Java/JSF-based banking application - a special post on this to follow) allows/uses:
When it comes to speaking about money, a lot of people get interested. And nowadays most money discussion evolve around or near-by the EUR-USD exchange rates.
Some people (including me sometime ) are unhappy to depend and always lose their honestly earned savings because of some avid and greedy circles of interest are playing with exchange rates and make them uncontrollable…
Some points why USSD is a good choice:
- USSD and USSD replies are free compared to SMS (except special, VAS, etc. numbers)
- USSD and USSD replies interact with 3rd party USSD Gateways software which most probably can be attacked more easy compared to SMSC
- USSD Gateways (if not crashed by a border-case/not-tested/unusual/malformed USSD message or USSD reply), forward the messages to Applications. Most probably “Third party content and application providers” suffer from buffer overflow, script injection, SQL injection, etc.
According to http://www.truteq.com/tips/ussd/:
“The menus are served by applications. This may not be at the GSM network operator, but at a content provider connected to the USSD infrastructure. Applications or content can therefore be served from :
1. Standard supplementary services
2. GSM Network Operators value-added services
3. Third party content and application providers
- USSD sessions implementation mechanisms can be exploited in USSD Gateways (grow huge sessions, open huge number of sessions, etc.)
Fuzzing requires a lot of messages/replies back and forth through TELCO’s equipment. Many may say that such activity may not go unnoticed, and this is true.
The point I want to discuss here is also somehow related to trust or mis-trust whether a given called subscriber really went out of GSM network reach/had the battery discharged during idle OR the subscriber actually shut-off his phone and pretends he is out of network reach/battery discharched.
This trust/mis-trust often comes as a facade dialogue template:
John: “I tried to called you regarding XYZ”
Bob: “Umm, I am really sorry - I really wanted to talk to you, but I lost network/I had phone battery discharged” (when actually Bob did switch off his phone on purpose not to be reachable specifically by John and/or other calling parties)
Now there is really a way, without having any technical device or very specific knowledge to find out whether a subscriber has shut down his phone or went out of network-reach or had his battery discharched.
26C3 is over… It was a fun experience however !
Some key points:
Also, I have attended a very nice and neat workshop put up by Mathias Coinchon from OpenDigitalRadio.org
Mathias also have kindly provided the GNU Radio Companion files used in “26C3 Radio Broadcasting Workshop”.
Ever wondered how the thousand pages books are scanned and put online? I was wondering that too.
A nice lecture and slides are here:
A deep dive into brain's curiosities
|<< <||Current||> >>|