Tue May 15 14:41:04 EEST 2018

Open letter to HRs


Hi HR,

You are a proxy recruiter, right?

Assuming so I appear to be the ``product''.

Here is a brief summary of the product: I was active in security in the period
1997-2007, mainly disclosing my 0days. Per my estimate was in top 3%
overall of the public hacking scene (this might be far off in both
directions). 
During roughly this time was Netscape/Mozilla independent security consultant,
mainly pre-0days and advice for the Firefox browser.
Then I went on a vacation, mainly enjoying life and doing
experimental mathematics as a hobby.

I am considering return in the IT stuff.

Some of the things I DO NOT do currently:
1. 0days (AKA security bug hunting)
2. working with products of microsoft (don't like MS).
3. relocation from Sofia, Bulgaria (it is in the EU).

Some of the things I would like to do (not all applicable for you):
1. Experimental mathematics/data analysis
2. Software quality assurance (QA)
3. Hardening systems
4. Privacy research
5. Some security research without 0days
6. Possibly software development
7. Possibly security consulting

In all non-trivial stuff I have done I am self taught, education
didn't help much.

CV: http://j.ludost.net/resumegg.pdf

Georgi Guninski

Posted by joro | Permanent link

Thu Apr 26 12:30:40 EEST 2018

My brother's emails


Just for a backup contact, my brother's emails are:

aguninski@gmail.com
sashog@yahoo.com


Posted by joro | Permanent link

Wed Feb 21 15:43:03 EET 2018

Types of security bugs by methodology of discovery


Types of security bugs by methodology of discovery

Draft: Wed Feb 21 13:35:57 UTC 2018

Here are some types of security bugs by methodology of discovery that work for me,
your mileage may wary

1. Fuzzing
2. Source code auditing
2.1 When you know that to look for
2.2 When you don't know that to look for
3. Opportunistic black box attacks
4. Bugs out of nowhere

Some details.

1. Fuzzing
This is easiest. Run a fuzzer and wait, usually for SEGV.
The hard part is writing the fuzzer and making exploit from a messy testcase.

2. Source code auditing
2.1 When you know that to look for

Run a grep(1) or something better like semantic grep or some kind of source analyzer.
Usually you are looking for low hanging fruit like strcpy(3) or something like it.
Second by ease.

2.2 When you don't know that to look for

Carefully examine the source code looking for “anomalies”.
Run the code in your head, not necessarily rigorously.
If the codebase is large split by subcomponents, the interaction between them
is complicated stuff.
To some extent it could be automated, but logical errors are likely uncaught.
Example of this approach is the qmail signedness bug

3. Opportunistic black box attacks
Examples of these are almost? all my internet explorer bugs.
Treat the program as a black box and try random stuff, carefully observing
small changes in the system and side effects.
Difficult to succeed. Resembles catching fish in a pool.

4. Bugs out of nowhere

No joke. These are so rare they border with non-existence.
I claim they exist.
Read some documentation and optionally if possible browse some source
code.
Then relax without computer thinking about whatever you wish.
If you are lucky, potential bug will pop up in your head.
Verify the reality of the bug on a computer.
For me relaxation with beer greatly increases the potential bugs and the false positives.

Posted by ^-^ | Permanent link

Wed Feb 14 15:14:53 EET 2018

On IT security



Some important axiom in the Real World are:
1. Hardware is buggy and insecure
2. Software is buggy and insecure
3. Users are buggy and insecure

The goal of IT security is to build secure and bug-free system while
(implicitly) assuming (1) and (2) and (3). Usually the solution is
just Antivirus.


Posted by lol | Permanent link

Fri Feb 9 14:59:22 EET 2018

Cosmos


Posted by stefo | Permanent link

Thu Feb 1 10:48:20 EET 2018

Чecтит Tpифoн Зapeзaн / Happy St. Trifon Zarezan

Чecтит Tpифoн Зapeзaн
===
Happy St. Trifon Zarezan

Posted by in bira veritas | Permanent link

Wed Jan 10 15:41:19 EET 2018

Nearly social, on Linkedin

I am getting nearly social on Linkedin.

Name:  Georgi Guninski
URL: https://www.linkedin.com/in/georgi-guninski-b0069a156

Posted by oo | Permanent link

Tue Jan 9 12:26:53 EET 2018

Own on install. How grave it is?

This is well known, haven't seen it discussed.

In short doing clean install (factory defaults) has a window of
opportunity when the device is vulnerable to a known network attack.

It used to be common sense to reinstall after compromise (probably
doesn't apply to the windows world where the antivirus takes care).

All versions of windoze are affected by the SMB bug to my knowledge.
Debian jessie (old stable) is vulnerable to malicious mirror attack.

More of interest to me are devices where the installation media is
fixed and can't be changed.

This includes smartphones and wireless routers.

Some smartphones might be vulnerable to wifi RCE (found by google?).
Some wireless routers might be vulnerable to wifi RCE or
default admin password attack over wifi.

Internet of Things will make things worse (some NAS devices are
affected).

Shielding the device might not be solution since updates must be
applied.

Are the above concerns real?

Have this been studied systematically?



Posted by 00t | Permanent link

Mon Jan 8 15:41:16 EET 2018

Some predictions for 2018

Some predictions for 2018:

1. Major malware(s) spreading via Intel ME and the like.
Significantly worse than wannacry.
Possibly hard to clean, requiring reprogramming chip on external
device.

2. Major Android malware(s).

3. m$ windows will suck so much, computer illiterate people will be
ready to pay for just literally "uninstalling windows"

4. bitcoin will at least temporary lose the first place on
https://coinmarketcap.com (this is not rigorous metric)

Posted by nearly a time machine | Permanent link

Mon Jan 1 09:04:46 EET 2018

Чecтитa нoвa гoдинa / Happy New Year

Чecтитa нoвa гoдинa / Happy New Year

Posted by ЧНГ | Permanent link