Before: Arbitrator EvaStöwe (A), Respondent: CAcert (R), Claimant: Marcus M (C), Case: a20120522.1

History Log

Original Dispute

while testing today in the software telco we found out, that it is  possible to save executable code in the WebDB through the any input.  When opening a page with the executable code from the WebDB it is  executed. see details below:

Account with 2150 Points +CATS
[Testserver details of 1st account]
Account With 100 Assurances Points, 50 Experiens Points, CATS
[Testserver details of 2nd account]
Assurer With 100 Assurances Points, 50 Experiens Points, CATS

Assure Someone
https://cacert1.it-sls.de/wot.php?id=5

Name         9 autotest
DoB          1950-01-01 (JJJJ-MM-TT)
Location:<script type="text/javascript">alert("FAIL!");</script>
Date<script type="text/javascript">alert("FAIL!");</script>
Checkboxes    1 1 0
Punkte:<script type="text/javascript">alert("FAIL!");</script>

Msg:
"In Kürze werden Sie und die von Ihnen bestätigte Person eine E-Mail-Bestätigung erhalten. Es ist dafür von Ihrer Seite aus nichts weiter zu tun."
I accept CCA and DRP

EOT Private Part


Preliminary Considerations and Activities

After picking up the case some things were unclear:

  1. Was the bug solved?
  2. Was there a bug entered in the bugtracker?
  3. Why was a case about a security relevant bug that may be unsolved not picked up by arbitration?
  4. What does the claimant ask with the dispute?
  5. Should the case be sealed?

Was the bug solved?

The first step was to check if the bug could be reproduced. If it could be reproduced on the testserver it would also be open on the productive server.

Some tests by A and CM showed:

Bugtracker-Entry

The next step was a search for a bug entry for this bug in the bugtracker. Non was found.

Bug 1291 was entered. (Look there for more details about the bug and the tried exploits).

Why was the bug and the case not attended for over 2 years?

The bug was discovered in a software team session. It looks like the decision back then was to enter this dispute and to wait for arbitration to pick it up. Also it may be that the software team thought the bug to be fixed as it was not working for the old calculation (WoT10).

At the same time it looks like nobody of the arbitration team thought the case to be relevant enough to pick it up for two years. This may be because the dispute is quite technical and does not ask arbitration for anything to do. As the dispute was also filed out of a software session, maybe the arbitrators thought that the bug probably was treated so that there may no need to pick it up, soon.

Even if that would be the case, possible exploits may have been working based on the kind of the fix, so even this can be considered to be a little bit careless.

However the question why the case was not picked up for some time, is not the focus of this case, even if it is an important question. As this is obviously not covered by the dispute, the only action here was to inform the internal Auditor about the issue and to hope that he will follow this and find some advice how to prevent that other security relevant cases will stay unattended in the future.

Beside of this the teams can only be encouraged to install some kind of prioritisation system to ensure that security relevant issues are attended, soon.

Domain of the Dispute

The domain of the dispute was considered to be to ensure that the bug was fixed and to find possible exploits based on the bug.

Sealing of the case

At the time the case was picked up, the bug was open. It was not clear when it would been solved and how long it would take to ensure that there was no way to exploit it further.

Any sensible documentation of the case and especially intermediate rulings (which would have to be posted when there is no seal) would invite people to exploit the bug further and by this possibly harm other members.

Because of the possible attack the internal Auditor suggested to seal the case at least until the bug was fixed.

The Arbitrator decided to follow the advice of the internal Auditor and seal the case until it was ensured that the bug was fixed and possible exploits analysed.


Discovery

Security relevance of the bug

Because of the bug it was possible to enter anything into the location field of assurances. As long as it was possible to enter free texts into the date field of the assurance, the same seem to be true for that field.

By this is was possible to enter scripts into this fields. Those scripts would be executed every time the contents of the fields were displayed by the software.

A possible attacker could have tried to execute a script or to take over the session of someone else, for example a support engineer (by asking to take a look at the points based on some other complaint).

Bug fix

The bug is fixed, now.

1. Any entry in free fields gets escaped before entered in the DB. 1. Before any none-escaped entry is displayed it is escaped temporarly to prevent its execution.

Handling of possible exploits

Any relevant exploit of the bug would have contained a combination of "<" and later ">". As most browser allow to execute also scripts that are missing closing "</ ...>", they would not be needed for an exploit-attempt.

To find possible exploits a search for "<" followed by anything and ">" in the affected fields (location and date of assurances) was needed.

As a combination of both characters is seldom needed to describe a location and never needed to describe a date, the chance to hit false positives was considered to be relatively small.

The Arbitrator decided to search for possible exploits with two SQL-queries that would provide any assurance id and location/date entry for assurances with location/date entries that contain "<" and later ">".

While the location field is a sensible field regarding the privacy of our members, stand alone it does not reveal anything about any special member. The connection to the member would only be needed if an exploit would be found. This would require a second search in the case

The assurance id would be helpful to get an idea of time frames of any exploits (for both fields) is some were found. But it would not point to any member as any member can assure any member at any time and order.

As long as the identity of the assurer and the assuree is not looked up afterwards the privacy of the affected members would be kept as best as possible while searching for possible exploits.

The following SQL-query were approved and tested by two software assessors:

   1 SELECT `id`,`location`
   2 FROM `notary`
   3 WHERE `location` LIKE '%<%>%';
   4 
   5 SELECT `id`,`date`
   6 FROM `notary`
   7 WHERE `date` LIKE '%<%>%';

One alternative for the date was discussed but dismissed by the Arbitrator.

The execution of the queries (see Intermediate Ruling) provided 5 hits. All of them were classified as non-exploiting, uncritical false positives by the critical team lead and the Arbitrator and CM of this case.


Sealing history

While the seal was set, all communication was done encrypted and excluded from the archive (as it cannot handle encrypted mails). At the same time the internal Auditor was included in said communication as an additional pair of eyes to ensure correct handling of the case. (However the result-set of the queries was kept private between critical team, A and CM.)


Ruling

Intermediate Ruling

After applying the patch for bug #1291 with the normal procedures, Critical Team should execute the following two SQL-queries and send the results encrypted to the Arbitrator and Case Manager of a20120522.1:

   1 SELECT `id`,`location`
   2 FROM `notary`
   3 WHERE `location` LIKE '%<%>%';

and

   1 SELECT `id`,`date`
   2 FROM `notary`
   3 WHERE `date` LIKE '%<%>%';

As the patch for bug #1291 is currently not approved by software team the execution of this ruling has to wait until software team finishes their work on it.

-- In a train between Osnabrück and Bremen, 2014-08-04

Final Ruling

The bug reported in the dispute was found open. It is fixed now. A search for exploits was done. The bug was not exploited.

No harm was found, so no action against anybody is required.

One additional point has to be addressed: The bug was found during a software session but not covered with a bug-entry until the case was picked up by the Arbitrator. This was over two years after the bug was found.

The question remains why the case and the bug were not attended for so long. This question is not covered of the dispute so it should not be treated in this case. The internal Auditor was informed about it and may consider further actions.

Additionally software team and arbitration team should be advised to find ways to ensure that security relevant cases and bugs are treated without delay. Software team already categorises bugs for urgency. It would be a good idea to do so for arbitration cases, as well.

As the arbitration team probably was not aware of the security relevance and thus urgency, it would have been the duty of the claimant to ask the iCM or DRO for urgent treatment of the case. Any member who is aware of a security relevant issue has the duty to ensure that they are resolved (see SP 9.1.6.).

-- Cologne, 2014-08-09.

Execution

Similiar Cases

a20140422.1

Gather evidence about the SQL injection/ shell execution discovered in #1272

a20140322.1

Maybe lost information in the database

a20120614.1

Emergency Patch


Arbitrations/a20120522.1 (last edited 2014-08-09 16:45:34 by MartinGummi)