Top Failed Bots

During a presentation the other day to the Charlotte ALT.NET group,  I made a joke that Rock, Paper, Azure is doing something completely ridiculous: we invite people to write code and we’ll run it arbitrarily.  (Well, not really arbitrarily, but it does present a unique security challenge.)

We’ve naturally had a few interesting submissions, so I’m posting some of them here for interest sake.

First up:

 Thread.Sleep(...);

 

We see this one fairly often.  In a game where you have very limited time, I’m puzzled why some people would intentionally sleep their bots.

 

Next – this one is fairly innocent:

    1: if (dataset.Tables.Contains(opponent.TeamName))
    2: {
    3:      DataTable table = dataset.Tables[opponent.TeamName];
    4:      table.Rows.Clear();
    5:      foreach (Round round in rounds)
    6:      {
    7:     ...

… but in a short run game like this, I’d steer away from datasets.  (Plus, we have LINQ!)  This one gets caught in the filter not because it poses a specific threat, but we don’t allow anything from System.Data.

Third:

    1: try
    2: {
    3:       StreamWriter writer = new StreamWriter(@"C:\RPSLog.txt", append);
    4:       writer.Write(builder);
    5:       writer.Close();
    6: }
    7: catch (Exception)
    8: {
    9: }

WOW a lot of people are trying to write text files.  Not allowed.

And now for my all time favorite … an obvious hack attempt:

    1: StringBuilder builder = new StringBuilder();
    2: using (SqlConnection connection = new SqlConnection(ConfigurationManager.
    3:     ConnectionStrings[0].ConnectionString))
    4: {
    5:      using (SqlCommand command = new SqlCommand("SELECT * FROM sys.Tables", connection))
    6:      {
    7:          SqlDataReader reader = command.ExecuteReader();
    8:          while (reader.Read())
    9:          {
   10:              builder.Append(reader["[name]"]);
   11:              builder.Append(",");
   12:          }
   13:      }
   14: }
   15: you.Log.AppendLine("Here: " + builder);

This last one actually raises a legitimate issue and security threat – so much so that we can ban players (or worse) for this kind of thing.  Still, though, not much of a threat:  the code can’t get through, but even if it could, connection strings aren’t available to the app domain running the round, and even so, the engine only has execute permissions on the procedures necessary to insert the results.

I’m curious to see what else comes through!