Credits

John
Github: https://github.com/johnjhacking

Robert Willis:
Twitter: https://twitter.com/rej_ex

Identification

The Wedding websites that can be created with The Knot have many components built in. Among some of the functions included the ability to send out RSVP invites to friends or family. The websites that utilize RSVP can easily be identified:

inurl:"theknot.com" intext:"rsvp-link"

When you click on the ‘RSVP’ tab of the web applications, the only piece of data that it asks for is a first and last name. It seemed problematic, but putting in a wrong name returned error messages in ‘most’ cases - so unexploitable right? What happens when you use OSINT to identify a legitimate guest?

Turns out - the Web Application actually puts the first and last name of the bride and groom in the URL. Names might not be enough to enumerate guests of the wedding, fortunately for bad actors, the wedding location is usually disclosed on the homepage of the Wedding Site:

If that’s not enough, reverse image searching the photos that the couple upload to the site is more than adequate means of identifying their location in conjunction with other information that they provide. Social media, etc, then becomes your best friend. It’s trivial as you can typically enumerate who these individuals interact with and the name of their family members.

Exploitation

At this point, accessing RSVP invites is easy. I entered the first and last name of a suspected guest:

After clicking on the button, I had access to the invitation - unrestricted:

The ability to decline the invitation was now available. In addition, I was able to see the +1 or additional guests that the invitee had entered on their RSVP responses. I can now accept RSVPs of Wedding attendees that aren’t actually going, or decline invitations of attendees that want to attend:

[Note: I did not actually decline the invitation, I changed it back]

That’s fun. What else can we do?

I can now modify the meal preference of guests. I can’t help but think about the sheer chaos if someone changed all of the meal preferences of the guests prior to the Wedding. I also noted the ability to access notes:

While accessing notes is of less impact, it’s impossible to say what we would find if we looked at all of the notes for each guest in attendance. After I pressed continue, I noticed that I could modify the RSVP confirmations:

Being able to modify the confirmation isn’t all that problematic on the surface, however, there’s a possibility that the bride and groom may send out updates or other information. If the confirmation is modified, my assumption (untested) would be that the bad actor would receive the updates. Nonetheless, the bigger concern is that part of the email/phone number is revealed within this part of the RSVP. Knowing the person’s full name, enumerating the censored portion of the email or phone number might be plausible.

More Vulnerable Business Logic

I asked Robert Willis to lend me a hand in seeing if there was anything else that could be done.

Rob identified interesting Access Control issues. As I stated before, a threat actor would need to obtain the first and last name of a guest. In some instances - the Wedding RSVP website might suffer from further misconfiguration issues. Rob noticed that some of the RSVP websites allowed the ability to search guests, just by entering a first name or a last name only:

Thinking about the logic of this vulnerability, you can literally enter the bride or groom’s last name, and pull up heaps of attendees. The above picture shows “8” guests. However, one of the above guests had 4 additional guests on their RSVP. You could imagine how problematic this would be, especially for extended families. If someone wanted to enumerate a ton of guests, they could intercept the search function with Burp Suite and use Intruder with a custom wordlist of first names, or last names and effectively end up with a full list of guests and the ability to access their RSVPs.

But wait! There’s more!

In that above photo you may have noticed the “None of the above. Add me please!” option. Rob then observed that he had the ability to add guests to the Wedding:

Evaluating Impact

We noticed that many of RSVP sites had a wide variety of information. For example, some of the invites didn’t ask for a guest’s meal choice, but instead asked if they were bringing children, if they had allergies, etc. Obviously this isn’t good, so we decided to make our own Wedding website in an attempt to enumerate all available questions and forms associated with the RSVPs. What we found was a bit alarming:

In total, there were 8 ‘recommended’ questions/response forms.

1. What’s your meal preference?
2. Do you have any dietary restrictions?
3. Will you need transportation to our Wedding Day?
4. Do you have any song requests?
5. Leave us a note!
6. Just for fun, what’s the best piece of marriage advice you’ve heard?
7. When will you and your party arrive?
8. Will you be bringing any children under the age of 10?

But the most concerning field of all: “Create Custom Question”

Essentially, there’s no telling what level of information can be exposed via this business logic flaw. The worst part: these access control issues are baked into the application.

Well…surely there must be an option to restrict this, right?

Yes, and no. Fortunately, the bride and the groom have the ability to restrict people from adding themselves to the system if they are not invited. It appears that The Knot also warns the bride and groom about enabling public RSVP options.

Translation: The only option that can be disabled is the ability to add yourself as a guest, as demonstrated above. There’s no option to restrict people from accessing RSVP invites of people that are invited to the wedding. A major access control based vulnerability.

Notice the last option in the access control settings: “Guest List Visibility”.

A threat actor may not even have to go through the process of enumerating all of the guests if this option is enabled. Having access to one person’s RSVP would allow them to see anyone in attendance, thus, enabling the ability to access any of those guest’s Wedding invitations. Yikes.

For the most part, we didn’t observe the ability to access the entire guest list through this method in the wild - but we obviously refrained from testing this as we would have to actually tamper with the RSVPs, which we avoided doing.

Impact Recap

In total, we observed many variations of this setup and noted this as a baseline:

1. Ability to enumerate guests by using a first and last name (default)
2. Modify RSVP status (default)
3. Modify RSVP notification settings (default)
4. Ability to enumerate guest by using a first OR last name (limited)
5. Ability to add uninvited guests (limited - it’s a feature lol)
6. Access to sensitive information (depends on questions/forms implemented)
7. Modify meal preferences or other response based questions (default)