hari-kathe

Harish RK

So you're eager to learn about pointers but unfortunately you got stuck because they seemed to you terrible in nature? That's not true I know, but many of the people get confused when they arrive at the topic of pointers. Well pointers are the most important tools in C programming and are the one that can make you fly (unless you don't know how to ride over them). In this article we're going to learn basics of pointers.

Pointers are the varaibles that store addresses of other variables. Easy ain't it?

So lets start with the decleration of a pointer, pointer is decreleared as:

data_type *var_name;
e,g
int *pt;

well the astrisk(*) before the variable name is the thing that makes variable a pointer. So far so good now what?
Now lets say we want to store address of a variable in our pointer variable that seems pretty complex..!

Let's do it:

int number = 100;
int *pt = &num;

Is it really complex..?
what we are doing here is that we are first declaring and initializing a integer variable (number) with value of 100 and then we declare and initialize a pointer variable (pt) with the address of number variable. Now pt (pointer variable) contains the address of number (integer varaible). So what? Now we can use this pointer variable to change the value of number variable. Is this some kind of Magic? Maybe. Lets' do it:

*pt = 200;

what we have done here is that we De-referencing the pt variable with the asterisk (*) and then assigned it the value of 200 now the number variable contains 200. Isn't it a magic? De-referencing is used for accessing the value of the variable towards which our pointer is pointing simple. So lets write a full program of what we have learned so far.

/*Pointer Basics: Creating and Using Pointers*/
#include<stdio.h>
int main(void){
int number = 100;
int *pt = &number;
printf("Value of 'number' is: %d", number);
printf("Address of 'number' is: %p", pt);
*pt = 200;
printf("New value of 'number' is: %d", number);
return 0;
}

What this whole program did was it created a integer variable and a pointer to integer variable and then printed out the value and address of the 'number' variable and after that we De-referenced the pointer variable so that we can access the value to which our pointer variable is pointing and changed the old 100 value with new 200 value and at last we printed that out. Easy isn't it?
But do you know that you can get the address of a variable even by using ampersand (&) operator? Lemme show you how. I'll declare and initialize a variable 'var' and then print it to screen using ampersand (&) operator:

int var = 10;
printf("Address of 'var' is %p\n", &var);

the last statement here will print out the address of 'var' not value so that means it is equal to this statement:

int *pt = &var;
printf("Address of 'var' is %p\n", pt);

here we first assigned the address of 'var' to pointer variable 'pt' and then printed out the address of 'var' using the pointer variable (pt).
So lets write another program that will wrap up this part of 'Pointer Basics':

/*Pointer Basics Part 1: Program 2*/
#include<stdio.h>
int main(void){
   int var = 10;
   int *pt = &var;
   printf("The Value of 'var' is: %d\n", var);
   printf("De-referencing: *pt = %d\n", *pt);
   printf("Ampersand: The Address of 'var' is %p\n", &var);
   printf("pt = %p\n", pt);
   return 0;
}

So that's the end of first part watch out for the next part in which we'll tighten our grip on pointers and get ready for some Advanced '*po(inter)-fo'.

A bug bounty program, also called a vulnerability rewards program (VRP), is a crowdsourcing initiative that rewards individuals for discovering and reporting software bugs. Bug bounty programs are often initiated to supplement internal code audits and penetration tests as part of an organization's vulnerability management strategy.

Many software vendors and websites run bug bounty programs, paying out cash rewards to software security researchers and white hat hackers who report software vulnerabilities that have the potential to be exploited. Bug reports must document enough information for for the organization offering the bounty to be able to reproduce the vulnerability. Typically, payment amounts are commensurate with the size of the organization, the difficulty in hacking the system and how much impact on users a bug might have.

Mozilla paid out a $3,000 flat rate bounty for bugs that fit its criteria, while Facebook has given out as much as $20,000 for a single bug report. Google paid Chrome operating system bug reporters a combined $700,000 in 2012 and Microsoft paid UK researcher James Forshaw $100,000 for an attack vulnerability in Windows 8.1. In 2016, Apple announced rewards that max out at $200,000 for a flaw in the iOS secure boot firmware components and up to $50,000 for execution of arbitrary code with kernel privileges or unauthorized iCloud access.

While the use of ethical hackers to find bugs can be very effective, such programs can also be controversial. To limit potential risk, some organizations are offering closed bug bounty programs that require an invitation. Apple, for example, has limited bug bounty participation to few dozen researchers.

Continue reading

Harish RK

In the first post of this DNSSEC series, I have shown the problem (DNS vulnerabilities), and in the second post, the "solution." In this third post, I am going to analyze DNSSEC. Can DNSSEC protect the users against all of the attacks? Or just part of them? What about corner cases?

The following list are the attack types from the first post, where DNSSEC can protect the users:

DNS cache poisoning the DNS server, "Da Old way"
DNS cache poisoning, "Da Kaminsky way"
ISP hijack, for advertisement or spying purposes
Captive portals
Pentester hijacks DNS to test application via active man-in-the-middle
Malicious attacker hijacks DNS via active MITM

The following list are the attack types from the first post, where DNSSEC cannot protect the users:

Rogue DNS server set via malware
Having access to the DNS admin panel and rewriting the IP
ISP hijack, for advertisement or spying purposes
Captive portals
Pentester hijacks DNS to test application via active man-in-the-middle
Malicious attacker hijacks DNS via active MITM

If you are a reader who thinks while reading, you might say "What the hell? Am I protected or not???". The problem is that it depends… In the case where the attacker is between you and your DNS server, the attacker can impersonate the DNS server, downgrade it to a non DNSSEC aware one, and send responses without DNSSEC information.

Now, how can I protect against all of these attacks? Answer is "simple":

Configure your own DNSSEC aware server on your localhost, and use that as a resolver. This is pretty easy, even I was able to do it using tutorials.
Don't let malware run on your system! ;-)
Use at least two-factor authentication for admin access of your DNS admin panel.
Use a registry lock (details in part 1).
Use a DNSSEC aware OS.
Use DNSSEC protected websites.
There is a need for an API or something, where the client can enforce DNSSEC protected answers. In case the answer is not protected with DNSSEC, the connection can not be established.

Now some random facts, thoughts, solutions around DNSSEC:

Did you know .SE signed its zone with DNSSEC in September 2005, as the first TLD in the world?
Did you know DNSSEC was first deployed at the root level on July 15, 2010?
Did you know .NL become the first TLD to pass 1 million DNSSEC-signed domain names?
Did you know that Hungary is in the testing phase of DNSSEC (watch out, it is Hungarian)?
Did you know that you can also use and test that cool DNSSEC validator?
Did you know that there are alternative solutions like DNSCrypt?
Did you know that in the future you might be able to enforce HSTS via DNSSEC?
Did you know that in the future you might be able to use certificate pinning via DNSSEC?

That's all folks, happy DNSSEC configuring ;-)

Note from David:

Huh, I have just accidentally deleted this whole post from Z, but then I got it back from my browsing cache. Big up to Nir Sofer for his ChromeCacheView tool! Saved my ass from kickin'! :D

More articles

hari-kathe

Tuesday, May 30, 2023

Pointers Part 1: The Basics

Related posts

Monday, May 29, 2023

Hackerhubb.blogspot.com

$$$ Bug Bounty $$$

Continue reading

DNSSEC, From An End-User Perspective, Part 3

Blog Archive