1:34 Hello. Hello.
1:37 Hello.
8:52 What
9:22 >> Hello.
9:24 Yeah, it's working. [Music]
9:50 >> Hello.
9:53 Okay, perfect. It's working. Uh I think
9:55 we can start. Hi everyone. We have
9:57 people online. We have people here in
10:02 person. Um uh my name is N. Uh I am the
10:07 coach for the CTF and uh also uh I am a
10:09 vertra employee as a director of
10:12 emerging tech uh innovation and
10:14 architecture. Today I'm going uh just to
10:16 give you an introduction about our
10:20 session that it will be uh hosted by our
10:22 uh lead application engineer Muhammad
10:26 Abuadura and Wad our QA uh senior uh
10:28 senior QA engineer. So today's session
10:31 it will be about break it like a tester
10:34 where it will be uh representing some
10:38 tactics that the QA tester uh use it um
10:43 dur to do some security finding and it
10:46 will follow up by uh a live demo session
10:50 uh with for with our uh lead application
10:53 Muhammad Abu Kadura representing um and
10:56 how he how he solved an issue on a
11:00 native mobile uh that it was found by
11:03 man in the middle attack using uh some
11:06 techniques and uh between nanoflows and
11:08 micrflows. So welcome everyone. I hope
11:11 you will enjoy the session and and good
11:15 luck with that challenges. Thank you.
11:23 Hey everyone, it's lovely to have you
11:25 all here today and whoever watching us
11:27 on the stream. Hello, good morning, good
11:29 afternoon. Uh, I would like to kick off
11:31 this session with a quick introduction
11:34 about myself. Uh, my name is Watiat. I'm
11:36 a certified senior quality assurance
11:39 engineer with extensive experience in in
11:41 functional and nonfunctional testing. My
11:43 main focus is identifying weaknesses,
11:46 bottlenecks, and edge cases which might
11:49 impact our systems and end users.
11:52 While I'm not a while I'm not a cyber
11:54 security specialist, I bring the
11:56 perspective of a professional QA who is
11:58 trained to think critically about systems
11:59 systems
12:02 not only in the way of does it work and
12:05 also uh if it might fail and what's the
12:08 impact of that failure. So today we'll
12:12 be focusing on um So today we'll be
12:14 focusing on how to use our skills as a
12:19 QA in finding vulnerabilities and uh
12:21 saving our system from
12:24 hackers. Okay.
12:28 So um QA when working with Mandex a QA
12:31 usually verify if apps behaves correctly
12:34 whether it was about page loading uh
12:37 workflows running and if data is stored
12:39 but MEX is usually used for sensitive
12:42 business processes such as customer
12:44 portals, financial services, government
12:47 solutions which makes its security as
12:49 critical as its functionality and if not
12:53 more. Us as QAs, we already explored the
12:55 unexpected and we never play by the
12:57 rules. So with a small mind shift from
13:00 traditional QA, we would be great threat hunters.
13:02 hunters. Okay.
13:04 Okay.
13:07 Attention to details is a skill 101 for
13:10 any QA. We notice inconsistencies, bad
13:12 or wrong behavior, and even a tiny
13:14 misalignment which makes developers hate
13:16 us so much.
13:18 Okay. Uh but why don't we look at the
13:21 bigger picture? Let's say that I was
13:24 testing a website. Okay. I logged in
13:27 using the username John Do, but I
13:29 entered the wrong password. Mandx
13:31 verified those credentials and returned
13:33 the message in connect password for user
13:35 John Do. If you want to stick to the
13:38 surface, you would say that this test
13:40 has passed because we were not able to
13:42 login again using a password. But the
13:45 security impact of this is pretty huge
13:47 because that message revealed the
13:49 existence of that username which might
13:52 be abused in brute attack uh in brute
13:54 force attacks.
13:56 Another thing exploratory testing let's
13:59 say that we were testing a form or a
14:01 text field or anything that input that
14:04 uh that accept inputs. Okay, we entered
14:06 special characters and they were
14:08 accepted into that field. If we didn't
14:11 use Mendix built-in input validation
14:13 that would expose our system to
14:21 Okay, we already uh discussed a few
14:23 examples that represents the power of
14:26 shifting our mindset from does it work
14:29 to can it be broken by but why don't we
14:31 think more outside of the box.
14:34 What would happen if I intentionally try
14:36 to bypass our security checks? Let's go
14:39 back to the login example. Okay. I
14:41 entered the credentials. Medics verified
14:46 it. If we uh if we if we displayed the
14:48 correct message and everything was
14:50 right, the user was not able to login.
14:52 That would actually pass a test. But
14:54 what if I intentionally manipulate the
14:57 uh the response from the network tab?
15:00 Would I pass the MEX UI? And are my
15:02 checks only implemented in UI or also in
15:04 the back end?
15:06 Another thing is user role testing or
15:09 switching which is widely used in menx
15:12 especially in admin portals. Let's say I
15:14 was working using a limited role uh
15:17 while navigating through this website I
15:20 would only see the authorized pages. But
15:22 if I bookmarked a restricted page or I
15:25 know the link for a page that's only
15:26 supposed to be displayed to the super
15:29 admin. Clicking on that bookmark or
15:31 opening the the URL would it display the
15:33 page or it wouldn't. If that was
15:36 displayed then our our access are misconfigured.
15:44 To recap those were the points that
15:47 we've discussed input viation negative
15:49 testing user switching handed or
15:52 indirect navigation path and also added
15:54 session management. We all know the
15:56 importance of session management.
15:58 Leaving a user session active for too
16:00 long will expose our system to risk. But
16:03 also it has another impact. It might
16:05 overload our system which might cause it
16:18 uh MEX provides strong uh strong
16:21 security defaults such as entity access
16:23 rules, page page access control and
16:25 cross- site scripting protection. But
16:27 misconfiguration and overlooked rules
16:31 are common. QAS already have the already
16:33 have the skill to spot vulnerabilities
16:36 simply by asking what what would happen
16:39 if I break it or or if I misuse it. Okay.
16:41 Okay.
16:44 Um lastly I would like to emphasize on
16:46 something. Functioning applications is
16:49 good but functionality is only half of
16:53 the bottle. Having functional uh having
16:56 a fast, secure, resilient, userfriendly
16:58 and functional application is the end
17:01 goal. By combining both functional and
17:04 nonfunctional testing, then adding menex
17:06 security which is going to be the cherry
17:07 on top, we would have a bulletproof
17:10 system. Okay,
17:13 that would conclude my part for today. I
17:16 wish you all bug and threat
17:19 bug and threateree development. I will
17:21 leave you with my colleague Muhammad who
17:23 will introduce you to man in the middle
17:25 and how to secure applications against it.
17:50 Okay. Hello everyone. My name is
17:52 Muhammad Abu Khadura. I a lead
17:54 application engineer here here as a
17:57 Vertra. I have joined Avertra four years
18:01 ago. So since uh that time I have been
18:04 uh leading multiple banking projects. So
18:08 those project were uh contains of uh web
18:10 application and native mobile application.
18:11 application.
18:13 So it's great to be here today at
18:16 capture the flag events. Uh so guys
18:19 today uh our presentation uh will
18:22 revolve around illustrating how uh a
18:25 threat actor will can leverage device
18:30 proxies. So uh to to intercept the the
18:32 data that will leave the native mobile
18:36 into uh to the server side.
18:38 So this interception
18:41 uh this interception will will allow the
18:44 attacker to view or even modify the data
18:48 in the transit of the payloads.
18:51 So uh
18:53 so today we are going to go through
18:56 three main parts. uh the attack the
19:00 strategy and the result. So firstly the
19:02 attack we are going to show you how
19:04 exactly the attacker is going to
19:07 intercept the data in the transit
19:10 between client side and the server side.
19:13 Next we will move to the strategy. So
19:16 here where we are going to explain our
19:18 strategy which is uh application level
19:21 encryption and decryption.
19:24 And finally we will go to the result. we
19:26 will run the exact same attack that we
19:29 already have uh done in the first step
19:31 but this time with our solution in place.
19:39 So uh we are looking here guys at uh in
19:42 this image we are seeing a classic man
19:44 in the middle attack right where the
19:47 attacker places themselves in the line
19:49 of communication between the client side
19:53 and the server side uh logic so they can
19:57 intercept the data. So uh the attacker
20:01 will use a specialized uh software uh
20:04 called interception proxy. So in this
20:06 session today we are going to use one of
20:10 the most uh common tools uh called burp suite.
20:17 So uh in burp suite once the uh the
20:20 traffic uh reach let's say the network
20:23 side leaves the the native mobile side
20:26 this burpuite this tool will capture the
20:29 traffic and decrypt the https or SSL
20:33 pinning that we are using to uh to give
20:35 control to give control to the attacker
20:38 to view or even modify the data in transit.
20:40 transit. Okay.
20:43 Okay.
20:46 >> So yeah uh now we are going to show you
20:50 a a small demo how the attacker will
20:53 intercept this uh traffic or let's say
20:55 the payload once it leaves the mobile
20:57 device and uh reach the network. he will
21:01 be able to view, modify, uh change uh
21:04 anything in the payload itself uh using
21:06 the tool that we talked about which is
21:45 So, I'm going to I'm going to uh this is
21:48 guys the B suite uh tool that we already
21:50 talked about. um you will need to
21:53 configure the proxy setting in uh to be
21:57 able to intercept the payload or the
22:00 request that have left the mobile. So in
22:02 our case today now I'm going to show it
22:05 to you without any uh solution without
22:07 our solution actually application level
22:10 encryption. I'm going to uh start the
22:13 intercept intercept. Let's make it on.
22:16 I'm going to enter values. Uh in this in
22:19 this example uh I'm going to enter it on
22:21 the mobile. Uh we are going to enter
22:24 from account to account transaction
22:27 amount and the currency. So from account
22:32 let's make it 111. Uh the two account
22:35 222 for example transaction amount let's
22:40 make it 100. And the currency
22:50 So I'm going to hit on submit.
22:52 Burp suit will start capturing all the
22:55 requests that is coming out uh from the
22:59 device. So as you can see here uh this
23:01 is the request that have left the
23:05 device. So if you can uh you can see the
23:09 entity name uh the attributes inside
23:12 this payload. So the entity name is uh
23:15 bank account right. Uh if you you can
23:17 see here the from account that we have
23:20 entered the value is 111 the two account
23:22 the transaction amount you can see
23:25 actually everything inside this payload.
23:28 So for now let's uh let's change the
23:30 transaction amount. Let's make it for
23:37 Uh then just we are going to click on
23:41 forward. This will forward the uh the
23:43 request to the server side. I'm going to
23:46 also show you uh on menx I have already
23:49 added the debugger to see the data how
23:52 it have been reached to the server side.
23:54 So as you can see we have entered the
23:57 from account the currency the two
23:59 account and the transaction amount. The
24:02 transaction amount now is reached the
24:06 server with uh uh 1,000 and we already
24:09 uh entered on the mobile application
24:13 100. So the the attacker was able to
24:15 intercept the request. He was able to
24:18 view all the data and the most important
24:20 thing he was able to change the data
24:24 itself from 100 to 1,000.
24:27 So this is guys uh the attack that we
24:30 are uh we are going to have a solution
25:00 So guys yeah uh as we just saw uh the
25:04 impact the impact itself is uh severe.
25:08 So uh we have seen uh how sensitive data
25:11 uh we have seen uh we we have seen
25:14 sensitive data exposure uh which have
25:18 lead uh leds to unauthorized action. Uh
25:20 as we just saw in the example, the
25:22 attacker have been able to view all the
25:25 payload itself. He was able to modify
25:30 the payload uh to from we we changed
25:32 actually the transaction amount from 100
25:38 to 1,000 uh which will lead to um uh a
25:41 loss of trust in our application. So
25:43 that's why the uh our solution which is
25:45 application level encryption is
25:49 important in our case. So guys the most
25:52 important takeaway uh from this section
25:56 is we can't uh we can't u we can't rely
26:00 just on the HTTPS itself. We need
26:03 another layer of security
26:07 which will lead us to our strategy.
26:11 uh slides right
26:14 so guys uh this uh which as as I
26:16 mentioned before this will lead us to
26:18 our strategy
26:22 so uh we will implement uh our an let's
26:24 say application level encryption and
26:28 decryption to prevent uh this whole
26:31 attack from happening inside the the
26:34 network itself.
26:38 So the concept is basic um as we just
26:42 saw we don't just uh rely on the let's
26:45 say in interception layers itself uh we
26:48 can't we can't just rely on the HTTPS or
26:51 SSL pinning we need another layer as we
26:55 mentioned before to cap to encrypt the
26:59 data on the client side right after it
27:02 before it goes to the network itself uh
27:05 once it reached the network. Uh let's
27:09 say that this data this payload will be
27:11 cipher cipher text. He the attacker will
27:13 not see anything. The data will be
27:17 encrypted. So what once this uh payload
27:19 reach the server side, it will be
27:22 decrypted again and uh it will return to
27:25 its uh original uh format. So it can be
27:31 processed at the server side itself.
27:34 So this is how it will look like in mind
27:38 context. So in in mind we are going to
27:40 do encryption inside the nanoflow which
27:43 is obviously the client side. Uh we are
27:47 going to use uh an inter uh let's say an
27:50 encryption mechanism. Uh in our example
27:53 we are going to use JWT.
27:56 So once the device or the nanoflow
27:59 encrypt this data it will go to uh the
28:02 network itself during the transit the
28:05 data even if the attacker was able to
28:08 intercept the request and compromise
28:11 let's say the HTTPL uh and the SSL
28:14 pinning he will not be able to uh let's
28:18 say to to view or even edit the data
28:21 itself. it will already be unreadable
28:25 cipher text and uh once the uh the
28:28 request reach the server side in a
28:31 micrflow we will uh do the decrypt
28:35 mechanism with the same J JWT. So guys
28:37 uh here the the most important thing
28:40 that we will we will need to take uh
28:43 that we will need to actually be careful
28:46 with it is the keys for the encryption
28:49 and decryption. we have to to manage
28:52 manage it in a secure way that uh the
28:55 attacker will not be able to have access
28:58 to those keys. Uh so he cannot uh let's
29:02 say decrypt the payload himself. So now
29:05 we are going to do uh another demo
29:08 another we will show you another example
29:11 but this time with our solution in place
29:14 uh we are going to show you exactly how
29:18 the attacker uh will uh see the payload
29:20 after the application level encryption
29:57 So guys, I'm going to enter the same
29:59 values that we have entered before,
30:02 which is the from account 111 and the
30:05 two account will be 22.
30:08 The transaction amount uh we have added
30:14 100 and the currency was uh USD in our
30:18 uh previous example. So I'm going to
30:21 turn on the interception on the uh burp
30:26 suite uh tool. So I'm going to hit on
30:30 submit. Now we will see the request in B
30:34 suite. So guys, as we can see on uh the
30:37 screen that this is the payload with the
30:39 our solution application level
30:42 encryption the the object itself the
30:46 payload was encrypted inside the client
30:49 side in anlow and reach the network. The
30:52 the attacker was able to intercept the
30:55 the request itself but he can't see
30:58 anything. It's already cipher text in
31:02 the in the transit. there's nothing uh y
31:04 everything was will be gibberish for him
31:06 he will he will not know what is the
31:09 parameter that is being uh passed or
31:12 what is the object type what is the
31:15 values anything so here everything is
31:19 encrypted I'm going to forward it now
31:22 uh to see it exactly in mind how it's
31:25 going to be so uh now if you can see my
31:27 screen the request have reached the
31:30 server side as you can See the value is
31:34 encrypted nothing clear uh so nothing
31:39 happened to it. So firstly uh in our uh
31:43 micrflow we are going to uh first uh
31:45 decrypt this uh payload that have
31:49 reached the string value. Uh after
31:53 decrypt it it will be converted to uh
31:57 JSON structure. We can see it here. This
32:00 is the same object as JSON structure.
32:04 Then we are going to uh convert it back
32:08 to an object. So it can be uh returned
32:12 to its original format. So the the the
32:14 system will complete pro the process
32:17 that he already started.
32:21 So guys have you have as you have seen
32:23 uh one second let me go back to the slides.
32:45 So as we have seen uh our our solution
32:46 uh let's say application level
32:50 encryption and decryption will focus on
32:52 the encryption itself. So firstly on the
32:55 nanoflow on the client side we are going
32:58 to get that object that we will need to
33:01 pass it uh from the client side to the
33:04 server side. We will need to change it
33:07 uh convert it actually to uh JSON
33:10 format. After changing it to JSON format
33:14 we are going to encrypt it. Uh once the
33:16 data as we have seen reach the server
33:18 side it's going to be decrypted again.
33:21 then it will be converted converted to
33:25 uh an object. So u the server side will
33:29 will have uh uh will see the data in its
33:32 original format. So he can do the
33:35 process that uh he's supposed to do. One
33:38 more thing I wanted to add here is uh
33:41 any parameter any parameter you are
33:43 passing from the client side to the
33:45 server side will be exposed. So you need
33:48 to encrypt in the client side and
33:50 decrypt in the server side. The
33:53 additional thing is even if you return
33:56 data from the micrflow to the nanoflow.
33:59 So the response which will come from the
34:02 the server side to the uh let's say the
34:06 client side will be also exposed. So you
34:09 need also to encrypt inside the server
34:13 side. Same same steps. encrypt the data,
34:17 send it back to the uh client side uh
34:19 encrypted and in the client side you
34:21 need to decrypt it again and do the
34:25 whole scenario the whole steps.
34:27 So to summarize
34:32 uh let's go back. So guys to summarize
34:35 u it's important to to understand that
34:39 uh security is about layers. So we have
34:41 multiple layers here for security. We
34:45 have HTTPS TLS, we have SSL pinning. So
34:48 as we just saw in our example, uh we
34:52 can't just rely on HTTPS or SSL pinning.
34:55 So it might be uh compromised
34:58 uh by the attacker itself. That's why we
35:01 have got to our solution uh the third
35:04 layer uh our solution uh which is
35:06 application level encryption. And
35:10 there's uh that that's the place for uh
35:12 our solution. This is the third layer
35:15 the extra layer that we will have on
35:19 this. So uh actually the result will be
35:24 uh guaranteed that the our payload is is
35:28 secure and uh the data reach uh without
35:32 any manipulation by the attacker. Okay.
35:34 Okay.
35:37 So guys, I'm going to leave you with uh
35:40 three main points uh from our session
35:44 today. So firstly, the threat is real,
35:46 right? So we demonstrated that man in
35:50 the middle attack uh was able to
35:53 intercept the communication and uh let's
35:57 say view and even modify the data in
36:02 transit even with HTTPS was there. So he
36:06 will be able to actually reach the data.
36:09 Secondly, the solution is uh the
36:12 solution is to think in layers. So we
36:15 can't put all of our trust in the uh
36:18 let's say that that those channels which
36:22 is the HTTP TLS and the SSL pinning. we
36:25 need to add uh another extra layer of
36:30 security uh so we can um let's say uh
36:33 encrypt the data before it reach the the
36:37 server side and finally um actually the
36:43 the let's say the the in in the as as as
36:48 a result uh we have been able to uh to
36:50 let's say
36:53 protect our data our payloads in inside
36:57 the network itself. So the attacker was
37:00 not able to see anything inside this
37:04 data. So this will uh ensures that uh
37:06 confidentiality and strategy uh sorry
37:10 and integrity of our data remains uh untouchable.
37:12 untouchable.
37:15 So yeah this is uh everything guys for
37:17 today. Thank you for listening and hope
37:20 you will actually
37:24 uh use uh some tips from this uh session
37:27 today so you can capture the flag. Thank
37:49 Thank you W. Thank you Muhammad. Um so I
37:50 think there was one question online
37:54 about a key for the per suite if there
37:57 is a version but uh there's a community
37:59 version they can download. No key is required.
38:00 required.
38:03 >> Yeah they can use it actually. Yeah uh
38:05 they can use it without keys. I already
38:08 used it without the keys. Yeah, exactly.
38:11 So, it it will not give them all the the
38:15 the options. Uh but uh at least it will uh
38:17 uh
38:19 Exactly. Yes. Exactly.
38:21 >> Uh let's see if there is another
38:23 question from the audience about the
38:26 tool or anything
38:29 or Muhammad Alad.
38:32 If you need guys any help in
38:35 actually exactly tool, we are going to
38:37 help you with it.
38:40 >> You can ask anything regarding it. But
38:42 yeah, I'm not an expert actually in this
38:44 tool, but at least we can help each
38:47 other. Yeah,
38:49 >> thank you so much. Thank you. Thank you all.