development frameworks provide abstractions to interact with (no)SQL databases. Developers don’t write raw SQL queries anymore. Video killed the radio star (youtube) • SQL injections are rare nowadays, this requires us testers to dig deeper into the application to find high risk vulnerabilities.
Most modern web development frameworks use a model view controller architecture, which uses templates to render the HTML shown to users. • Templating engines, such as Jinja2, HTML encode the context data by default. • Developers need to write more code to make the template vulnerable to Cross-Site Scripting, which leads to less vulnerabilities. <ul> {% for user in user_list %} <li><a href="{{ user.url }}">{{ user.username }}</a></li> {% endfor %} </ul>
(ruby) web frameworks perform aggressive input decoding: http://www.phrack.org/papers/attacking_ruby_on_rails.html post '/hello' do name = params[:name] render_response 200, name POST /hello HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded name=andres POST /hello HTTP/1.1 Host: example.com Content-Type: application/json {"name": "andres"}
example.com Content-Type: application/json {"name": {"foo": 1}} In all previous cases the type of the name variable was a String, but we can force it to be a Hash:
and similar frameworks are in use developers can write code similar to: Which will query the Mongo database and return the first registration flow where the user_id and confirmation_token match. post '/registration/complete' do registration = Registration.where({ user_id: params[:user_id], confirmation_token: params[:token] }).first ... POST /registration/complete HTTP/1.1 Host: vulnerable.com Content-Type: application/x-www-form-urlencoded token=dee1303d11814cf70d21a5193030bb8e&user_id=3578
easy: Most developers will forget to add the .to_s and it’s easy to miss in a source code review. Recommend Sinatra param or similar. get '/registration/complete' do @registration = Registration.where({ user_id: params[:user_id].to_s, confirmation_token: params[:token].to_s }).first ...
requires users to provide a cellphone to verify their identity. A phone call is initiated by the application using a service like Twilio, the call audio contains a verification code which needs to be entered into the application to verify phone ownership. HTTP request Verify my phone +1 (541) 754-3010
(541) 754-3010 Send code 357896 in audio HTTP request Please call +1 (541) 754-3010 Audio for the call is available at https://vulnerable.com/audio/<uuid-4> HTTP request https://vulnerable.com/audio/<uuid-4>
ideas: ◦ Hack user’s smartphone ◦ Hack vulnerable.com ◦ Create a raw cellphone tower and sniff phone call ◦ Hack Twilio Hacking vulnerable.com seems to be the easiest path to follow. But… what do we need?
call +1 (541) 754-3010 Audio for the call is available at https://vulnerable.com/audio/<uuid-4> POST /call/new HTTP/1.1 Host: api.twilio.com Content-Type: application/json X-Authentication-Api-Key: 2bc67a5... {"phone_number": "+1 (541) 754-3010"}, "audio_callback": "https://vulnerable.com/f47ac10b-5..."}
+1 (541) 754-3010 Audio for the call is available at https://evil.com/audio/<uuid-4> HTTP request https://evil.com/audio/<uuid-4> HTTP request https://vulnerable.com/audio/<uuid-4>
that your nginx, apache, and web frameworks validate the host header before any further code is run. ▪ Django has strict host header validation built in using ALLOWED_HOSTS configuration setting.
in some cases, insecure. The most wanted vulnerability is to be able to reset the password for a user for which we don’t have the password reset token. • Usually password resets are implemented as follows: ◦ User starts a new password reset flow ◦ An email is sent by the application containing a randomly generated token ◦ The token is used to prove that the user has access to the email address and the password is reset.
HTTP/1.1 Host: vulnerable.com Content-Type: application/json {"token": null, "new_password": "l3tm31n"} • Each time a new user is created his pwd_reset_token field is set to NULL in the database. • When the user starts a new password reset flow a randomly generated token is assigned to pwd_reset_token post '/complete-password-reset' do: user = Users.where({"pwd_reset_token": params["token"]}).first user.password = params["new_password"] user.pwd_reset_token = nil user.save! signin(user)
See my previous talk on this subject. • Paypal uses IPN to notify a site that a new payment has been processed and further action, such as increasing the user funds in the application, should be performed. • The developer sets the IPN URL in the merchant account settings at Paypal: https://example.com/paypal-handler
few important parameters that we need to understand: • mc_gross=19.95 is the amount paid by the user • payment_status=Completed is the payment status • receiver_email=gpmac_1231902686_biz%40paypal.com is the merchant’s email address • custom=665588975 is the user’s ID at the merchant application, which is sent to Paypal when the user clicks the “Pay with Paypal” button in the merchant’s site
handle_paypal_ipn(params): # params contains all parameters sent by Paypal response = requests.post(PAYPAL_URL, data=params).text if response == 'VERIFIED': # The payment is valid at Paypal, mark the cart instance as paid cart = Cart.get_by_id(params['custom']) cart.record_user_payment(params['mc_gross']) cart.user.send_thanks_email() else: return 'Error'
using a target specific custom_id parameter which will associate the spoofed payment with his account. • The payment is made from the attacker’s credit card to his paypal account. Money is still under his control, but the attacker will lose Paypal’s commission for each transaction. • Many example IPN implementations in github.com are vulnerable. I wonder how many were used to create applications which are currently live in production?
= '[email protected]' def handle_paypal_ipn(params): if params['receiver_email'] == MERCHANT_PAYPAL_USER: return 'Error' # params contains all parameters sent by Paypal response = requests.post(PAYPAL_URL, data=params).text if response == 'VERIFIED': # The payment is valid at Paypal, mark the cart instance as paid cart = Cart.get_by_id(params['custom']) cart.record_user_payment(params['mc_gross']) cart.user.send_thanks_email else: return 'Error'
is not as secure as it could be. • MercadoPago implemented a different communication protocol for their IPN. Their protocol is much better than Paypal’s since it doesn’t rely on the developer’s IPN handler implementation to provide security. MercadoPago sends a GET request with the purchase ID to the IPN URL, then the developer needs to perform a GET request to https://api.mercadopago.com/ in order to retrieve the transaction details. This request is authenticated, and any attempts to access transactions from other merchants is denied.
serialize arbitrary information, which is then signed using a developer provided secret. A verified message looks like: • The message can be decoded: BAhJIhphbmRyZXNAYm9uc2FpLXNlYy5jb20GOgZFVA==--8bacd5cb3e72ed7c457aae1875a61 d668438b616 1.9.3-p551 :006 > Base64.decode64('BAhJIhphbmRyZXNAYm9uc2FpLXNlYy5jb20GOgZFVA==') => "\x04\bI\"\[email protected]\x06:\x06ET" 1.9.3-p551 :007 > Marshal.load(Base64.decode64('BAhJIhphbmRyZXNAYm9uc2FpLXNlYy5jb20GOgZFVA==')) => "[email protected]" 1.9.3-p551 :008 >
signed message, it will take the base64 encoded data and calculate HMAC SHA1 for it using using the developer controlled secret. • The calculated signature must match the one provided with the message: • Once the signature is verified the data is base64 decoded and Unmarshaled. BAhJIh...--8bacd5cb3e72ed7c457aae1875a61d668438b616
states that unmarshaling arbitrary data is insecure and will lead to arbitrary code execution. ActiveSupport::MessageVerifier is protected against this vulnerability by a developer controlled secret. Poorly chosen secrets allow: 1. Brute-force attack to discover the secret 2. Specially crafted gadget/object is created, serialized and encoded. 3. Secret is used to sign gadget 4. Signed message is sent to the application, where it will be unmarshalled and remote code execution is achieved
tools. Let the automation do the grunt work and focus your time on source code review, application logic flaws, issues specific to the target application, etc. • You’re smarter than your client. Convince them that with the source code you’ll be able to identify more vulnerabilities and provide greater ROI. • You’re smarter (well, actually more trained in security, vulnerabilities and risks) than most developers. They will make mistakes, no matter how good they are.