1
00:00:00,170 --> 00:00:06,750
We're going to take a look at the idea of insecure logging when we're actually working with applications

2
00:00:06,780 --> 00:00:12,750
on Android devices we're able to log things into the log catalogs of our device.

3
00:00:12,750 --> 00:00:17,100
Now when we log things to these logs we have to be careful of what sort of information or writing to

4
00:00:17,100 --> 00:00:21,660
them because they could potentially expose information that is sensitive.

5
00:00:21,660 --> 00:00:26,220
So we're going to take a look at what this would usually look like instead of an application and how

6
00:00:26,220 --> 00:00:30,300
we can sort of find these vulnerabilities and determine if they exist.

7
00:00:30,300 --> 00:00:35,760
So first I want to explain a little bit about what this vulnerability is and why it's important.

8
00:00:35,760 --> 00:00:42,810
So there exists a general logging area on Android devices that is typically referred to as a logging

9
00:00:42,810 --> 00:00:43,210
cat.

10
00:00:43,890 --> 00:00:47,800
Now if I open up Android Studio here you can actually see the log here.

11
00:00:48,060 --> 00:00:53,970
So you could see here that consistently information is being logged to this log and this blog is shared

12
00:00:53,970 --> 00:00:58,090
by basically all of the applications on the actual device itself.

13
00:00:58,290 --> 00:01:04,280
And you can write things to the log fairly easily using some built in functions inside of the the android.

14
00:01:04,740 --> 00:01:06,780
The Android development module is right.

15
00:01:06,780 --> 00:01:11,030
So you'll be able to actually write information to these debugging logs.

16
00:01:11,070 --> 00:01:16,110
Not only can you write to them but you can also read them to see if a specific error has occurred.

17
00:01:16,110 --> 00:01:20,430
The reason why we don't want to log any sensitive information to this is sort of twofold through one

18
00:01:20,490 --> 00:01:21,380
as you can see here.

19
00:01:21,390 --> 00:01:27,780
I can easily access the log cut logs just by having the device plugged into my computer or by having

20
00:01:27,780 --> 00:01:30,600
the device running through an emulator on my computer.

21
00:01:30,690 --> 00:01:36,630
But more so that what's important to this is that somebody can actually created app that can read this

22
00:01:36,630 --> 00:01:37,980
log catalog.

23
00:01:38,040 --> 00:01:41,370
That means in terms they can read any messages that are logged to here.

24
00:01:41,400 --> 00:01:46,620
So if you for instance are logging information about a user's password or something like that if I have

25
00:01:46,620 --> 00:01:52,170
an application that's like sniffing the log file on this person's device I'll be able to see that information

26
00:01:52,170 --> 00:01:53,020
as well.

27
00:01:53,040 --> 00:01:58,530
So this gives you some context behind what this vulnerability really is and why it's important.

28
00:01:58,560 --> 00:02:03,150
So it's not really just a matter of logging information that is sensitive such as like an API key or

29
00:02:03,150 --> 00:02:07,110
something like that that somebody might see from you know looking at the logs.

30
00:02:07,110 --> 00:02:13,020
It's also a matter of someone you know a third party sort of like sniffing the logs of a random device

31
00:02:13,230 --> 00:02:15,710
to grab information about the user.

32
00:02:15,810 --> 00:02:22,200
So to give you an example of this let's go ahead and open up our diva application and we'll go into

33
00:02:22,200 --> 00:02:27,180
insecure logging and I'm going to demonstrate to you what exactly this could look like.

34
00:02:27,180 --> 00:02:32,250
So you see here and here we want to enter into credit card information so gonna put it on my credit

35
00:02:32,250 --> 00:02:35,750
card information and press checkout when I do this.

36
00:02:36,060 --> 00:02:40,220
You're going to see right here that there's an error message that gets processed.

37
00:02:40,230 --> 00:02:46,200
It says error while processing transaction with credit card and then it prints out the credit card number.

38
00:02:46,200 --> 00:02:48,050
So this is something that we want to avoid.

39
00:02:48,060 --> 00:02:50,550
This would be an example of insecure logging.

40
00:02:50,670 --> 00:02:55,500
And the reason being again is because if we have a third party application that say sniffing this log

41
00:02:55,800 --> 00:03:00,540
if they see this error message it exposes the credit card information of the user.

42
00:03:00,540 --> 00:03:05,930
So this is extremely bad because obviously then people can potential have an information disclosure

43
00:03:05,940 --> 00:03:10,340
they could end up showing information to someone else that shouldn't see that information.

44
00:03:10,350 --> 00:03:12,060
They'll be able to compromise them with it.

45
00:03:12,060 --> 00:03:12,360
Right.

46
00:03:13,230 --> 00:03:18,630
So we can take a look at the source code of this that we've compiled to get a bit of an idea of what

47
00:03:18,630 --> 00:03:21,160
this is actually looking like in the code.

48
00:03:21,180 --> 00:03:27,490
Just to give you an idea of what sort of things you can look out for for this so we have this log activity.

49
00:03:27,490 --> 00:03:33,300
This this method here log dot e is what happens when we're trying to log an error message.

50
00:03:33,310 --> 00:03:38,290
So there's like log dye E for error I think log dot D is debug and there's probably a few other ones

51
00:03:38,430 --> 00:03:39,710
that are very common.

52
00:03:39,790 --> 00:03:44,460
And as you can see here it gives the actual error message and you can see it actually writes in whatever

53
00:03:44,460 --> 00:03:50,410
is inside of a text box of the of the credit card field so you can see this is what the actual log message

54
00:03:50,470 --> 00:03:51,010
looks like.

55
00:03:51,010 --> 00:03:57,520
So if we're looking for these sort of instances we can look for like log dot e or log dot D and these

56
00:03:57,520 --> 00:04:04,000
will show us where logs are being read into the actual device like itself and then from there you can

57
00:04:04,000 --> 00:04:09,850
try triggering these are looking at what is actually being log to determine if that information is sensitive

58
00:04:09,850 --> 00:04:10,890
data or not.

59
00:04:11,080 --> 00:04:17,020
So common sensitive data would include things like passwords even usernames credit card details obviously

60
00:04:17,020 --> 00:04:24,070
personal details any anything sort of related to that API keys of the application would be a common

61
00:04:24,070 --> 00:04:30,940
one even database table names databases in general this sort of information leakage is the kind of stuff

62
00:04:30,940 --> 00:04:33,530
that we want to make sure isn't happening in our application.

63
00:04:33,540 --> 00:04:36,820
So this would be an example of insecure logging.

64
00:04:36,820 --> 00:04:40,690
So this gives you an idea of what this vulnerability looks like and how to actually detect it in an

65
00:04:40,690 --> 00:04:41,440
application.