This 30 day mission will help our researchers learn how isolation and close quarters affect individual and group behavior. This study at our Johnson Space Center prepares us for long duration
space missions, like a trip to an asteroid or even to Mars.
The Human Research Exploration Analog (HERA) that the crew members will be living in is one compact, science-making house. But
unlike in a normal house, these inhabitants won’t go outside for 30 days. Their communication with the rest of planet Earth will also be very limited, and they won’t have any access to
internet. So no checking social media kids!
The only people they will talk with regularly are mission control and each other.
The crew member selection process is based on a number of criteria, including the same criteria for astronaut selection.
What will they be doing?
Because this mission simulates a 715-day journey to a Near-Earth asteroid, the four crew members will complete activities similar to what would happen during an outbound transit, on location at
the asteroid, and the return transit phases of a mission (just in a bit of an accelerated timeframe). This simulation means that even when communicating with mission control, there will be a
delay on all communications ranging from 1 to 10 minutes each way. The crew will also perform virtual spacewalk missions once they reach their destination, where they will inspect the asteroid
and collect samples from it.
A few other details:
The crew follows a timeline that is similar to one used for the ISS crew.
They work 16 hours a day, Monday through Friday. This includes time for daily planning, conferences, meals and exercises.
They will be growing and taking care of plants and brine shrimp, which they will analyze and document.
But beware! While we do all we can to avoid crises during missions, crews need to be able to respond in the event of an emergency. The HERA crew will conduct a couple of emergency scenario
simulations, including one that will require them to maneuver through a debris field during the Earth-bound phase of the mission.
Throughout the mission, researchers will gather information about cohabitation, teamwork, team cohesion, mood, performance and overall well-being. The crew members will be tracked by numerous
devices that each capture different types of data.
Past HERA crew members wore a sensor that recorded heart rate, distance, motion and sound intensity. When crew members were
working together, the sensor would also record their proximity as well, helping investigators learn about team cohesion.
Researchers also learned about how crew members react to stress by recording and analyzing verbal interactions and by analyzing “markers” in blood and saliva samples.
In total, this mission will include 19 individual investigations across key human research elements. From psychological to physiological experiments, the crew members will help prepare us for
future missions.
This 30 day mission will help our researchers learn how isolation and close quarters affect individual and group behavior. This study at our Johnson Space Center prepares us for long duration
space missions, like a trip to an asteroid or even to Mars.
The Human Research Exploration Analog (HERA) that the crew members will be living in is one compact, science-making house. But
unlike in a normal house, these inhabitants won’t go outside for 30 days. Their communication with the rest of planet Earth will also be very limited, and they won’t have any access to
internet. So no checking social media kids!
The only people they will talk with regularly are mission control and each other.
The crew member selection process is based on a number of criteria, including the same criteria for astronaut selection.
What will they be doing?
Because this mission simulates a 715-day journey to a Near-Earth asteroid, the four crew members will complete activities similar to what would happen during an outbound transit, on location at
the asteroid, and the return transit phases of a mission (just in a bit of an accelerated timeframe). This simulation means that even when communicating with mission control, there will be a
delay on all communications ranging from 1 to 10 minutes each way. The crew will also perform virtual spacewalk missions once they reach their destination, where they will inspect the asteroid
and collect samples from it.
A few other details:
The crew follows a timeline that is similar to one used for the ISS crew.
They work 16 hours a day, Monday through Friday. This includes time for daily planning, conferences, meals and exercises.
They will be growing and taking care of plants and brine shrimp, which they will analyze and document.
But beware! While we do all we can to avoid crises during missions, crews need to be able to respond in the event of an emergency. The HERA crew will conduct a couple of emergency scenario
simulations, including one that will require them to maneuver through a debris field during the Earth-bound phase of the mission.
Throughout the mission, researchers will gather information about cohabitation, teamwork, team cohesion, mood, performance and overall well-being. The crew members will be tracked by numerous
devices that each capture different types of data.
Past HERA crew members wore a sensor that recorded heart rate, distance, motion and sound intensity. When crew members were
working together, the sensor would also record their proximity as well, helping investigators learn about team cohesion.
Researchers also learned about how crew members react to stress by recording and analyzing verbal interactions and by analyzing “markers” in blood and saliva samples.
In total, this mission will include 19 individual investigations across key human research elements. From psychological to physiological experiments, the crew members will help prepare us for
future missions.
WARNING: THIS POST CONTAINS RIDICULOUS STRIP SEARCH SPOILERS
So I lost. Wah, boohoo, etc etc. It doesn’t mean I’m going to give up. I love The Last Halloween. If you also loved The Last Halloween, don’t worry, it’s happening. But first I have to
Kickstart it! The Kickstarter goes up within the next few days, and I hope you guys will fund it, if you’ll have me.
I’ll do a much larger post when the Kickstarter kickstarts so you’ll all know my feelings and how great everything is and how much you will be into backing it.
I’m one of these guys being sshhhhhsh’ed. Abby had the best comics on Strip Search and so for my continued entertainment I shall help kickstart!
Level 8 of the Stripe CTF is a password server that returns success: true if and only if the password provided matches the password stored directly via
a RESTful API and optionally indirectly via a callback URI. The solution is side channel attack like a timing attack but with ports instead of time.
(I found this in my drafts folder and had intended to post a while ago.)
Code
def nextServerCallback(self, data): parsed_data = json.loads(data) # Chunk was wrong! if not parsed_data['success']: # Defend against timing attacks remaining_time = self.expectedRemainingTime() self.log_info('Going to wait %s seconds before responding' % remaining_time) reactor.callLater(remaining_time, self.sendResult, False) return
self.checkNext()
Issue
The password server breaks the target password into four pieces and stores each on a different server. When a password request is sent to the main server it makes requests to the sub-servers
for each part of the password request. It does this in series and if any part fails, then it stops midway through. Password requests may also be made with corresponding URI callbacks and after the
server decides on the password makes an HTTP request on the provided URI callbacks saying if the password was success: true or false.
A timing attack looks at how long it took for a password to be rejected and longer times could mean a longer prefix of the password was correct allowing for a directed brute force attack. Timing
attacks are prevented in this case by code on the password server that attempts to wait the same amount of time, even if the first sub-server responds with false. However, the server uses
sequential outgoing port numbers shared between the requests to the sub-servers and the callback URIs. Accordingly, we can examine the port numbers on our callback URIs to direct a brute force
attack.
If the password provided is totally incorrect then the password server will contact one sub-server and then your callback URI. So if you see the remote server's port number go up by two when
requesting your callback URI, you know the password is totally incorrect. If by three then you know the first fourth of the password is correct and the rest is incorrect. If by four then two
fourths of the password is correct. If by five then four sub-servers were contacted so you need to rely on the actual content of the callback URI request of 'success: true' or 'false' since you
can't tell from the port change if the password was totally correct or not.
The trick in the real world is false positives. The port numbers are sequential over the system, so if the password server is the only thing making outgoing requests then its port numbers will also
be sequential, however other things on the system can interrupt this. This means that the password server could contact three sub-servers and normally you'd see the port number increase by four,
but really it could increase by four or more because of other things running on the system. To counteract this I ran in cycles: brute forcing the first fourth of the password and removing any entry
that gets a two port increase and keeping all others. Eventually I could remove all but the correct first fourth of the password. And so on for the next parts of the password.
I wrote my app to brute force this in Python. This was my first time writing Python code so it is not pretty.
Level 5 of the Stripe CTF revolved around a design issue in an OpenID like protocol.
Code
def authenticated?(body) body =~ /[^\w]AUTHENTICATED[^\w]*$/ end
...
if authenticated?(body) session[:auth_user] = username session[:auth_host] = host return "Remote server responded with: #{body}." \ " Authenticated as #{username}@#{host}!"
Issue
This level is an implementation of a federated identity protocol. You give it an endpoint URI and a username and password, it posts the username and password to the endpoint URI, and if the
response is 'AUTHENTICATED' then access is allowed. It is easy to be authenticated on a server you control, but this level requires you to authenticate from the server running the level. This
level only talks to stripe CTF servers so the first step is to upload a document to the level 2 server containing the text 'AUTHENTICATED' and we
can now authenticate on a level 2 server. Notice that the level 5 server will dump out the content of the endpoint URI and that the regexp it uses to detect the text 'AUTHENTICATED' can match on
that dump. Accordingly I uploaded an authenticated file to
Navigating
to that URI results in the level 5 server telling me I'm authenticated as level 2 and lists the text of the level 2 file 'AUTHENTICATED'. Feeding this back into the level 5 server as my endpoint
URI means level 5 seeing 'AUTHENTICATED' coming back from a level 5 URI.
Notes
I didn't see any particular code review red flags, really the issue here is that the regular expression testing for 'AUTHENTICATED' is too permisive and the protocol itself doesn't do enough. The
protocol requires only a set piece of common literal text to be returned which makes it easy for a server to accidentally fall into authenticating. Having the endpoint URI have to return variable
text based on the input would make it much harder for a server to accidentally authenticate.
<%= user[:username] %>
(password: <%= user[:password] %>, last active <%= last_active %>)
Issue
The level 4 web application lets you transfer karma to another user and in doing so you are also forced to expose your password to that user. The main user page displays a list of users who
have transfered karma to you along with their password. The password is not HTML encoded so we can inject HTML into that user's browser. For instance, we could create an account with the
following HTML as the password which will result in XSS with that HTML:
This HTML runs script that uses jQuery to post to the transfer URI resulting in a transfer of karma from the attacked user to the attacker user, and also the attacked user's
password.
Notes
Code review red flags in this case included lack of encoding when using user controlled content to create HTML content, storing passwords in plain text in the database, and displaying passwords
generally. By design the web app shows users passwords which is a very bad idea.
Level 6
Code
...
def self.safe_insert(table, key_values) key_values.each do |key, value| # Just in case people try to exfiltrate # level07-password-holder's password if value.kind_of?(String) && (value.include?('"') || value.include?("'")) raise "Value has unsafe characters" end end
conn[table].insert(key_values) end
Issue
This web app does a much better job than the level 4 app with HTML injection. They use encoding whenever creating HTML using user controlled data, however they don't use encoding when injecting
JSON data into script (see post_data initialization above). This JSON data is the last five most recent messages sent on the app so we get to inject script directly. However, the system also
ensures that no strings we write contains single or double quotes so we can't get out of the string in the JSON data directly. As it turns out, HTML lets you jump out of a script block using no
matter where you are in script. For instance, in the middle of a value in some JSON data we can jump out of script. But we still want to run script, so we can jump right back in. So the frame
so far for the message we're going to post is the following:
$filename = 'secret-combination.txt'; extract($_GET); if (isset($attempt)) { $combination = trim(file_get_contents($filename)); if ($attempt === $combination) {
Issue
The issue here is the usage of the extract php method which extracts name value pairs from the map input parameter and creates corresponding local variables. However this code uses $_GET which contains a map of name value pairs passed in the query of the URI. The expected behavior is to get an attempt variable out, but since no input validation is done I can provide a filename variable and overwrite the value of $filename. Providing an empty string gives an empty string $combination which I can match with an empty string $attempt. So without knowing the combination I can get past the combination check.
Notes
Code review red flag in this case was the direct use of $_GET with no validation. Instead of using extract the developer could try to extract specifically the attempt variable manually without using extract.
This code accepts POST uploads of images but with no validation to ensure it is not an arbitrary file. And even though it uses chmod to ensure the file is not executable, things like PHP don't require a file to be executable in order to run them. Accordingly, one can upload a PHP script, then navigate to that script to run it. My PHP script dumped out the contents of the file we're interested in for this level:
Notes
Code review red flags include manual file management, chmod, and use of file and filename inputs without any kind of validation. If this code controlled the filename and ensured that the
extension was one of a set of image extensions, this would solve this issue. Due to browser mime sniffing its additionally a good idea to serve a content-type that starts with "image/" for these
uploads to ensure browsers treat these as images and not sniff for script or HTML.
app.get('/*', function(req, res) { var namespace = req.param('namespace');
if (namespace) { var query = 'SELECT * FROM secrets WHERE key LIKE ? || ".%"'; db.all(query, namespace, function(err, secrets) {
Issue
There's no input validation on the namespace parameter and it is injected into the SQL query with no encoding applied. This means you can use the '%' character as the namespace which is the
wildcard character matching all secrets.
Notes
Code review red flag was using strings to query the database. Additional levels made this harder to exploit by using an API with objects to construct a query rather than strings and by running a
query that only returned a single row, only ran a single command, and didn't just dump out the results of the query to the caller.
query = """SELECT id, password_hash, salt FROM users WHERE username = '{0}' LIMIT 1""".format(username) cursor.execute(query)
res = cursor.fetchone() if not res: return "There's no such user {0}!\n".format(username) user_id, password_hash, salt = res
calculated_hash = hashlib.sha256(password + salt) if calculated_hash.hexdigest() != password_hash: return "That's not the password for {0}!\n".format(username)
Issue
There's little input validation on username before it is used to constrcut a SQL query. There's no encoding applied when constructing the SQL query string which is used to, given a username,
produce the hashed password and the associated salt. Accordingly one can make username a part of a SQL query command which ensures the original select returns nothing and provide a new SELECT via
a UNION that returns some literal values for the hash and salt. For instance the following in blue is the query template and the red is the username injected SQL code:
SELECT id, password_hash, salt FROM users WHERE username = 'doesntexist' UNION SELECT id, ('5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8') AS password_hash, ('word') AS salt FROM users WHERE username = 'bob' LIMIT 1
In the above I've supplied my own salt and hash such that my salt (word) plus my password (pass) hashed produce the hash I provided above. Accordingly, by
providing the above long and interesting looking username and password as 'pass' I can login as any user.
Notes
Code review red flag is again using strings to query the database. Although this level was made more difficult by using an API that returns only a single row and by using the execute method which
only runs one command. I was forced to (as a SQL noob) learn the syntax of SELECT in order to figure out UNION and how to return my own literal
values.
I was the 546th person to complete Stripe's web security CTF and again had a ton of fun applying my theoretical knowledge of web security
issues to the (semi-)real world. As I went through the levels I thought about what red flags jumped out at me (or should have) that I could apply to future code reviews:
Level
Issue
Code Review Red Flags
0
Simple SQL injection
No encoding when constructing SQL command strings. Constructing SQL command strings instead of SQL API
1
extract($_GET);
No input validation.
2
Arbitrary PHP execution
No input validation. Allow file uploads. File permissions modification.
3
Advanced SQL injection
Constructing SQL command strings instead of SQL API.
4
HTML injection, XSS and CSRF
No encoding when constructing HTML. No CSRF counter measures. Passwords stored in plain text. Password displayed on site.
5
Pingback server doesn't need to opt-in
n/a - By design protocol issue.
6
Script injection and XSS
No encoding while constructing script. Deny list (of dangerous characters). Passwords stored in plain text. Password displayed on site.
Stripe is running a web security capture the flag - a series of increasingly difficult web security exploit challenges. I've finished it and had a lot of fun. Working on a web browser I knew the theory of these various web based attacks, but this was my first chance
to put theory into practice with:
No adverse consequences
Knowledge that there is a fun security exploit to find
Access to the server side source code
Here's a blog post on the CTF behind the scenes setup which has many impressive features including
phantom users that can be XSS/CSRF'ed.
I'll have another post on my difficulties and answers for the CTF levels after the contest is over on Wed, but if you're looking for hints, try out the CTF chatroom or the level specific CTF chatroom.
2010 Jul 5, 4:23Cross-site scripting attack on YouTube over the weekend: "That turned out to be as simple as using two script tags in a row (<script><script>fun scripting stuff goes here!), as noted by
F-Secure researcher Mikko H. Hypponen on Twitter—the first of the two tags would get stripped, and the second was allowed through."technicalyoutubesecuritycross-site-scriptingjavascript
Sarah and I are just back from a successful wedding planning trip to California. We now have cake, food, officiant, makeup, and some other things. Planning weddings is tough. It was also, of
course, a pleasure to see my parents who made home made pasta -- yum!
2010 Mar 5, 2:54LiveJournal replaces affiliate links with their own... Between this and not being able to stick in videos, script, etc maybe its time to switch blogging sites...bloglivejournaltechnical
2010 Feb 22, 3:13On the Griffith OBservatory and the history of Mr. Griffith: "Today a splendid statue of Mr. Griffith stands in the park named after him. In one hand he is not holding a pistol, and in the other hand
he is not holding a bottle of whiskey."humorgriffith-observatorylacaliforniatripdestination
Sarah and I just got back home from a Eric and Jane's wedding / Sarah and Dave's vacation trip to the Bahamas (note the lack of activity for the past twelve days on my website). I've got plenty of
photos and things to post but for now I'll just relate this humorous anecdote during the rehearsal dinner. I had said something about photos to Jim, Eric's brother and he gave me a crazy look. "Oh,
I thought you meant like pho-tos" he said. It took me a moment to realize he misunderstood what I said as "faux toes". I laughed until I cried a little. Also works with digital faux toes.
2009 Sep 11, 8:39"In the W3C Media Fragment Working Group (MFWG) we have had long discussions about the use of the URI query (”?”) or the URI fragment (”#”) addressing approach for addressing directly into media
fragments, and the diverse new HTTP headers required to serve such URI requests, considering such side conditions as the stripping-off of fragment parameters from a URI by Web browsers, or the
existence of caching Web proxies."fragmenturivia:connollymediaurlqueryhttphttp-header
2009 Aug 5, 7:22Weird Al relates the awesome exploits of Charles Nelson Reilly in the style of the White Stripes. Notice the head of Chuck Norris mounted on CNR's trophy wall at 0:55s.humorvideoweird-alcharles-nelson-reillymusicmusic-video