Jean-Marc's infotainment stream » Following the White Rabbit Blog

« Expand/Collapse

Following the White Rabbit Blog

July 26, 2010
4:37
The DMCA vs "Reverse Engineering" Software
» ‎ Following the White Rabbit Blog

As we open up another Black Hat Defcon week ... this should make your research presentation more interesting... So there is this exceptionally interesting story running in the "Your Rights Online" section of Slashdot today, and the more I think about it the more I think this needs to be analyzed more. The article is specific to a recent ruling in the GE vs. MGE UPS case [cited here] where a "dongle" was bypassed to continue to use expired software but I think there are more far-reaching implications here...img src="http://feeds.feedburner.com/~r/RafalLos/~4/gRe9-5-dVyM" height="1" width="1"/
July 20, 2010
22:24
Star West - Security Talk at a Software Quality Conference?
» ‎ Following the White Rabbit Blog

What is this madness? What does security have to do with software quality? This is the 2nd year in a row that I've been preaching security topics (testing, that is) at this wonderfully put-on software quality conference called Star West. Run by the folks at SQE, this conference is a multi-day event that's hosted twice a year (once out east at Star East, and once out west at Star West, accordingly) bringing together practical speakers, workshops and some really cool innovative stuff into the world of the quality engineer.img src="http://feeds.feedburner.com/~r/RafalLos/~4/gaJwhIuuIf4" height="1" width="1"/
July 16, 2010
20:35
Trust Nothing, No One - FireFox Add-On Backdoored!
» ‎ Following the White Rabbit Blog

A startling revelation was recently unleashed upon the Mozilla FireFox community ...and an entire following's world view was shattered. Johann-Peter Hartmann of SektionEins revealed what he had discovered - a FireFox add-on he was using had been backdoored. I won't go and re-state the NetCraft article so you can go read that on your own - but I do have some comments... as you would expect!img src="http://feeds.feedburner.com/~r/RafalLos/~4/HH5Ubc5H3uE" height="1" width="1"/
July 15, 2010
21:10
I've Joined the SBN
» ‎ Following the White Rabbit Blog

Since I know you can't get enough Information Security content... I've joined the Security Bloggers Network! That's right, all the news, breaking information, and content on security you can possibly stand is at your fingertips, delivered and streamed - and now the White Rabbit is the stream.img src="http://feeds.feedburner.com/~r/RafalLos/~4/Vfd1kcTaGLg" height="1" width="1"/
July 14, 2010
23:21
What We're All Forgetting ...
» ‎ Following the White Rabbit Blog

This morning on my Twitter feed I posed the question: "What's the last thing orgs think about relating to the web application lifecycle? [hint: testing] Send your thoughts, and stay tuned!" As expected, I got a series of varying answers, but only 1 person really got close - zeroing in on data. So what is this one thing that the web application lifecycle misses, that relates to testing and has to do with data?img src="http://feeds.feedburner.com/~r/RafalLos/~4/AkXpbyq1MDw" height="1" width="1"/
July 13, 2010
6:31
"We Haven't Been Hacked" ...is not a metric
» ‎ Following the White Rabbit Blog

An interesting thing happens when speaking with the few non-believers in Web Application Security out there. Many of them cite the it hasn't happened to me metric for why they don't feel the need to incorporate better security (or any at all) into their development programs. You know me though, by now, and probably know that I always have a follow-up question back at those people. "So, how do you know that your web applications haven't, or aren't being, compromised?"img src="http://feeds.feedburner.com/~r/RafalLos/~4/M8VNb0LJviQ" height="1" width="1"/
July 09, 2010
6:31
The True Problem with Web Apps and Security
» ‎ Following the White Rabbit Blog

If you read this blog, I hope you take the time to read some of the comments people take the time to write, I know I do. Security is all about community, contributing to the greater good, and learning from each other. If I write and everyone just reads, nods and then goes about their day without offering experiences, comments, or counter-points this whole experience isn't as meaningful. I especially enjoy when someone makes an interesting counter-point to something I say ...like 'dre does in my previous post.img src="http://feeds.feedburner.com/~r/RafalLos/~4/EWI8TF-2IMU" height="1" width="1"/
July 06, 2010
5:18
Web Apps Have It So Easy
» ‎ Following the White Rabbit Blog

Web-based applications have it so easy ...they really do. Compared to locally installed applications, web applications are a cake-walk. The primary reason for this is, of course, being able to make changes when a defect is discovered that has severe security implications.img src="http://feeds.feedburner.com/~r/RafalLos/~4/dXBNFv_lkew" height="1" width="1"/
June 29, 2010
16:37
Oops. Sorry for the unsolicited scan.
» ‎ Following the White Rabbit Blog

I'm sure everyone who reads this blog is already aware of this type of situation - but I think I'll at least repeat it once here ... take extreme care when running your web app security scanning tools lest you give someone an unsolicited security audit! I would prefer not to have this conversation with any of you ... ever.img src="http://feeds.feedburner.com/~r/RafalLos/~4/fAPpYJsfZgo" height="1" width="1"/
June 27, 2010
20:20
Avoiding WebAppSec Russian Roulette - or "Picking Your Tool"
» ‎ Following the White Rabbit Blog

Web Application Security Scanners are an interesting lot. Most of them have few things in common, as vendors (or developers) of these tools are as diverse as the technologies they produce - and it's hopefully not surprising that each piece of software (aka "scanner") is written to a slightly different specification. So how are you going to pick which one is right for you? This process is a little like deciding to purchase your first car...img src="http://feeds.feedburner.com/~r/RafalLos/~4/cwEzdy3jvKk" height="1" width="1"/
June 22, 2010
20:34
That's Not My Problem
» ‎ Following the White Rabbit Blog

A very un-interesting phenomenon happens when you try and talk security with just about anyone outside a traditional "security team" these days ... you run into the that's not my problem effect. While we've been seeing this for years and years, since the beginning really - I think it's more important now with the workloads, and compliance challenges most companies are facing.img src="http://feeds.feedburner.com/~r/RafalLos/~4/dRPiNmEVjJQ" height="1" width="1"/
June 15, 2010
22:49
Conversations with QA Managers
» ‎ Following the White Rabbit Blog

..."Last night I was introduced to a QA Manager for a very large Canadian company. I asked for his thoughts on my recent approach to application security through QA and got back a very good conversation, which could have continued if not for the need to get some sleep."img src="http://feeds.feedburner.com/~r/RafalLos/~4/7k7V-bPbzSc" height="1" width="1"/
June 14, 2010
22:37
Meet the QA Manager, the Security Team's New Best Friend
» ‎ Following the White Rabbit Blog

This week I'm traveling and at both HP Software Universe (the gathering of all HP Software customers, thought leaders and sales teams here in Washington, D.C.) and later in the week at the ISC2 Secure SDL. It's great to meet so many C-level security managers and CISOs but it's even more intriguing to meet so many Quality Managers, quot;VP of Appsquot; type folks, at the HP gathering because I am more convinced than ever that these people are the next important target for defeating web application security issues. Don't believe me? Keep reading.img src="http://feeds.feedburner.com/~r/RafalLos/~4/SgQZWCxA8U8" height="1" width="1"/
May 25, 2010
0:49
Psychology of "Secure Code"
» ‎ Following the White Rabbit Blog

pHappy Monday everyone,/pBR pnbsp; I#39;ve not written anything in a few weeks because I#39;ve been absolutely buried in the presentation of this new technology we#39;ve launched in the ASC.nbsp; I wanted to drop a quick post today to give you a little insight into what I#39;ve been reading and something I picked up on from the psychology angle./pBR pnbsp; In the past 5+ years in the web app security program space I#39;ve tried every approach to getting developers to write more secure code.nbsp; I#39;ve tried the carrot approach - offering positive reinforcement and rewards to developers as an incentive to write better, more robust and secure code.nbsp; I#39;ve also tried the stick approach - auditing, punishing and shaming developers who repeatedly write poor code.nbsp; Neither approach has actually produced the results I would have liked to see, and that#39;s the topic of today#39;s post./pBR pnbsp; Recently I#39;ve seen a few good a target="_blank" title="Coffee To Code: Humble Helps" href="http://coffeetocode.net/2010/05/humble-helps/"posts /aout there that reminded me just how and why this is such a difficult battle.nbsp; The matter of the OpenCart saga is a perfect demonstration that we in Information Security (Web App Sec) are far removed from our brethren in app dev.nbsp; Even though some of us in security (most?) came from the development side of the house - it#39;s a far distant memory and it shows.nbsp; Sometimes we completely forget what the motivations of developers are.nbsp; They are simple: write code to spec as fast as possible.nbsp; If you doubt what I#39;m saying look at most any project plan that involves application development.nbsp; There is usually an insanely short timeline to write the code, less time to actually test the code and security ... well that#39;s typically an after-thought./pBR pnbsp; Focusing on the development team, strictly speaking, they don#39;t often get quot;secure coding trainingquot; ... and even worse it#39;s rarely in their requirements.nbsp; Code is meant to be functional, fast and only as a tertiary idea is it ever asked to be secure.nbsp; Sure, this is different in what#39;s referred to as a quot;high security environmentquot; - but I bet that the vast majority of code-slingers worry little about security./pBR pnbsp; The mentality just isn#39;t there for quot;secure codequot; to be second nature to developers.nbsp; The reason?nbsp; The two vastly different mind-sets ... builders vs. breakers.nbsp; Those of us that cut our teeth on app dev then moved on to web app security started as builders but then something clicked in our brains that made us breakers.nbsp; Now we understand both sides of it, and then we learn how dangerous insecure code can be, why it works that way, and work tirelessly to prevent it.nbsp; On the other hand, builders simply build code to specifications.nbsp; Never getting that quot;breakerquot; light-bulb to go on makes it nearly impossible to understand why writing secure code is so critical - and more importantly why anyone would ever want to break!/pBR pnbsp; Now - let#39;s couple that with the approach that security pros take with developers ... and we have a great reason the two don#39;t talk.nbsp; Developers write code, insecurely, by nature.nbsp; The security guy comes along and tries to be helpful once, twice lacks the patience to really see this through.nbsp; Then the claws come out, feelings get hurt and both sides go on the defensive and then the offensive.nbsp; Now you#39;ve got a typical standoff on the playground, like back in grade school.nbsp; Remember that?nbsp; Remember when you tried to help someone with building something in the sandbox?nbsp; Remember what happened when you tried to itell them/i that you knew better?nbsp; Doesn#39;t matter if you used to be best friends - feelings got hurt and neither of you talked to each other./pBR pnbsp; The lesson then ...is this.nbsp; Web App Security professionals must bilearn patience/i/b when working with their code-slinging counterparts.nbsp; They must learn that it#39;s much easier to point out flaws than it is to actually write code without those flaws.nbsp; Security pros must come to the realization that code bundles are increasingly complex and that makes securing them ever-harder without the icooperative relationship/i with the security group./pBR pnbsp; Folks - this may shock you but ino one writes quot;badquot; code on purpose/i.nbsp; Sometimes a developer just doesn#39;t know better ... and then, like Mr. Miyagi would say quot;Patience, Daniel-sanquot; ...have patience, and remember that you too were not so security smart some time back./pBR pPlay nice on the playground or everyone loses recess privileges!/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/D2T-yKaZxik" height="1" width="1"/
May 24, 2010
16:49
Psychology of "Secure Code"
» ‎ Following the White Rabbit Blog

pHappy Monday everyone,/p pnbsp; I#39;ve not written anything in a few weeks because I#39;ve been absolutely buried in the presentation of this new technology we#39;ve launched in the ASC.nbsp; I wanted to drop a quick post today to give you a little insight into what I#39;ve been reading and something I picked up on from the psychology angle./p pnbsp; In the past 5+ years in the web app security program space I#39;ve tried every approach to getting developers to write more secure code.nbsp; I#39;ve tried the carrot approach - offering positive reinforcement and rewards to developers as an incentive to write better, more robust and secure code.nbsp; I#39;ve also tried the stick approach - auditing, punishing and shaming developers who repeatedly write poor code.nbsp; Neither approach has actually produced the results I would have liked to see, and that#39;s the topic of today#39;s post./p pnbsp; Recently I#39;ve seen a few good a target="_blank" title="Coffee To Code: Humble Helps" href="http://coffeetocode.net/2010/05/humble-helps/"posts /aout there that reminded me just how and why this is such a difficult battle.nbsp; The matter of the OpenCart saga is a perfect demonstration that we in Information Security (Web App Sec) are far removed from our brethren in app dev.nbsp; Even though some of us in security (most?) came from the development side of the house - it#39;s a far distant memory and it shows.nbsp; Sometimes we completely forget what the motivations of developers are.nbsp; They are simple: write code to spec as fast as possible.nbsp; If you doubt what I#39;m saying look at most any project plan that involves application development.nbsp; There is usually an insanely short timeline to write the code, less time to actually test the code and security ... well that#39;s typically an after-thought./p pnbsp; Focusing on the development team, strictly speaking, they don#39;t often get quot;secure coding trainingquot; ... and even worse it#39;s rarely in their requirements.nbsp; Code is meant to be functional, fast and only as a tertiary idea is it ever asked to be secure.nbsp; Sure, this is different in what#39;s referred to as a quot;high security environmentquot; - but I bet that the vast majority of code-slingers worry little about security./p pnbsp; The mentality just isn#39;t there for quot;secure codequot; to be second nature to developers.nbsp; The reason?nbsp; The two vastly different mind-sets ... builders vs. breakers.nbsp; Those of us that cut our teeth on app dev then moved on to web app security started as builders but then something clicked in our brains that made us breakers.nbsp; Now we understand both sides of it, and then we learn how dangerous insecure code can be, why it works that way, and work tirelessly to prevent it.nbsp; On the other hand, builders simply build code to specifications.nbsp; Never getting that quot;breakerquot; light-bulb to go on makes it nearly impossible to understand why writing secure code is so critical - and more importantly why anyone would ever want to break!/p pnbsp; Now - let#39;s couple that with the approach that security pros take with developers ... and we have a great reason the two don#39;t talk.nbsp; Developers write code, insecurely, by nature.nbsp; The security guy comes along and tries to be helpful once, twice lacks the patience to really see this through.nbsp; Then the claws come out, feelings get hurt and both sides go on the defensive and then the offensive.nbsp; Now you#39;ve got a typical standoff on the playground, like back in grade school.nbsp; Remember that?nbsp; Remember when you tried to help someone with building something in the sandbox?nbsp; Remember what happened when you tried to itell them/i that you knew better?nbsp; Doesn#39;t matter if you used to be best friends - feelings got hurt and neither of you talked to each other./p pnbsp; The lesson then ...is this.nbsp; Web App Security professionals must bilearn patience/i/b when working with their code-slinging counterparts.nbsp; They must learn that it#39;s much easier to point out flaws than it is to actually write code without those flaws.nbsp; Security pros must come to the realization that code bundles are increasingly complex and that makes securing them ever-harder without the icooperative relationship/i with the security group./p pnbsp; Folks - this may shock you but ino one writes quot;badquot; code on purpose/i.nbsp; Sometimes a developer just doesn#39;t know better ... and then, like Mr. Miyagi would say quot;Patience, Daniel-sanquot; ...have patience, and remember that you too were not so security smart some time back./p pPlay nice on the playground or everyone loses recess privileges!/pdiv style="clear:both;"/divimg src="http://www.communities.hp.com/securitysoftware/aggbug.aspx?PostID=111860" width="1" height="1"img src="http://feeds.feedburner.com/~r/RafalLos/~4/Sa_bd2ioqoA" height="1" width="1"/
May 05, 2010
8:17
Source: Boston Talk
» ‎ Following the White Rabbit Blog

pHi everyone - there are a bunch of you who have been asking if the Source: Boston talk titled quot;Into the Rabbit Hole...quot; Matt Wood (from Director HP Web Security Research) and I gave was recorded.nbsp; Well, thanks to #39;dre for pointing out that the video is up and viewable on a target="_blank" title="SecurityTube LINK" href="http://securitytube.net/Execution-Flow-Based-Web-Application-Testing-%28SOURCE-Boston-2010%29-video.aspx"SecurityTube/a!/pBR pHere#39;s the embedded video... /pBR pnbsp;embed src="http://blip.tv/play/AYHa3ysC" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" height="300" width="480"/embed/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/M9suAzMD8iY" height="1" width="1"/
May 04, 2010
2:36
The Lesser of Two Weevils
» ‎ Following the White Rabbit Blog

pRemember that scene in quot;a target="_blank" title="Capt. Jack Aubrey quote" href="http://www.imdb.com/title/tt0311113/quotes"Master amp; Commander/aquot; where the captain had to let one of his men be swallowed by the sea in order to save the rest of the ship?nbsp; That scene devolved into a joke about the ilesser of two evils/i ... so as I looked through that title today I thought about the idea of the lesser of two evils./pBR pFrom the WebAppSec perspective, there are two primary evils - bdevelopers /band bhackers/b.nbsp; If you#39;ve ever thought about this problem from this perspective - read through this and let me (and the readers here) know what you think .../pBR ulBR libDevelopers /b- iDevelopers are a necessary evil/i.nbsp; I don#39;t mean to call developers evil of course... but a careless or untrained developer can wreak havok with just a few strikes of the keyboard.nbsp; Web Applications are getting so much attention in the media lately because people are breaking into them and pillaging at an unprecedented rate.nbsp; The reason?nbsp; Developers.nbsp; Developers write the code and if they#39;re not properly trained and given the tools, processes and knowledge to successfully write a target="_blank" title="Rugged Software" href="http://www.ruggedsoftware.org/"rugged/a, bullet-proof code ... it doesn#39;t matter how many shiny devices you put on the wife in front of them...ahem.nbsp; Developers are focused on writing code to specifications (functional and performance, usually) with a general disregard for privacy and security ...and this can be dangerous!/liBR libHackers/b - Hackers are the embodiment of evil.nbsp; They look for weakness in our systems (especially web applications) and exploit them for their monetary pleasure.nbsp; They make money and get rich off of your company#39;s misfortune.nbsp; They aim to scheme, scam and break - all without regard for your company#39;s privacy or liability to the user-base.nbsp; Hackers deconstruct your web applications, find tiny holes to exploit and steal what they can - often without even being detected./liBR /ulBR pSo then, I challenge you to think about it and answer ...which is worse?nbsp; The buneducated developer/b or the bmalicious hacker/b?nbsp; ...now explain why?/pBR pI#39;d love to hear your responses ... feel free to post them in the comments/feedback section!/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/Z4LjVD4S95s" height="1" width="1"/
May 01, 2010
5:16
Episode 30 - "But wait! there's more!"
» ‎ Following the White Rabbit Blog

pI saved this gem for last on purpose. If you#39;re reading this and say to yourself ...quot;Hey! That#39;s my companyquot; then I think you can thank your bone appsec guy/b (you know who he is) because he#39;s driving awareness, process and tools into your environment to help fix these quot;neon welcome signquot; equivalents in your environment.nbsp; Also ... if you#39;re reading this and you remember this meeting ... I congratulate you for continuing the awareness that was started over a year ago... you#39;re on your way, just don#39;t give up!/pBR p------ inow, on to the final chapter/i/pBR pTruth is, sometimes people in massive IT organizations that work with patient and health information just don#39;t believe they have security issues until you show them... with their manager watching.nbsp; This incident took place a little over a year ago when I was visiting a company who was struggling with web app security like everyone else ... and losing.nbsp; The one IT guy who really did care about web app sec was not being heard and the iproof/i just wasn#39;t there that issues were plentiful within the organization#39;s infrastructure.nbsp; I was invited to demo our web app sec testing suite to these guys and my contact wanted to make sure we found as much impactful stuff as possible ... and we sure did.nbsp; Given only 2 days we had to make fast work of our findings, but sadly it was almost too easy... like shooting dead fish in a bucket.nbsp; After a day and a half of findings and putting together a presentation I got a chance to present to the CISO and some senior IT staff which was great ... and we started talking security vulnerabilities and the issues we found./pBR pilittle did I know how crazy things would get .../i/pBR pSo, as soon as I dived in I was asked the typical question ... quot;So what?quot; ... so I decided to fire up our bSQL Injector/b tool (just for the record, if SQL Injector can pull out your database it#39;s time to shut down your web site ....just sayin#39;) and go to town.nbsp; I started with the company#39;s ihome page which had had a login form/i ...and things went sideways from there.nbsp; Immediately SQL Injector was able to determine that the application was easily vulnerable to SQL injection.nbsp; Since this was a panel of seasoned skeptics, I decided to take it a step further and get SQL Injector to pull back the database name, version and some basic information.nbsp; I was still faced with the quot;so what?quot; question .../pBR pNot wanting to be stumped by apathy I went a step further and started explaining what this tool was doing ...and then went ahead and pulled the database table names for the audience.nbsp; iNOW I was getting a silghtly panicked look from the DBAs and developers in the audience/i ... finally!nbsp; Next, I showed that with the click of the mouse I could pull the columns and start quot;pumping dataquot; ... all without setting off any of their iIPS alarms/i ... whoops #1./pBR pIn the spirit of quot;But wait! there#39;s morequot; ...the DBA manager started looking a little worried.nbsp; I was explaining that the typical bxp_cmdshell/b commands could be used to entirely take over the system ...and just before I was going to execute the command to add myself as an admin user on this machine ithrough SQL injection/i ...I was stopped./pBR pI was fairly proud of myself that this demo and talk was going so well and that i was effectively able to demonstrate totally owning their database and server ... but there was more to this.nbsp; The DBA lead stopped me from adding myself to the system, because, as he explained, this system was clustered ... and it shared the instance with their ERP application./pBR pOuch, right?nbsp; But wait ...there#39;s more.../pBR pThis system bwhich I could completely exploit through SQL injection/b was not only clustered and shared with their ERP system - but because it was also hosting their ERP system ...it was inot in the DMZ but on their internal network/i./pBR pBut wait ... there#39;s more./pBR pOK, let#39;s review ... I can steal the database, add myself as a user on a box that is on their internal network ... how much worse can it get?!/pBR pWell ... as was explained to me and the audience, as this machine was on their internal network ... it was also participating on their internal AD environment./pBR pWait ... seriously?!nbsp; Yes./pBR pSo ... to summarize ... I was able to (without triggering any alerts) busing SQL injection/b steal their database (or modify it), and not only compromise their server but also add myself as an administrator on their internal Active Directory ... /pBR p... I think my mouth hung open, and my eyes were wide.nbsp; What do you say to this sort of situation but - quot;Wowquot;./pBR pbWhoops?/bnbsp; Yea ...whoops indeed boys and girls./pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/BLJGVJSbkMo" height="1" width="1"/
April 30, 2010
16:26
Episode 29 - "Grade A+ Broken"
» ‎ Following the White Rabbit Blog

pThese days, schools run tons of web applications both internally, and externally.nbsp; Every once in a while you pick up the paper, or read the trade magazines, or look at Twitter and see that some kid is getting blamed for ihacking/i a web app and changing their grade, or some other thing.nbsp; After reading this last email I started to wonder about some of you readers ... seriously.nbsp; I really hope this reader did the right thing and told someone (I recommend anonymously, as the consequences of a misunderstanding could be expulsion or prosecution!) about this bug ... because after I write it up here you#39;re all going to run out and try it in your school.nbsp; Here it is ...(edited for ipolitical correctness/i and anonymity - face it if I told you too much info about this app you#39;d be hacking in minutes)./pBR p------/pBR pI go to school.nbsp; A few months ago they put in a new system for the teachers to use.nbsp; It#39;s called and is just a bunch of Flash stuff in a big mashed-up page.nbsp; The teachers and students all log onto the same page and then either click on the quot;Student Accessquot; or quot;Teacher Accessquot; apps.nbsp; My friends and I were sitting in the lab and no one was around so we started playing with the teacher app.nbsp; I saw the talk on quot;hacking flash appsquot; you did and downloaded some Flash decompile tools to see what we could find./pBR pi---- I feel I need to chime in here and say that I don#39;t, and never have, condoned use of any of the tools or techniques I#39;ve described for evil purposes.../i /pBR pi(we continue...)/i The Flash app didn#39;t have any super-obvious vulns but I did find a call to an XML file, on a file-servernbsp; that was hard-coded into the app.nbsp; The XML file was on one of those quot; $ shares quot; since it was Windows, and I looked at the file.nbsp; The XML file must be a config file or something because it had a bunch of other network shares.nbsp; Looking at those network shares - I found the pot at the end of the rainbow.nbsp; The stuff in there were files named like quot;ihomework_Bio430_091209.xls/iquot;.nbsp; You can probably guess that these files had the answers to all the homework./pBR pThe web app told me where to find all the network shares (hidden network shares, like \\mtlfs0010\BIO430$) in some place where no one would have looked before, and it#39;s all thanks to the app in Flash!/pBR p------/pBR pbYIKES... Kids these days huh?/bnbsp; I really hope this person did the right thing and reported the bug ianonymously/i so the administration could have the dev company fix the product, change permissions on the shares - anything - to keep the semester from being quot;too easyquot;./pBR pbWHOOPS!!/b/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/HrKHKDjOpSM" height="1" width="1"/
1:44
Episode 28 - "Making Your Vote Count (a lot)"
» ‎ Following the White Rabbit Blog

pWe#39;ve all seen those ivoting widgets/i that companies put on their website.nbsp; Whether you#39;re voting for quot;Person of the Yearquot;, or just your favorite color of Mamp;M, or just answering a silly pole on a website you#39;re on ... you always want to make sure your vote counts, right?/pBR pWell, when you up the stakes, for example - in a fast-food restaurant chain#39;s quest for the next quot;customer favoritequot; - you should probably make sure that your voting app is sound and that people can#39;t play the system.nbsp; Before developers discovered the need for re-CAPTCHAs, time+IP-based limiting, and other trickery most voting type applications were wide open to abuse by someone who had the intentions./pBR pIt just so happens that I had the pleasure of ilegitimately testing/i one such system which was set to go live on the site of a vendor I was rather fond of.nbsp; Diving into the application I immediately wanted to figure out a way to game the system ...make my choice #1 by a landslide.nbsp; Turns out it was a little tougher than I would have liked.nbsp; The application was pure HTML (for a change) and if you wanted to vote you first had to give it demographic information.nbsp; After receiving your information the system would give you a page where you could for the fast-food item of your choosing./pBR pSome of the methods my team used to try and exploit the system were variations of re-playing the quot;votequot; POST message.nbsp; After a few hours of beating on the application we realized that it wasn#39;t going to be so simple.nbsp; Yes, the application looked at source IP address - we could get around that.nbsp; Yes, the application looked at the user-agent and set a cookie - we could get around that.nbsp; ...but there was something else./pBR pWe scoured the packets and it turned out that we had to focus on one of the dozen or so cookies that were set during the registration process.nbsp; One particularly interesting one was called quot;bUserRegVoterID=/bquot; so we figured we would start there.nbsp; Starting to tamper with this string was fruitless as it generated quot;Sorry - our system did not recognize you, please register again (LINK)quot;.nbsp; One of the team noticed a pattern though, in that parameter ...while it wasn#39;t incrementing or anything it did look an awful lot like a base64-encoded string ...minus the quot;==quot; at the end./pBR pImagine my surprise when we took the strings from 10 registrations, added quot; = quot; to the end and base64-decoded them... here are a few examples:/pBR pMTI6MjEuMTMtMDQvMDkvMDU=nbsp; --gt;nbsp; 12:21.13-04/09/05br /MTI6MjIuMTItMDQvMDkvMDU=nbsp; --gt;nbsp; 12:22.12-04/09/05br /MTI6MjQuNDAtMDQvMDkvMDU=nbsp; --gt;nbsp; 12:24.40-04/09/05br /MTI6MjQuMzEtMDQvMDkvMDU=nbsp; --gt;nbsp; 12:24.31-04/09/05br /MTI6MjUuNTktMDQvMDkvMDU=nbsp; --gt;nbsp; 12:25.59-04/09/05br /MTI6MjUuMDEtMDQvMDkvMDU=nbsp; --gt;nbsp; 12:25.01-04/09/05br /MTI6MjcuMjctMDQvMDkvMDU=nbsp; --gt;nbsp; 12:27.27-04/09/05br /MTI6MjguMzgtMDQvMDkvMDU=nbsp; --gt;nbsp; 12:28.38-04/09/05br /MTI6MjguMzgtMDQvMDkvMDU=nbsp; --gt;nbsp; 12:28.38-04/09/05br /MTI6MzAuNTAtMDQvMDkvMDU=nbsp; --gt;nbsp; 12:30.50-04/09/05/pBR pSee a pattern here?nbsp; So ... now it was time to write a script that would make sure that iour favorite/i choice would win by a landslide./pBR pnbsp;/pBR pbWHOOPS!nbsp; Gotcha!/b/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/CBdQ8F2mfGI" height="1" width="1"/
April 29, 2010
6:48
Episode 27 - "How to DoS an Airplane"
» ‎ Following the White Rabbit Blog

pI fly all the time, so seeing someone send this in bugs me, although now I#39;m tempted to figure out WHO this company is.../pBR pSomeone sent this in to me quot;anonymouslyquot; and probably with pretty good reason - this is a pretty silly and potentially devastating vulnerability in a web app.nbsp; The scary thing is that vulnerabilities like this exist all around in these AJAX-type applications ... I wonder if there are more of these?/pBR p------/pBR pTesting a web application is always interesting.nbsp; Sometimes you find subtle defects that may not ever be found by automated testing methods and it#39;s those defects that can effectively stop business.nbsp; Take this example ... DoS#39;ing an entire plane.nbsp; I#39;m speaking about the ability to cause an entire plane to fly without passengers but appear full./pBR pI found one such defect in a heavily client-loaded application a few months ago while testing.nbsp; The process of testing the application involved testing the reservation system for the airline industry.nbsp; Its interesting that the process of reviewing a functional specification was mentioned in your talk because that#39;s exactly what I was doing.nbsp; After the scanners and penetration testers were done with the app I took one more look at the application since there was a half-day left in the testing cycle and everything else was done./pBR pBrowsing the application and reading through the functional spec I found a piece of functionality that interested me.nbsp; In the process of reserving a flight the application would fire off a request in the background to the server to reserve my seat while I paid for it.nbsp; The seat was held (according to the system policy) for 10 minutes while I had a chance to pay for the flight.nbsp; What I found is that I could easily replicate the AJAX request (sort of like CSRF#39;ing the application) for a seat hold several times ... over and over until I received an error that the flight was full.nbsp; Of course, since this was a test application the back-end was acting as it would in production and since I knew no one else was reserving seats on this quot;demoquot; flight I knew I was onto something.nbsp; If I could simply send a stream of continuous requests against an arbitrary flight - I could effectively take up the whole plane for 10 minutes at a time without actually buying a seat./pBR pCould I keep a flight quot;ghostly fullquot; for real?nbsp; I tested the system after I asked the administrators to re-set the flight to empty ...and sure enough it filled up again when my script ran.nbsp; I told the developers and manager of the project.nbsp; When they asked me if it was a security bug I explained it was a business logic bug that could cost the company a lot of money and possibly empty planes being scheduled./pBR pThey fixed the bug after I demonstrated it to them ... good thing I had that extra half-day of testing huh?/pBR p------/pBR pExcellent find, quot;anonymousquot; ... the fact that this is something that would have gone live without your intervention is scary.nbsp; Maybe we should start randomly checking the airline industry reservation systems?nbsp; b(Note: I don#39;t condone this in any capacity!nbsp; Test your own systems first...)/b/pBR pbGreat find ...Whoops!nbsp; I DoS#39;d a plane!/b/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/leLCFdIpt9g" height="1" width="1"/
April 28, 2010
9:12
Episode 26 - "Trading Off the Clock"
» ‎ Following the White Rabbit Blog

pSurely you#39;ve read and recall the story published nearly everywhere about how some smarty-pants would-be investors gamed CNBC#39;s system to quot;winquot; a million dollars? Well, they didn#39;t actually win because CNBC people got wise to the hack and the cheaters got greedy - but here#39;s the a target="_blank" title="CNBC Cheaters!" href="http://www.bloggingstocks.com/2007/06/10/give-the-prize-to-the-cheaters-in-cnbcs-stock-picking-contest/"original story/a. This story is interesting because it starts to sound very similar, but has its own twist. I wonder if the same set of developers wrote both sets of code?/pBR pb------/b/pBR pI got an email from an incident response security guy (or gal?) who claims to work for one of those quot;big financial housesquot; on Wall Street or somewhere important. Interestingly enough this person had attended one of my quot;When Web 2.0 Attacks!quot; talks and decided to take that knowledge back to their desk with them.nbsp; This of course was quite dangerous since I tend to pick on Adobe Flash - not necessarily due to the shortcomings of the technology itself but mainly due to the types of code that have been historically generated in Flash.nbsp; Anyway, this person had gone back to their desk after my talk and decided to download, decompile, and dissect one of the quot;trading platform componentsquot; which was, painfully, written in Adobe Flash.nbsp; I feel the need to state that I do my best to make it clear that ihacking is illegal/i and that you should always test analysis techniques like the ones I outline in a familiar setting on code that is either your own, or that you have the approval to play with.nbsp; Apparently my contact here decided to beg for forgiveness rather than ask for permission./pBR pThe long and short of it is this - the application, which was again, written in Flash 10.x - allowed for a person to make various financial transactions tied to the Wall Street clock.nbsp; What the person doing the analysis noticed is that there was a parameter that was fed into the application which indicated (from the server to the client app) what time the transaction was initiated.nbsp; The client (Flash app) would then send what appeared to be an iencrypted POST/i to the server to complete any transaction.nbsp; It was interesting to note that quotes and other non-order-placing actions were all unencrypted ...but the order-placing component looked like it was encrypted.nbsp; The POST looked like a series of parameters all sent across Base64 encoded (no, this was not the iencryption/i) and then an ending string that was unreadable./pBR pCloser analysis of the app revealed how the inner-workings were constructed.nbsp; The Base64 encoding parameters were simply the ticket number, quantity, account number, etc ... and the iencrypted parameter/i was the quot;OrderPlaceTimequot; parameter./pBR pNow, you may be asking yourself - quot;Self, why would you need to encrypt that?quot;/pBR pThe correct answer after some testing is that the ionly way/i the server knew whether the order was being placed during a valid purchase window was by this parameter.nbsp; Indeed - the server did not check its own time stamp on a received order, rather, it trusted the client./pBR pAmongst the plethora of things wrong with this picture was the fact that the end user, with a little trickery, could craft payloads to the server that would allow someone to execute purchases after the purchase window had closed - simply by quot;tricking the systemquot; into believing that the order had been placed on time.nbsp; What could possibly go wrong you say?/pBR pHow about this ... much like in the CNBC scenario - say this was a stock ordering platform.nbsp; Say you could track the top-performing stock, and then BUY IT after the close of the bell with the price that it had during its lowest point on the day.nbsp; You could make serious money like this ... illegally of course!nbsp; All facilitated by the poor coding and some client-side stupidity./pBR pbWhoops?!nbsp; Hey SEC - are you paying any attention to these types of apps??/b/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/r3WFOzh5AS4" height="1" width="1"/
5:18
Episode 25 - "Fun with XSS"
» ‎ Following the White Rabbit Blog

pFresh from the mind of a frustrated corporate InfoSec analyst ... I BR guess if you#39;re going to prove your point you should do it BR judiciously... unless no one listens - then do what this guy did.nbsp; BR Yikes!nbsp; Hopefully he still has a job./pBR p------/pBR pThe company I work for doesn#39;t take web app security seriously. I canBR say that for a fact because every time to do an assessment and find BR security issues I am never taken seriously and the projects still go BR live without the bug fixes./pBR pLast time I had to review our biggest BR corporate portal which leads a customer into our order system - I found BR several obvious cross-site scripting vulns. When I showed these to the BR developers, then to the project manager they all had the same response: BR quot;big deal, it#39;s a pop-upquot;. The app went live without my approval, not BR shocking./pBR pI also found not only reflected XSS but stored as well BR during the process, so I thought I would show the owners how dangerous BR XSS can be and so I wrote a short script that sent all the project BR managers (including the VP of this project) an email that said quot;Check BR out the new project launch!quot;. Well, when they opened the project BR homepage they were greeted with our competitor#39;s logo and color scheme BR through CSS - all thanks to a little quot;stupid scriptquot; as they put it BR earlier./pBR pI think they got the point now.../pBR p------/pBR pbWow,BR WHOOPS! indeed./b/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/atJpVQgpBAk" height="1" width="1"/
2:53
Episode 24 - "Fun with Open Redirects"
» ‎ Following the White Rabbit Blog

pquot;Jamesquot; emailed me to let me know that he found a particularly interesting open redirect vuln a while back in his company ...and got a little HR love in the process.nbsp; Sorry quot;Jamesquot;, but I think you should have thought twice!/pBR p------/pBR pOpen redirects are interesting bugs. What most people don#39;t realize is that you can use it to defeat stupid HR policies./pBR pMy company doesn#39;t allow us to surf to quot;questionable contentquot; as they call it - but I found a bug accidentally in one of our search pages that basically allows me to view anything on the web. This is a stupid redirect but that allows the web server, apparently, to make the request to the quot;questionable contentquot; for me which bypasses all the filters we have in place./pBR pOf course, the iquestionable content/i that I#39;m referring to isn#39;t adult-oriented... I just like to look at insecure.org, and other security-related sites and mailing lists which my corporate policy won#39;t allow./pBR pSo I started reading the mailing lists and other sites by exploiting the /search.aspx?results-page={insert page here} option in our site. Since the developers obviously didn#39;t check what gets put in that iresults-page/i param I can put things like quot;http://www.insecure.orgquot; or whatever I want, and it works!/pBR pI had to stop using it though, because I was showing someone how to do it and then everyone was doing it in the office. Someone in IT figured it out and then HR got involved... my co-workers outed me as the one who had found the bug and I had to explain myself. The good news is now they don#39;t block security websites anymore - and the site is fixed :)/pBR p------/pBR pbWhoops!/b Killed 2 birds with one stone there, did he!/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/6KqSngyxXOw" height="1" width="1"/
April 27, 2010
7:39
Episode 23 - "Fuzzy Security"
» ‎ Following the White Rabbit Blog

pFrom the quot;too funny to be un-truequot; box... Thanks to the reader who sent this in!/pBR p------/pBR pA few years ago, a major home improvement retailer had an issue with their quot;strongMyAccount/strongquot; system wherein someone carefully looked at the URl and realized that they could simply increment the quot;AccountNumber=quot; field and they would get someone else#39;s information. This of course included their credit card details, shipping information, order details and such ...all pretty interesting if you#39;re going to steal someone#39;s information right? Well ... there is actually a better example than that of why emAccountNumber={number}/em is a bad idea without some sort of other factor for authentication./pBR pAbout 5 years ago I worked for a cable company here in the US, and they had (and probably still have) some pretty lax security practices. The web development department was no exception to the lax security rule so when I was asked to investigate an issue where (and this is how it was written up, I swear) quot;orders would magically cancel in the system, as if the customer cancelled themquot; I knew something was foul./pBR pThe first thing I noticed is that each day, at around the same time there was a large spike of web traffic, and seemingly at around the same time every order in the system would be quot;cancelled by the userquot;. Further investigation revealed that it was all done by a single IP address, based overseas somewhere. Odd, I thought, as I looked through logs and investigated the application. I looked at the application myself and then tried to place an order to see what would happen. Sure enough the next day at the same time my order was cancelled... and it#39;s not that it just disappeared - it was cancelled by emme/em according to the system. Funny - I wasn#39;t the one who cancelled it!/pBR pAs I was now convinced we were being hacked I took a deeper look at the traffic and set up a network-level packet capture for the time-frame which I was fairly certain would yield the cancelled orders the next day. Sure as snowflakes, the quot;attackquot; came and all the orders for the day were cancelled. I started investigating the packet captures and my eyes quickly saw a pattern. Someone would emlog in/em with a quot;dummyquot; account (one that was not tied to any legitimate account, just one that had been created to access the system) and then quickly do thousands upon thousands of POSTs with what appeared to be a valid quot;cancel orderquot; flag. Strangely, the only thing that was changing between POSTs was the quot;OrderNum=xxxxxxxxxxxxquot; parameter./pBR pApparently, after looking through the code, someone figured out that you really didn#39;t need to be logged in as anyone in particular, just logged into the emsystem itself/em so that it would talk to you. Then you could just craft quot;Cancel my orderquot; POST requests with an incrementing OrderNum emsince the system didn#39;t actually check that the OrderNum that you were cancelling was your own/em!/pBR pIt took us 2 weeks to figure this out ... 2 weeks = 10 days worth of orders that were cancelled ... I wonder how many customer we lost?/pBR pstrongWHOOPS!/strong/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/ktJahHSoUN0" height="1" width="1"/
April 26, 2010
23:25
Episode 22 - "Web Services ...Super-Secret"
» ‎ Following the White Rabbit Blog

pWhile speaking at a conference recently, talking about Flash and other client-side technologies and their associated pratfalls, someone in the audience raised their hand and volunteered another brilliant fail that needed to be written up.nbsp; Apparently this is on at least one very real, quite popular (according to the Google) website out there.../pBR pAs the gentleman explained it- quot;bWow, this website makes open-ended database calls!/bquot;/pBR pWhat that means is this... while quot;browsingquot; the site, the gentleman noticed that it was making interesting looking AJAX-type calls out to what appeared to be a web service through the Flash component. Like any good security-minded person he decided to investigate. Decompiling the Flash component and reading through the code he noticed that there were a series of bIF/b statements which basically defined the icorrect database/i to connect to. Once the database was selected the Flash component would then make quot;web servicesquot; calls out to a server to retrieve data. The interesting thing was that it passed all the parameters in the call ...in clear text HTTP. A piece of sample code pulled out revealed this type of call being made:/pBR preidataBaseQuery/i.ifetchResults/i(idbName, paramOne, paramTwo, maxResults/i)/preBR p...which wouldn#39;t be bad until you realize that the data on the other end was unfiltered. You were literally passing query parameters which were concatenated into an on-the-fly query string in Oracle and the data was returned straight-up again unfiltered./pBR pWhat could ipossibly go wrong/i? Well, the answer is you can actually enumerate iall the data in all 5 databases/i ... whether you should have access to the tables/rows or not./pBR pbWhoops!/b/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/nPH076Y8ipE" height="1" width="1"/
April 23, 2010
7:56
Episode 21 - "Back, Forward, Back, Forward"
» ‎ Following the White Rabbit Blog

pWelcome to Episode 21, and how time flies when you#39;re ...pointing out horrible developer mistakes.nbsp; A reader sent this in to me, and I re-wrote it in English (since it was originally submitted in Polish ...thank goodness I am fluent!).nbsp; Anyway, my Polish isn#39;t as good as it once was, but I hope I translated for you OK.nbsp; Thanks for sending in, and greetings to everyone back home in the motherland!/pBR p------/pBR pI was working for a small bank a time ago, which was trying to compete here in Poland for customers against the big national bank. To make new customers they had an idea of doing lots of business and transactions (like paying bills, transfer monies, etc) on the web. We were asked to test this application that was written in just 4 months, and with almost no specification by a developer group I had never seen before./pBR pThe first step for testing is always to browse the application, with good credentials and do good function exercises. I like to test the quot;Backquot; and quot;Forwardquot; button because sometimes developers forget that finance transactions are one-time things and should never be quot;accidentallyquot; repeated. I was not surprised when this showed the biggest ihack/i I could think of ...without really needing to break out any special hacking tools.nbsp; Here is what I found:/pBR olBR liAfter logging in and using the application I could click the quot;bLog Out/bquot; button, and then get redirected the the landing page. I then could click the bBack/b button on the browser to get back to the application and continue using it, just like I had never logged out!/liBR liI then found that if I completed a transaction (like a bill pay) I could click bBack/b and bForward/b on my browser and the transaction would happen again, and again, and again.../liBR liI also found that if I performed the transaction all the way through once (transferred money, for example) I could click bBack/b and go to the start of the transaction, then use the browser to go to the confirmation page and bdebit the TO account, without taking money from the FROM account!/b/liBR /olBR pThis was a crazy application, and the developers didn#39;t understand basic practice of writing code, OOPS right?/pBR pnbsp;/pBR pbWhoops indeed my friend, iWhoops!/i/bi indeed.../i/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/2lU3Q2pKeHk" height="1" width="1"/
April 22, 2010
7:57
Episode 20 - "Please Do Not Turn Off JavaScript"
» ‎ Following the White Rabbit Blog

pThe last 10 posts... I hope you#39;re enjoying reading them! As I sit at Logan airport and write this I head home from Source Boston which was an awesome con from the 1 day I had there ... I will definitely make sure I#39;m there again next year. Thanks to everyone who participated and came to our talk - it was great to have a full room!/pBR pNow, this next quot;iWhoops!/iquot; comes from the great land of misunderstanding. You#39;ve all seen quot;input validationquot; done on the client-side in JavaScript and chuckled - but I wonder if you#39;ve ever run across anything like this one. Somewhere along the path of enlightenment in web development these developers figured that everything that was worth doing - was worth doing on the client-side in JavaScript. Maybe it was the promise of off-loading work from the already-busy server to the client. Maybe it was the prospect of ... nevermind, I have no idea what they were thinking./pBR pAs a team I was working with was testing a particularly iinteresting/i application I decided that since I had time to kill I would tag along and observe. Not being able to participate was killing me - but it was still pretty fun to observe and suggest. One of the things I noticed one of the guys doing which I now do religiously is go to FireFox and iturn off JavaScript/i... then browse the site in scope. The other members of the team were busy spidering, injecting and testing the sign-on mechanism ... but this particular tester just turned off JavaScript and started browsing./pBR pNow, I#39;m always interested in seeing how other people think so I observed. I literally almost fell over in amazement at what happened next./pBR pLet me first explain that the first page we were given as a quot;targetquot; was inot/i the login page.nbsp; The first page was an administrative portal page which immediately (without any investigation) just redirected to login and then allowed continued browsing./pBR pHowever ...if you turned off JavaScript you got this error message at the top of the following page: quot;bPlease turn ON JavaScript, otherwise authentication will not work/bquot;.nbsp; Oh, and below that line was the admin page... apparently no credentials needed./pBR pApparently, iall the code/i for the redirect-to-login-page functionality happened ON THE CLIENT ... in JavaScript./pBR pnbsp;/pBR pbWhoops.../b/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/OA8q6wGLrKE" height="1" width="1"/
April 21, 2010
14:45
Episode 19 - "Password Reset, Please"
» ‎ Following the White Rabbit Blog

pHey there and welcome to another episode of quot;Whoops!quot; ...this one comes to us from an quot;anonymousquot; (in quotes, because ...who#39;s ireally/i anonymous on the Internet these days?) submitted who claims this quot;Whoops!quot; was real. Given what I#39;ve seen over the last several years, I#39;m inclined to believe him (or her).nbsp; Enjoy!/pBR p-----/pBR pBack in 2000 when the Internet boom was at its peak and everything was quot;moving to the webquot; the Acme Finance Co. was pushing their financial management platform to the web browser full steam ahead.nbsp; Having a few competitors to beat out, the coding was furious and the mistakes were many. On top of the architectural, procedural, and mathematical mistakes that were encountered was this gem. Apparently, after pushing the issue it was decided that the way this little ifeature/i worked was a calculated risk decision. ...and these people wanted to manage your financial assets?! Really?/pBR pAs Acme Finance Co. was ramping up its web presence and signing people up, the registration process was pretty simple (email address was login name, password was simple). Even though the passwords could be anything you wanted them to be (the thinking here was that complex passwords discouraged people from logging in... uhmm... yea) people still forgot their passwords. The thing is ... the quot;Forgot Passwordquot; functionality was insane. All you had to do was click the quot;Forgot Passwordquot; button and it would igive you the existing password/i ... in plain text./pBR pSee, apparently because of the demographic group they were dealing with (50+ investor, not very tech savvy) the risk analysis was weighed heavily on convenience, and very low on security. This wasn#39;t a huge risk since you had to iknow the email address/i of one of the valid logins. That is, until someone sent out an email quot;newsletterquot; with everyone#39;s email address in the CC: instead of the BCC: lines.nbsp; Now everyone had each other#39;s email addresses, and thus login names - and all hell broke loose./pBR pLet#39;s just say from what I understand that functionality was taken offline and replaced by a more quot;robustquot; system within 24 hours./pBR pbWHOOPS!/b/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/Xlkkr8f-sT0" height="1" width="1"/
April 20, 2010
2:37
Episode 18 - "Loyalty, Free"
» ‎ Following the White Rabbit Blog

pMy friend Tyler Reguly told me this one over dinner a while back and I#39;ve used it a few times to illustrate how logic issues within a site can cause chaos or cost you money.nbsp; Thinking over logic issues with applications is always fun - especially since there is no magic quot;scanning toolquot; that will uncover them. Heck, many logic flaws in applications are uncovered entirely by accident as there isn#39;t a way to test for the unknown, by definition./pBR pAnyway, these types of defects can be costly, as I#39;ve said, when someone uncovers one and exploits it for their own good.nbsp; In this case, the Discoverer of the defect was kind enough to let the vendor know to change their code.nbsp; Enjoy the read.../pBR p------/pBR pLiving in Toronto I hear is pretty exciting. As in most major cities, they have a take-out delivery service which has a website. If you#39;ve never utilized the services of one of these companies (and really, who out there hasn#39;t!) then I#39;ll explain how it works. If you want to get food from a nice restaurant (not fast food) but don#39;t want to go through all that hassle of getting out of your PJs, going down to the local restaurant, waiting, ordering and tipping ...you#39;re in luck. You just hit a website, pick where you want food from, place your order and it shows up on your doorstep delivered by a friendly (hopefully) delivery person! If you#39;re lucky, the place you order from has a loyalty program which allows you to get some sort of rewards for using their services repeatedly. Our story starts here./pBR pSitting home one night, possibly watching a movie, our accidental hacker decided that food was next on the needs list but that going out was not. Our hero pulls up a web page, picks a restaurant, clicks through his order and gets sent to the quot;Pay Nowquot; page. Here our hero attempts to use a credit card from memory since his was all the way over on the other side of the room in his wallet. Entering in the information, and noticing that his account had a copious amount of loyalty points he mused quot;I should use those next time for some free foodquot;. Clicking quot;Processquot; he notices that his credit card was rejected, probably because he didn#39;t guess his numbers correctly./pBR pInterestingly enough though, while the transaction failed, our hero noticed that his loyalty points were incremented ... just as if he had placed the order. Being a hacker by trade, our hero decides to give this a test drive. A few minutes of hunger later, he has a script which continually submits his (incorrect) credit card information on that same order. Clearly the first thing the site was lacking in was anti-automation - but secondly and even more importantly was this logic flaw that had just surfaced. Without actually placing a correct order, our hero is able to continue to rack up points... what to do./pBR pWell, being responsible, our hero contacts the vendor and explains the issue but first dinner needed to be placed. Luckily, the vendor was polite enough to offer our hero some additional loyalty points for being not only loyal, but honest./pBR pSo what happened? Clearly while the logic should have done the points addition iafter/i the order was successfully processed, the loyalty points were incremented ibefore/i the order was successfully completed.nbsp; Makes you wonder how many people quot;took advantage ofquot; these great loyalty points for free./pBR pibWHOOPS!/b/i/pimg src="http://feeds.feedburner.com/~r/RafalLos/~4/3_ZDXZvMgs8" height="1" width="1"/

← Random-Tech's piggfeed - General Scie... invisiblethings' blog →

Jean-Marc's infotainment stream » Following the White Rabbit Blog

Feeds

Following the White Rabbit Blog