Last year, my church signed up for echurch, a service provided by Pushpay which calls itself a “mobile engagement system”. Essentially, echurch creates a custom mobile app for each of its customers by applying the church’s branding to a generic app, which provides features such as a Bible viewer, announcements feed, podcast player, Pushpay donation link, and prayer request form. A quick search in the Google Play Store reveals at least 245 of these apps available on Android, their screenshots showing layouts and features that become very familiar after you’ve looked at a few. I took some time to do some basic security testing of my church’s app, and this post details my findings.

Non-technical summary

My main finding from my testing was somewhat worrying: messages sent using the Contact Card and Prayer Request forms in the app are not encrypted before being sent over the network. This means that any party which can intercept a user’s message can read it, even if they are not the intended recipient. In practical terms, this could be a problem if, for example, a user is connected to a public WiFi hotspot (in a coffee shop or even a church venue, for example), and someone else connected to that network is using a program such as Wireshark to watch the activity of other users. Unlike most modern apps, like (I hope) your email client or online banking site, echurch apps do not use encryption to “scramble” any messages that are being sent, leaving them vulnerable to this type of attack.

I informed Pushpay about the issue, giving a “responsible disclosure” deadline of six months for them fix it. They responded quickly, and told me that a fix would be deployed with an updated version of their platform. Unfortunately that update has not been released before the disclosure deadline, and the apps that I have tested are still vulnerable. Pushpay asked me to include the following message with this article:

We want to clarify that the issue is isolated to our echurch apps 2.0 platform and is not present in any other area of our product, most importantly, the Pushpay giving solution. In addition, we are able to resolve the concern with the echurch apps 2.0 platform in our newest platform, echurch apps 4.0. In the coming months, our Customer Success team will be reaching out to our customers to coordinate migrating them to this new platform.

We understand that this does not resolve the concern immediately, however, we do have a temporary recommendation to ensure any potentially affected information remains secure. With the 2.0 platform, churches are able to move their forms to an external web view. There are many excellent web-based form solutions that integrate well with our 2.0 apps platform, such as Google Forms, Wufoo Forms, and FormStack.

We have created a help article to walk churches through setting up web forms and they can contact us to request a link to the article. [Update 2017-12-11: Pushpay have since published the article and I have added the link.]

If you have any further questions or concerns, please let us know.

Mitigation

If you’re a user of a church app, you can check whether you’re affected by looking at the app in your phone’s store (normally the Google Play Store on Android, or the App Store on iPhones and iPads). If it says that your church’s app is published by “eChurch App”, any contact functions in that app are probably not encrypted, and therefore vulnerable to being intercepted. I recommend using a different method of communication, such as email, instead.

If you’re a church administrator, I advise following Pushpay’s recommendation above to use a web-based form solution such as Google Forms, Wufoo, or FormStack until echurch apps 4.0 is released. There is now a thorough help article on how to set this up on the echurch website.

Technical information and reproduction steps

I discovered the issue using Burp Suite Community Edition, an intercepting proxy, to view the traffic being sent and received by an Android device. See the PortSwigger website for instructions on setting up Burp Suite with an Android device. No certificate set-up is required, as the traffic we’re interested in doesn’t use SSL.

With Burp Suite set up, launch the echurch app you are interested in. It will make a number of HTTP requests to an app-specific subdomain of goodbarber.com, which returns data to be displayed in the app, encoded as JSON or in base 64. GoodBarber is an online service for creating native and Web applications, which echurch appears to be using. We’re not interested in the start-up requests right now.

Navigate to the app’s contact functionality, which is often split into Contact Card and Prayer Request forms. Enter some data into one of these forms, and make sure Burp’s proxy is set to intercept, so that we can drop the request before it’s properly sent. Touch “Send” on the form.

The Intercept tab in Burp should turn orange, and show the HTTP request being sent by the app. The request is form-encoded data, and the text entered into the Prayer Request form fields is clearly visible, without encryption. (Click “Drop” to prevent an actual request being sent to the church.)

Out of four echurch apps that I tested in this manner, three were vulnerable. The fourth was not vulnerable because its contact features were disabled.

Timeline

6th June 2017: I disclosed the issue to security@pushpay.com, and set a responsible disclosure deadline of 7th December 2017.

14th June 2017: Pushpay reported that they had successfully reproduced the issue, and were in talks with an upstream provider about the service.

10th September 2017: I contacted Pushpay again, as the deadline was less than three months away.

27th September 2017: Pushpay contacted my church’s director of operations and informed her that they would be upgrading our app to version 3.0 of their platform, which uses HTTPS to encrypt data entered in forms. They did not mention a migration plan for other echurch apps. The support ticket was marked as resolved, but I requested that it be kept open until the update was released.

22nd November 2017: Pushpay asked if the issue had been resolved to my satisfaction.

27th November 2017: I tested the app again, found the vulnerability still present, and so responded that it had not been resolved. I also clarified that I considered other churches’ apps to be within the scope of the issue.

5th December 2017: I sent a draft of this article to Pushpay for comment.

7th December 2017: Pushpay sent me the statement included in the Non-technical summary section.

8th December 2017: The disclosure deadline passed, and I published this article.

11th December 2017: Article updated with the link to the echurch help article.