Has Firefox become bugless or where are the Firefox CVEs for 2017? Through 2016 Firefox had about the same number (or same order of magnitude) of new issues listed as every other browser. Around 100-250.

2017 lists only a single issue

https://www.cvedetails.com/product/3264/Mozilla-Firefox.html?vendor_id=452

I'd love to believe it's true but on the surface that basically seems impossible. All software has bugs and especially software as complex as a browser.

Some possibilities:

Vulnerabilities in cvedetails.com not showing the correct data
Vulnerabilities are listed under some other software, not under Firefox
Mozilla discovered of way of having ~0 issues unlike all other software in the history of software.
???

Any idea what's going on?

Canonical Solution
According to Security Advisories for Firefox, there were 182 security vulnerabilities that were fixed in 2017.
List of Firefox CVEs (Fixed) - 2017:
* --------------------------------------------------------------------------------------------------- *
| #   | CVE Identifier | Source                                                                       |
| --------------------------------------------------------------------------------------------------- |
| 1   | CVE-2017-5373  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5373 |
| 2   | CVE-2017-5374  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5374 |
| 3   | CVE-2017-5375  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5375 |
| 4   | CVE-2017-5376  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5376 |
| 5   | CVE-2017-5377  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5377 |
| 6   | CVE-2017-5378  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5378 |
| 7   | CVE-2017-5379  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5379 |
| 8   | CVE-2017-5380  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5380 |
| 9   | CVE-2017-5381  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5381 |
| 10  | CVE-2017-5382  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5382 |
| 11  | CVE-2017-5383  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5383 |
| 12  | CVE-2017-5384  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5384 |
| 13  | CVE-2017-5385  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5385 |
| 14  | CVE-2017-5386  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5386 |
| 15  | CVE-2017-5387  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5387 |
| 16  | CVE-2017-5388  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5388 |
| 17  | CVE-2017-5389  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5389 |
| 18  | CVE-2017-5390  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5390 |
| 19  | CVE-2017-5391  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5391 |
| 20  | CVE-2017-5392  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5392 |
| 21  | CVE-2017-5393  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5393 |
| 22  | CVE-2017-5394  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5394 |
| 23  | CVE-2017-5395  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5395 |
| 24  | CVE-2017-5396  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5396 |
| 25  | CVE-2017-5397  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-04/#CVE-2017-5397 |
| 26  | CVE-2017-5398  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5398 |
| 27  | CVE-2017-5399  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5399 |
| 28  | CVE-2017-5400  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5400 |
| 29  | CVE-2017-5401  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5401 |
| 30  | CVE-2017-5402  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5402 |
| 31  | CVE-2017-5403  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5403 |
| 32  | CVE-2017-5404  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5404 |
| 33  | CVE-2017-5405  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5405 |
| 34  | CVE-2017-5406  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5406 |
| 35  | CVE-2017-5407  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5407 |
| 36  | CVE-2017-5408  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5408 |
| 37  | CVE-2017-5409  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5409 |
| 38  | CVE-2017-5410  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5410 |
| 39  | CVE-2017-5411  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5411 |
| 40  | CVE-2017-5412  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5412 |
| 41  | CVE-2017-5413  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5413 |
| 42  | CVE-2017-5414  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5414 |
| 43  | CVE-2017-5415  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5415 |
| 44  | CVE-2017-5416  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5416 |
| 45  | CVE-2017-5417  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5417 |
| 46  | CVE-2017-5418  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5418 |
| 47  | CVE-2017-5419  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5419 |
| 48  | CVE-2017-5420  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5420 |
| 49  | CVE-2017-5421  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5421 |
| 50  | CVE-2017-5422  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5422 |
| 51  | CVE-2017-5425  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5425 |
| 52  | CVE-2017-5426  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5426 |
| 53  | CVE-2017-5427  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5427 |
| 54  | CVE-2017-5428  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-08/#CVE-2017-5428 |
| 55  | CVE-2017-5429  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5429 |
| 56  | CVE-2017-5430  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5430 |
| 57  | CVE-2017-5432  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5432 |
| 58  | CVE-2017-5433  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5433 |
| 59  | CVE-2017-5434  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5434 |
| 60  | CVE-2017-5435  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5435 |
| 61  | CVE-2017-5436  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5436 |
| 62  | CVE-2017-5438  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5438 |
| 63  | CVE-2017-5439  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5439 |
| 64  | CVE-2017-5440  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5440 |
| 65  | CVE-2017-5441  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5441 |
| 66  | CVE-2017-5442  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5442 |
| 67  | CVE-2017-5443  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5443 |
| 68  | CVE-2017-5444  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5444 |
| 69  | CVE-2017-5445  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5445 |
| 70  | CVE-2017-5446  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5446 |
| 71  | CVE-2017-5447  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5447 |
| 72  | CVE-2017-5448  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5448 |
| 73  | CVE-2017-5449  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5449 |
| 74  | CVE-2017-5450  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5450 |
| 75  | CVE-2017-5451  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5451 |
| 76  | CVE-2017-5452  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5452 |
| 77  | CVE-2017-5453  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5453 |
| 78  | CVE-2017-5454  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5454 |
| 79  | CVE-2017-5455  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5455 |
| 80  | CVE-2017-5456  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5456 |
| 81  | CVE-2017-5458  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5458 |
| 82  | CVE-2017-5459  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5459 |
| 83  | CVE-2017-5460  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5460 |
| 84  | CVE-2017-5461  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5461 |
| 85  | CVE-2017-5462  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5462 |
| 86  | CVE-2017-5463  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5463 |
| 87  | CVE-2017-5464  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5464 |
| 88  | CVE-2017-5465  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5465 |
| 89  | CVE-2017-5466  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5466 |
| 90  | CVE-2017-5467  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5467 |
| 91  | CVE-2017-5468  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5468 |
| 92  | CVE-2017-5469  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5469 |
| 93  | CVE-2017-5031  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-14/#CVE-2017-5031 |
| 94  | CVE-2017-5470  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-5470 |
| 95  | CVE-2017-5471  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-5471 |
| 96  | CVE-2017-5472  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-5472 |
| 97  | CVE-2017-7749  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7749 |
| 98  | CVE-2017-7750  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7750 |
| 99  | CVE-2017-7751  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7751 |
| 100 | CVE-2017-7752  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7752 |
| 101 | CVE-2017-7754  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7754 |
| 102 | CVE-2017-7755  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7755 |
| 103 | CVE-2017-7756  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7756 |
| 104 | CVE-2017-7757  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7757 |
| 105 | CVE-2017-7758  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7758 |
| 106 | CVE-2017-7759  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7759 |
| 107 | CVE-2017-7760  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7760 |
| 108 | CVE-2017-7761  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7761 |
| 109 | CVE-2017-7762  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7762 |
| 110 | CVE-2017-7763  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7763 |
| 111 | CVE-2017-7764  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7764 |
| 112 | CVE-2017-7765  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7765 |
| 113 | CVE-2017-7766  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7766 |
| 114 | CVE-2017-7767  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7767 |
| 115 | CVE-2017-7768  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7768 |
| 116 | CVE-2017-7770  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7770 |
| 117 | CVE-2017-7778  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7778 |
| 118 | CVE-2017-7753  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7753 |
| 119 | CVE-2017-7779  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7779 |
| 120 | CVE-2017-7780  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7780 |
| 121 | CVE-2017-7781  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7781 |
| 122 | CVE-2017-7782  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7782 |
| 123 | CVE-2017-7783  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7783 |
| 124 | CVE-2017-7784  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7784 |
| 125 | CVE-2017-7785  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7785 |
| 126 | CVE-2017-7786  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7786 |
| 127 | CVE-2017-7787  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7787 |
| 128 | CVE-2017-7788  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7788 |
| 129 | CVE-2017-7789  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7789 |
| 130 | CVE-2017-7790  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7790 |
| 131 | CVE-2017-7791  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7791 |
| 132 | CVE-2017-7792  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7792 |
| 133 | CVE-2017-7794  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7794 |
| 134 | CVE-2017-7796  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7796 |
| 135 | CVE-2017-7797  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7797 |
| 136 | CVE-2017-7798  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7798 |
| 137 | CVE-2017-7799  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7799 |
| 138 | CVE-2017-7800  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7800 |
| 139 | CVE-2017-7801  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7801 |
| 140 | CVE-2017-7802  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7802 |
| 141 | CVE-2017-7803  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7803 |
| 142 | CVE-2017-7804  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7804 |
| 143 | CVE-2017-7806  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7806 |
| 144 | CVE-2017-7807  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7807 |
| 145 | CVE-2017-7808  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7808 |
| 146 | CVE-2017-7809  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7809 |
| 147 | CVE-2017-7793  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7793 |
| 148 | CVE-2017-7805  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7805 |
| 149 | CVE-2017-7810  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7810 |
| 150 | CVE-2017-7811  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7811 |
| 151 | CVE-2017-7812  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7812 |
| 152 | CVE-2017-7813  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7813 |
| 153 | CVE-2017-7814  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7814 |
| 154 | CVE-2017-7815  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7815 |
| 155 | CVE-2017-7816  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7816 |
| 156 | CVE-2017-7817  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7817 |
| 157 | CVE-2017-7818  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7818 |
| 158 | CVE-2017-7819  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7819 |
| 159 | CVE-2017-7820  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7820 |
| 160 | CVE-2017-7821  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7821 |
| 161 | CVE-2017-7822  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7822 |
| 162 | CVE-2017-7823  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7823 |
| 163 | CVE-2017-7824  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7824 |
| 164 | CVE-2017-7825  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7825 |
| 165 | CVE-2017-7826  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7826 |
| 166 | CVE-2017-7827  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7827 |
| 167 | CVE-2017-7828  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7828 |
| 168 | CVE-2017-7830  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7830 |
| 169 | CVE-2017-7831  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7831 |
| 170 | CVE-2017-7832  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7832 |
| 171 | CVE-2017-7833  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7833 |
| 172 | CVE-2017-7834  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7834 |
| 173 | CVE-2017-7835  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7835 |
| 174 | CVE-2017-7836  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7836 |
| 175 | CVE-2017-7837  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7837 |
| 176 | CVE-2017-7838  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7838 |
| 177 | CVE-2017-7839  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7839 |
| 178 | CVE-2017-7840  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7840 |
| 179 | CVE-2017-7842  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7842 |
| 180 | CVE-2017-7843  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-27/#CVE-2017-7843 |
| 181 | CVE-2017-7844  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-27/#CVE-2017-7844 |
| 182 | CVE-2017-7845  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-29/#CVE-2017-7845 |
* --------------------------------------------------------------------------------------------------- *


side channel attack vs eavesdropping attack I wonder if there is a difference between side channel attack and eavesdropping attack. To me both seems similar

Yes.

Eavesdropping means that someone (usually someone named Eve...) eavesdrops on Alice's communication with Bob. Eavesdropping can break the security of a system, for example when the protocol has passwords transmitted in plaintext.

A sidechannel attack takes advantage of information leaked via (insert drums here) a side channel which you watch to break a system. Sidechannel attacks don't need to involve any eavesdropping on actual communications between Alice and Bob; the attacker might just attack the system directly and observe a given side channel.

For example, here's a simple side-channel attack against naive implementations of a password check that uses a for loop to check each secret character against a provided password:

def check_password(provided):
   secret = 'open-sesame'
   for i in range(len(secret):
       if provided[i] != secret[i]:
           return False
   return True

(The above python code wouldn't work in real life, but bear with me): If you use such a check, it takes less time when the first character is wrong than it takes when the first character is right, because the for loop will be terminated in the first iteration. So you can simply try a password starting with A, then with B, then with C and so on and measure the time it takes for it to be rejected by check_password. When it takes a bit longer, you know you have the right first character. Now repeat that with the second character, etc.

The communication going on here is that you're providing the check_password function with a password and get a True or False (accepted or rejected) answer. The time it takes for the password to be accepted or rejected is the side channel, and since the time isn't the same for accepted and rejected passwords, the system leaks information over this side channel, which can be exploited to turn password guessing into a O(n) operation, where n is the length of the password in characters.

You might think such tiny differences in timing can't be exploited, but it's been shown that such timing attacks even work remotely (e.g. by measuring how long it takes the server to reply with a "access denied" message), provided that you collect enough statistical information about how long the average answer takes to reach you.

https://www.sjoerdlangkemper.nl/2016/11/01/tenex-password-bug/ describes an older timing attack against password checking found on the tenex operating system which exploited timing differences introduced by the paging infrastructure . That one's pretty famous and the provided link has a nice and detailed explanation.

Timing attacks are just one example of side-channel attacks. Another side-channel is power consumption, and recently Bruce Schneider blogged about a research paper that used an attack using wifi radiation patterns to determine your smart phone password. Also see news article about it.


Do anti-XSS rules of Web Application Firewall break business logic? I've read about Web Application Firewalls in a MOOC, and the provided example is that the WAF can filter out a request like ?user=<script to avoid potential XSS attacks.

But what if a webpage of the application allows to see a user's profile in a pretty way like view_user?name=... (instead of ID-based)? I could set my name to <script in the register form or so, and then, no one will be able to see my profile, because the page would legitimately be view_user?name=<script and the WAF rejects it?

Such username sounds odd, but it can be an advantage to have a non-accessible profile in some applications: like, in a game where you have to view the player's page [or a town's page or a character's page etc] to attack them, in a forum where you need to get to a user's page to edit/ban them, etc.

In more general terms: can you avoid side-effects of WAF rules that break business-logic? How?

In a general sense, WAFs are historically notorious for false positives- issuing alerts on legitimate requests when in non-blocking mode, and for edge case breakage of applications, difficult or impossible to reproduce in non-production environments, when in blocking mode.

As a result, the overall space is evolving away from signature- and granular request-specific alerting- which is really the responsibility of the application- and moving more towards reputation analysis, statistical anomaly detection, and providing pooled intelligence around the behavior of threat actors.


Should we build a generic security unit test suite as part of our secure SDLC we are delivering security as security requirements directly into the backlog of an application team. The security requirements will directly correlate to the functional features being delivered in the iteration. I am predominantly talking about application based controls ( code level ) here btw.
As part of that we are looking to encourage unit testing for those requirements as a mechanism for fully validating their implementation and going one step further we are hoping to foster the practice of TDD - i.e. the developer will develop a unit test for security functionality e.g. input validation for path traversal etc
I have read that it would be a good idea for us to develop a generic unit test suite for this
Now I have to ask - Would it ?
Would it really be a good idea for us to develop a bunch of JUNIT tests to integrate into development teams projects ? Is there not an issue around flexibility here in that we would pretty much be standardising the how, the parameters, and the naming of security functions for development teams?
Maybe there is another way we could develop generic unit tests that would allow developers call their bespoke methods without them following the method signatures of our test frameworks that I am not aware of ? I imagine the overhead for integrating this would be huge!
Does us developing the test not fly in the face of TDD in that the developer doesnt need to "think about what he is delivering and write a test first"
My gut says the test suite should be sudo code for each requirement with outliers and negative and positive scenarios that the developers must implement - this way it woudlnt matter if we are writing it in C, C# Java or python etc
Is this not a better approach ?

Yeah, I'm having the same debate with my teams and I am equally conflicted about it.
Arguments for security unit tests:

Reusability / automation of security testing (ie you can re-use security unit tests against new products / features without needing time from the appsec team for manual testing)
Regression testing: continue testing for these security defects in the future, not a point-in-time manual test.

Arguments against security unit tests:

pen testing is often highly intuition-based relying on experience and training of the security tester, and typically not things you would think of if you just sat down to define the positive and negative test cases, and/or not even possible to test via unit tests. Pen test cases are also often complex. For example, is someone likely to write a junit test for "Do the login flow up to but not including MFA; take that mid-flow JWT and try calling APIs with it". Or "Create a JWT with sub= for each value in this XSS payload list then navigate around the UI and see if any of the javascript payloads execute". In fact, I'm not even sure how you do the later in junit.
junit tests are usually testing individual methods. You may find real security issues there, but the high-value security issues typically happen at the boundary of software layers; ex.: you have a GET controller that assumes CSRF protection is being applied to it, but Spring is only configured to do CSRF on POSTS. Or tomcat is listening for /admin reqs on :666 and the firewall had better be blocking that externally. (plus the ones in the previous bullet; mismatch between login and access control parts of the code; a mismatch between JWT and UI).

I guess where I've landed is that some of your manual exploratory appsec testing will be automatable. Like, at the end of a Burp or ZAP session, go through your history, find things that would be good automation candidates, export as curl, throw them into unit tests. Great, value added. But recognize that the high-value security issues will likely not show up in unit tests, so question whether this is the best use of your appsec time budget.


Can an attacker see Cookie Contents via CSRF attack? I'm trying to learn about CSRF Attack and having a hard time understanding that.

My understanding is, An attacker can maliciously make a request to the user via hidden value in his website to make a request to Bank website to transfer funds.
The browser sends all cookies along with that request initialed maliciously via Attacker.

My question is, Can the attacker see cookie contents like Session ID or some Data stored Inside Cookie?

When the targeted application does not properly validate the origin of the request a Cross Site Request Forgery attack is possible.

It is an attack which forces end users to execute undesired actions on a web application in which they are currently authenticated.

Due to the nature of web browsers, all cookies are transmitted in the malicious request to target the web application.

  Can the attacker see cookie contents like Session ID or some Data stored Inside Cookie?

No, this is not possible in a Cross Site Request Forgery attack. However, if a Cross Site Scripting attack is also possible this may be possible depending on the cookie's attributes (e.g. HTTPOnly)


Web server file sniffing What is it called when a user tries several attempts to figure out the files and folder structure on a web server?

For example, the attacker will run http://example.com/test.jpg to determine if test.jpg exists or not before commencing on other kind of attacks?

The proper term for it is Forced (or Forceful) Browsing.


How to convince my management of a physical security risk? While I do not claim to be an expert in all things security based, I'd think that I have a good grounded knowledge of what is acceptable and what is not in regards to digital security.

After giving some general advice on internal network security, I was advised by a company that physical access based attacks (i.e. attacker has access to internal network) are unrealistic and are considered out of scope.

I was informed that due to the company having a guest wifi system which is in a DMZ, it's not a problem for them. The main oversight that they don't seem to understand or accept is that from outside the office, you can see in plain sight the private wifi password stuck to the walls around the office, as so many people constantly forget them.

Without lighting fires, I am really struggling to get them to accept that this is horrible practice and they are really opening themselves up if an attacked or compromised system was connected to their private wifi.

For example, customer brings device into office for a meeting, sees a publicly advertised wifi password in the meeting room and continues to connect to the wifi. Customers machine is compromised and now has full access to the private internal network containing business critical data, and a ton of personal data due to bad domain policies.

Any suggestions on the best way to approach this situation?

Take a passive approach and do a risk assessment. Security management is a form of risk management. You have assets which might have threats and vulnerabilities. A threat exploiting a vulnerability is a risk, which is calculated by calculating (quantitative) or estimating (qualitative) the likelihood and impact (most of the time it's high,medium,low but some organizations have their own).

First you expose the risk. You derive an impact of an attacker having access to the internal network. Then you assess the likelihood and technical complexity. In your case the hard part is getting buy in from your management. So the first thing to do is taking references. Have a look if you find specific requirements for the type of business you are in, the size of your business and what industry best practice guides say you should do (NIST). It's important to structure your risks like this ensuring you have both the technical reasons, but also a clear business impact (what is this going to cost the business?) (in the end the business is what it's all about, IT is just an enabler).

As you are from the UK and you clearly think there is a risk for private data, have a look at the Data Protection Act. It's always interesting to show what can happen by refering to cases which bear a similarity to your current environment. Make sure that they understand that the upper management can be held personally accountable if it's deemed they made wrong decisions (e.g. not fixing this), but do not threaten them as this may have an adverse effect.

There's also the EU General Data Protection Regulation, which will be finalized end of this year. It allows the EU to fine companies up to 5% of their global turnover in case severe missmanagement of personal data is found.

After you  have made the report, you need to present it to your management, which is someone responsible for the business and someone responsible for IT as well as your internal audit department. That's the easy part. Now comes the hard part: sell security.

You will need to get buy-in from your upper management to fix this, which will most likely cost money as they will need to spend resources. Unfortunately it's quite hard to do so, you need to involve your stake holders in the security process and explain the benefits to them. It's important to involve all employees in your security process. The security executive cannot sell the necessity and importance of the security function to others if  people do not understand it.

Now the best way to get buy-in is to make them first understand. Make sure you think of a solution for each problem you face, you're already half way if you can come up with a good alternative. In your case it could be password managers or using domain credentials (PEAP authentication).  I'm not a fan of allowing just any device into the internal network, preferably the only devices allowed should be those issued by the company.

Note that the business may decide to sign off on the risk. This means that they're aware of the risk, but choose not to do anything with it. In the end there's only so much you can do. To be fair, it's not uncommon that a serious incident occurs before people start seeing the importance of security. It's sad, but the hard truth.


Friend received email from my name, but an unknown account A friend of mine has just received an email from my name @ medexplorer.com
i don't have an account with Medexplorer, and it has a link which neither one of us has clicked. What could this be and how do I stop it?

First, you cannot stop someone from sending emails from an account that they set up.

Second, if you have a common name (Chris?) then this is not unusual at all to get phishing emails (or emails with infected links). Spam has been happening for a very long time.

Third, if the email address included your last name, then it is possible that either you or your friend has had their email accounts compromised and the address books mined for contacts. If this is the case, I highly recommend changing passwords and implementing 2-factor authentication (if available).


Brute force time estimation - random sequence I would like to ask if there are 2^1000 possibilities to choose from, how long would it  take go through them all on average? (in terms of min, hours or years)

Note: This is not necessary related to passwords, but more into figuring out a random sequence

Is there any metric/general rule of thumb that I can use to give a rough estimation?

Something along the lines of "it would take x amount of years using y computer to go through all the combinations"

The calculation is simple. First, figure out how many "tries" a computer can do per second, minute, or hour, etc. Obviously it depends on the computers. For example, let's say 1000 calculations per second.

So time in seconds = 2^1000 / 1000 = 1.071509e+298

Then you can convert in minutes by dividing that number by 60, and so on.

The formula is: timeInUnit = nbCombinations / (CombinationsPerUnit * nbComputers)

The time to try all combinations is the number of combinations divided by the number of combinations the computer can do in that time unit, again divided by the number of computers you have.

HOWEVER, to reach a particular sequence, you can, on average, divide that time by 2. Because in a real scenario, you don't have to try every combination, you stop when you get the one you want. On average, you will hit it after having exhausted half the possibilities. You could get lucky and hit it on your first try, or you might have to go through every combination.

Now, to hit a certain number of sequences, say 3, how much time does this take on average? Not three times as much, because at most trying every combination will guarantee you hit those 3. But it has to be more than half the time, right? Well, that's a fun probability problem, I'll let you figure it out.


How can malware discover the real IP of a TAILS user? The FBI recently used a 0day exploit to hack a TAILS user and expose their real IP.
I am interested in how they could have managed to obtain the user's real public IP after compromising the machine. Since TAILS sends ALL network communications over tor, simply having the computer report to a server controlled by the FBI wouldn't help as the server would still only receive the IP of an exit node (and assuming the computer is connected to a wifi, it would only know its local IP not the public IP). Would they have to patch the OS somehow to allow communications without tor, which might further require some privilege escalation exploit, or is there any simpler way that I'm missing?

You are right that Tails only enforces conection over Tor circuit. Even if there's a malware running with application privileges, its traffic has to be routed through Tor. User-level applications cannot enforce their own network configuration in Tails. As facebook refused to disclose the vulnerability, this is what might have happenned.

Media file carries the payload.

a zero-day exploit in Tails: a bug in its video player

On running the media file, payload exploited a vulnerability in media player to execute arbitrary code inside a payload. Atleast a vulnerability in media player is confirmed by facebook.

That arbitrary code exploited a second vulnerability to gain privilege escalation.

Now the payload has privileges of a system, it patched the system to bypass Tor circuit.

Malware was able to connect with FBI controlled server directly.

It's likely a chain of vulnerability with privilege escalation attack. Given the cost of this exploit is in 6 figures and facebook non-compliance with vulnerability disclosure, it's safe to assume that critical zero day exploit was involved.

Sources told Vice that since an upcoming Tails update was slated to strip the vulnerable code, Facebook didn’t bother to do so.

It is still not clear from this context where the vulnerability resides apart from the one which was in media player as compromising an application in Tails doesn't give you privilege of bypassing Tor circuit. We still have to wait for official response from maintainers of Tail. No CVE has been assigned as of now.


Is this a virus or what? DECRYPT_INFORMATION On my computer there are lots of html files with titles DECRYPT_INFORMATION. I have scanned them with AVG and it says they are no threat but I am suspicious. I don't know html so when I open them on notepad I can't understand it. My question is is this somthing I should worry about?

From a bit of googling the DECRYPT_INFORMATION looks like a thumbprint of Hermes Ransomware, symantec has a technical description here

According to the link the executed Trojan creates the following files, which you could search for to confirm, but definitely don't click on that Reload.exe file if you find it:

  %AllUsersProfile%\Reload.exe
  %AllUsersProfile%\shade.bat
  %AllUsersProfile%\system_.bat
  [LOCATION OF ENCRYPTED FILES]\DECRYPT_INFORMATION.html
  [LOCATION OF ENCRYPTED FILES]\UNIQUE_ID_DO_NOT_REMOVE

And creates the following registry subkey:

  HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\allkeeper

It targets files with a range of extensions, available at the Symantec link, but the recommendations apply mostly for network admins and won't help you much.

Note: I'm sharing this bleepingcomputer forum post just for information, not at all suggesting to follow the suggestions there.

From this bleepingcomputer forum post, it seems that the Hermes Trojan may have some difficulty traversing directories, so it could be minor if you don't make things worse in your detective work.

I suggest backing up any information on your computer that you don't want to lose, and opening files by right-clicking them and opening them in notepad instead of double-clicking.

If I remember right Windows has the unpleasant feature of hiding file extensions and you don't want to stumble on any more executables in case it has more landmines.


Does "late launch"/"dynamic chain of trust" allow remote attestation? One of the features support by modern processes and Trusted Platform Modules is "dynamic chain of trust" (also known under the acronym DRTM, for dynamic root of trust measurement).  This allows loading a critical piece of software in an isolated execution environment, where it can be protected from the rest of the software on the system.

The feature is initiated via the SENTER instruction (on Intel chips) or SKINIT instruction (on AMD).  On Intel, this is part of Intel's Trusted Execution Technology (TXT).  I've sometimes heard this technology under the name "late launch": e.g., if you want to start a hypervisor or other critical software while the system is already running, in a trusted way, you do a "late launch" of the hypervisor/software module.

DRTM/"late launch" provides isolation (so that other software components cannot tamper with the code or data of the trusted module that is launched in this way).  It also provides sealed storage, so that the trusted module can store data in encrypted form, where the decryption key will be released to future invocations of the trusted module but not to any other software component.

Does "dynamic chain of trust" support remote attestation?  Does it provide way to attest to the code of the trusted module that was launched in this way, to a third party?

Does "dynamic chain of trust" support remote attestation?

When a dynamic launch is used on an area of memory, specific PCR indexes in the TPM are used to used to record the state of that software. If these PCR indexes are included in the attestation request by the challenger, then that software would be attested to in the response. These PCR indexes are 17-22, as specified in the TCG's PCClient inplementation for BIOS spec, see page 30.

  Does it provide way to attest to the code of the trusted module that was launched in this way, to a third party?

Intel's implementation of TXT support on Linux, tboot, has missed a detail, which they will hopefully fix soon. tboot doesn't expose the event log, which would show what software was extended into TPM PCRs as part of the TXT launch. This is a requirement for a remote challeneger to attest against dynamic launch PCRs, so at the moment, support isn't fully there. You can technically find the event log, but its not available in a TCG standard format, so all the common trusted computing tools that'd be used to parse it will not work ATM.


Scans more IPs than asked I am running this command through Zenmap:

nmap -T4 -A -v -iR 1000

It is the default 'Intense Scan' with 1000 random targets. On almost every scan I run, however, it seems to scan more than 1000 targets. Usually it's only up by 3 or 5, but I've had it scan 1056.

The output begins with,

Starting Nmap 7.12 ( https://nmap.org )
NSE: Loaded 138 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 08:48
Completed NSE at 08:48, 0.00s elapsed
Initiating NSE at 08:48
Completed NSE at 08:48, 0.00s elapsed
Initiating Ping Scan at 08:48
Scanning 1000 hosts

which implies that it started correctly scanning 1000 IPs. At the finish of the scan, however:

Nmap done: 1056 IP addresses scanned in 14486.68 seconds
Raw packets sent: 252137 (11.381MB) | Rcvd: 387821 (36.462MB)

Does anyone know what could be causing this?

This is a bug in Nmap. Thanks for discovering it! Short answer: there was a bug in how we counted how many addresses were already scanned, which I just fixed in r36341.

Longer answer: Nmap runs scans in several phases. The important ones for this bug are host discovery (Ping scanning) and port scanning. Nmap loops over all possible addresses, doing host discovery in large chunks when necessary, and grabbing some number of "up" hosts to do port scanning on in a group. It stops looping over addresses when it has enough targets for a hostgroup or when the addresses run out. For -iR, the addresses never run out, so instead we check whether o.numhosts_scanned is less than o.max_ips_to_scan. That would work except that we don't consider an "up" host "scanned" until after the port scan phase. So there's the potential to check extra addresses. Over a long scan, most of these get counted anyway because they increment o.numhosts_scanned after the port scan phase and before the host discovery phase for the next group, but the last hostgroup will have some carry-over. I fixed this by adding an extra loop check to ensure that "up" hosts were added to o.numhosts_scanned before checking against o.max_ips_to_scan during the discovery phase.

Example debug output from nmap -iR 2 -p80 -d -n:

Initiating Ping Scan at 15:14
Scanning 2 hosts [2 ports/host]
Completed Ping Scan at 15:14, 1.48s elapsed (2 total hosts)
Overall sending rates: 4.06 packets / s.

This shows that we correctly ping-checked 2 addresses.

Nmap scan report for 20.240.133.236 [host down, received no-response]

One of them was down, so the report is printed immediately. One of them must have been up because we only got one such report.

Initiating Ping Scan at 15:14
Scanning 54.28.85.198 [2 ports]
Completed Ping Scan at 15:14, 1.48s elapsed (1 total hosts)
Overall sending rates: 2.71 packets / s.

Oops! The one "up" target wasn't counted towards the number of scanned hosts, so ping scan thinks it needs to scan one more to be done.

Nmap scan report for 54.28.85.198 [host down, received no-response]

That one was down. So 2 down hosts and one up.

Initiating Connect Scan at 15:14
Scanning 187.142.197.40 [1 port]
Completed Connect Scan at 15:14, 0.06s elapsed (1 total ports)
Overall sending rates: 17.06 packets / s.
Nmap scan report for 187.142.197.40
Host is up, received conn-refused (0.059s latency).
Scanned at 2016-09-29 15:14:26 UTC for 3s
PORT   STATE  SERVICE REASON
80/tcp closed http    conn-refused
Final times for host: srtt: 59196 rttvar: 33779  to: 194312

And here's the third one: port 80 was closed.

Read from /usr/bin/../share/nmap: nmap-payloads nmap-services.
Nmap done: 3 IP addresses (1 host up) scanned in 3.06 seconds

And here's the output showing that 3 IP addresses were scanned, even though I requested only 2.


Key pairs extension / version I read in some docs, there are several version of GPG key extension available.
For ex: gpg, ascii, p12
I know .gpg extension is in binary, and Ascii is in text.
But I want to know their differences regarding its quality and security.
So please tell me their differences (GPG, Ascii, p12) ?
Which one is the most recommended ? and why ?

You appear to be asking about keys exported from GnuPG, although you don't actually say so, and it isn't clear if you mean public keys (only) or secret (aka private) keys.
Nor if you mean the GnuPG suite (which includes both gpg and gpgsm) or the gpg program only.
First, to clarify, the extension on a filename doesn't really matter; what is important is the format of the data in the file(s). People often (usually?) choose the extension to reflect the format, and some programs (like the GUI Kleopatra in gpg4win) encourage this, but GnuPG itself can process a file depending on its actual format without regard to the extension (or lack thereof).

gpg processes OpenPGP messages using OpenPGP keys, and for all files (except clearsigned) it supports binary or 'ASCII armored' variants. There is one OpenPGP-defined format for each of public and private keys, and those are the (only) export formats gpg supports, in both variants. People generally use .asc for armored files, because the actual content type can be determined by looking at the first (or last) line; .gpg is sometimes used for binary files, but sometimes people use other extensions to indicate the type of content as well as format, such as .enc for encrypted, .sig for signed or signature, .key or maybe .pub or .sec for keys, etc.
Public keys are protected against tampering by at least one signature, and don't need to be confidential; private keys have one signature, and are encrypted with password-based encryption using reasonable algorithms by default (unless you have deliberately configured them badly) so their confidentiality is protected if you use a good password (including passphrase) and not otherwise.

gpgsm processes S/MIME (effectively CMS) messages using S/MIME keys and certificates, and similarly supports binary and PEM files; although not identical, PEM is very similar to PGP's ASCII armor and gpgsm adapts option --armor to actually mean PEM. gpgsm supports exporting public keys as X.509 certificates, and private keys in PKCS1, PKCS8, or PKCS12 formats, all in binary and PEM variants. However Kleopatra supports only X.509 and PKCS12. Similarly people, and Kleopatra, use .pem for PEM and varying extensions like .p7s .p7m .der .p12 for binary.
X.509 public keys (certs) are protected from tampering by CA signature and don't need confidentiality, like PGP public keys. PKCS1 and PKCS8 private keys from gpgsm are not encrypted, which is very bad, and not protected from tampering either, but as noted Kleopatra doesn't support these. PKCS12 private keys are protected by a password-based MAC and also include the X.509 cert which is protected as above and partially verifies the private key. The private key is encrypted by password-based encryption with 3DES which is decent but at risk if and when quantum analysis succeeds, and dependent on the password in the same fashion as gpg/OpenPGP; following common practice, the cert is encrypted with a weak algorithm (RC2-40) which is unnecessary and silly.

The main differences are that a PGP key can only be used with PGP programs and not S/MIME, while the S/MIME format keys can only be used with S/MIME and similar programs but not PGP, so which is better depends on who you want or need to communicate with. The text formats (armor and PEM) are necessary if you want or need to process the key as text, for example with cut-and-paste; otherwise it doesn't matter to (most? all?) programs, although the text formats are easier for a person to identify, especially if the filename was badly chosen or altered accidentally.


Can you sniff VPN traffic just like you would a coffee shop? I see a few questions related but am not sure I understand how VPNs work so my question is: Can you sniff VPN traffic the same way as you would another network like a coffee shop. For example, at a coffee shop, I can just run tcpdump and listen to any connections to that coffee shops router thus seeing what the person next to me is doing. However, does a VPN work like this as well? For instance, could I setup a VPN and the user next to me is on the same VPN (different user login to the VPN) and run tcpdump and still sniff that persons traffic?

I understand that VPN traffic is encrypted but that is to people outside of the VPN itself (or is it also encrypted for each user?).

VPNs are encrypted per User. What tcpdump will tell you in a Public WiFi is that there are people using VPNs. But thats all - everything else is encrypted and - assuming the VPN vendor implemented the crypto correctly - cannot be sniffed on the user-side.

However: If you know the VPN users exit node you could sniff packages travelling in the exit nodes network. You would then have to corelate these packages with the encrypted ones you see the user sending/receiving. Inpractice, this is very cumbersome due to the vast amount of internet traffic but was effectively used by the FBI to pwn tor users. That means: Using a VPN and not using HTTPS/TLS creates an attack surface big enough for a determined attacker to render your VPN useless.


Can an intruder still possibly succeed with pass-the-hash or pass-the-ticket on Windows 10 / Server 2016 networks where Credential Guard is enabled? In sum: Does Credential Guard make passing-the-hash and passing-the-ticket attacks effectively unavailable on networks of Windows 10 / Windows Server 2016 machines?  If not, how do you still acquire hashes or tickets to pass?

From what I've learned about pen testing and malicious attacker methods over the couple of years that I've been studying them in earnest, one of the happiest discoveries that an offensive actor can make happens when penetrating a target's Windows network and finding that it is not properly configured & administered to resist pass-the-hash and/or pass-the-ticket attacks. In such situations, it often becomes disturbingly easy for the intruder to (using a tool like mimikatz) dump NTLM password hashes and Kerberos credentials that are contained in the memory or are on the disk of the foothold machine that was originally compromised and use them to successfully move laterally and breach other boxes on the network. In the best case, it's possible to sooner or later get your hands on the keys to the kingdom: an NTLM hash or Kerberos ticket for a Domain Administrator or Enterprise Administrator.  And if that happens... the target is in a world of trouble.

Unfortunately for the offense, in Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Microsoft has implemented a number of measures to try to make passing-the-hash and passing-the-ticket attacks harder to pull off. The most ambitious of these is called Credential Guard, and arrived in Windows 10 Enterprise on the client and Windows Server 2016. The details of how Credential Guard appears to work technically are a little complicated. But at a high level things are more straightforward: Windows takes advantage of virtualization capabilities present in newer Intel and AMD processors to encase the credentials store that exists in memory on a Windows machine in a special
kind of virtual machine. A virtual machine that (in theory) even a program that manages to get administrator/SYSTEM privileges on the OS cannot penetrate. Thus, as the pitch goes even if you manage to get your malware onto a PC, and even manage to elevate your privileges on that PC all the way to SYSTEM, if that PC has Credential Guard enabled on it and you try to use a tool like mimikatz to dump the credential store you will get nothing usable for passing-the-hash or passing-the-ticket.

In theory.

So let's say you're a pen tester facing a Windows domain that consists exclusively of Windows 10 Enterprise workstations, Windows Server 2016 servers, and a Windows Server 2016 domain controller. All running with Credential Guard enabled. If you'd like to use pass-the-hash or pass-the-ticket for lateral movement, are you just screwed? Aside from being able to dump the hashes & tickets in the credential store, what other methods might an attacker use to gain hashes or tickets that can be passed? Can you bypass or disable Credential Guard? Or are you faced with just giving up on passing hashes/tickets entirely and trying other ways to do lateral movement?

Edit:  FYI, it turns out that in the July Windows 10 "Anniversary Update" Microsoft very quietly introduced Remote Credential Guard, which is apparently designed to prevent your credentials from ever being sent to the remote box when you initiate a Remote Desktop connection to it. (Same general idea as Restricted Admin mode for RDP, I guess, except improved.) A "helpful" diagram from MS:

Against normal adversaries ( non-APT; e.g. cyber criminals) it will be quite effective.
But I'll focus on the question of how to bypass Credential Guard so you can get an idea of the sophistication needed.

In the link you provided Microsoft has a visual describing the various security rings of a system.

Like most people Microsoft put Hypervisor (ring -1) directly above the hardware.

Of course, it would undermine their point and raise questions if there was to be a layer between their security mechanism and the hardware.

  But if i google ring -2 i don't get any fancy graphics describing anything more privileged...

No. But you will get a mention of SMM here and there. This is usually not something that you can experiment with, so there's not much resources on it.

However this video and this slide deck describe exploits for "rings" that are lower than the Hypervisor and could circumvent the mechanism you mention:.

  ... we have encountered systems in the wild where the SMRAM is locked by a non-integrity
  measured BIOS, thereby preventing an SMI intercept from being generated when the CPU is in guest mode. In other
  words, an SMM handler (as a result of an SMI) can execute in SMM mode without the hypervisor having any control
  over it. This leaves a hypervisor on such hardware potentially vulnerable to malicious SMM handler code.

The NSA has developed multiple rootkits for this mode of operation.
From the wikipedia on SMM:

  By design, the operating system cannot override or disable the SMI. Due to this fact, it is a target for malicious rootkits to reside in,[12][13][14] including NSA's "implants"[15] which have individual code names for specific hardware, like SOUFFLETROUGH for Juniper Networks firewalls,[16] SCHOOLMONTANA for J-series routers of the same company,[17] DEITYBOUNCE for DELL,[18] or IRONCHEF for HP Proliant servers.[19]


Is it safe to store a password in compiled code? My current application has a need to encrypt and store sensitive data and then decrypt it again for use at runtime. It's C#, but this question is language independent.

I've built myself a cipher class which uses the Rijndael algorithm and a randomly-generated salt to encrypt and decrypt a piece of data against a passphrase. Should be secure, so long as an attacker doesn't get the passphrase.

So the question is: is there any harm in hard-coding the passphrase into my class? We'll assume an attacker can't get the source code but, if they've got the data, they can likely get the compiled code too since they could be on the same server.

No, it's not secure.

Any compiled application can be disassembled and examined. The CIL bytecode generated by your C# compiler can be traced instruction by instruction just like any other programming language. When you hardcode your cryptographic key, it will appear somewhere in the assembly. (the same applies to machine code generated by "real" compilers, by the way). It's not if someone will find your key, the question is when.

You could encode your key, but the encoding algorithm must also be part of your assembly, so it can be found and used by the attacker.

You could use some code obfuscator which makes the assembly less readable, but that usually affects performance negatively and is also just an additional obstacle which will cost the attacker more time but will not prevent them from finding it when they are diligent enough.


Tons of vulnerabilities are found on tcp/0 port using vulnerability scanners Performed credentialed Vulnerability scan on linux/Unix servers by Nessus and thousand of vulnerability came out of port tcp/0. How could a IANA reserved port(tcp/0) handle traffic? Are those vulnerability truly countable or those came out as false positive? How should we proceed for the remediation process of the vulnerabilities showed under port tcp/0?

How could a IANA reserved port(tcp/0) handle traffic?

It can. Generally, TCP (or UDP) port 0 being in a reserved state doesn't mean it can't be used in practice. Though the way Berkeley sockets are designed it's not that easy to bind on port zero, it's nevertheless possible to use it.

However, it's highly unlikely that this is actually happening in your case. You're just using the Nessus scanner which lists activities not closely related to a specific port under port 0/TCP or 0/UDP (see: "Vulnerabilities by Host"). This is simply an (inconvenient?) convention to display port-less warnings under port 0 -- ironically, to avoid confusion.

Note that those a) are not necessarily vulnerabilities, just warnings or suggestions (e.g. not adhering to the best Microsoft practices while running a scanner); b) are not necessarily false positives. Try to ignore port zero itself, read the report carefully and act accordingly.


Security pertaining to Client-side validation One of my websites has a webpage wherein it has a button/link named 'BACK'. Anyone clicking on this button/link will redirect user to HOME page of the application. Now if the user change the URL on client-side through 'Inspect Element', then the user can be redirected/forwarded to even Google.com. In the process, request is not going to application rather it's going directly to Google.com.

Can anyone let me know if it's a vulnerability or not? I understand that as the link is not validated by the application in any way, it's a vulnerability.

It's not a vulnerability because it only affects the user. When you modify something with "inspect element", you are modifying the code in your browser, not in everyone else's browser.

A different thing is an URL-redirect vulnerability. Let's say you have variable in your code that does something like my-fancy-site.com/script.php?site=www.google.com. In this case, people could change the content of the variable and send the link to other people that trusts your domain, so that they will click on it and will be redirected to Google.


How are public key certificates updated securely? Let's say I get a new computer that's never been connected to the internet before. The first time I connect it to the internet, is it susceptible to a mitm attack while downloading its public key certificates from a certificate authority?

I assume that once the computer gets the certificate authority's public key certificate, it can connect securely and download more certificates for other sites. But how does it securely download the first certificate?

The operating system comes with a set of "default trusted root CA". This is how a Web browser can connect to existing HTTPS Web sites and be content with their certificates without requiring the user to do anything special with his trusted CA. Similarly, the "OS update" mechanism will use the same principle: it will accept an update only if it comes from a trusted server, with a notion of trust which is relative to a public key which is already known to the machine. One may note that OS updates may include updates to the store of default trusted root CA.

Of course, this raises the question of how the OS got there in the first place. All these trusted root CA only move the problem around; trust still has to start somewhere. Usually, a physical medium (say, a DVD) is involved; even more usually, this is done in the computer factory, and the user gets a computer with a pre-installed OS.

If the root CA you are talking about is not part of the "default trusted CA" (i.e. that specific CA did not make a deal with Microsoft to be included by default), then the trust system is bootstrapped by a manual procedure: when the root CA is installed, the machine asks for confirmation to the user; a thumbprint of the new certificate is displayed. The thumprint is a hash value computed over the complete encoded root CA certificate. The user is then supposed to check that the displayed hash value matches a value which was communicated to him through some out-of-band mechanism (e.g. with the on-paper documentation).

Trust must start somewhere, but, thanks to cryptographic hash function, that "somewhere" can be a value small enough to be handled in the physical, non-computer world (a human user can verify that a 40-character hash value matches that which was printed on some paper).


Is there a risk involved in befriending fake accounts on Facebook? I am quite active in several Facebook groups and get a handfull of friend requests from obvious fake accounts every day. Usually these profiles appear to belong to pretty young women who link to some site on their wall that I have to pay to become a member of, pretending that I can contact them once I have signed up.

But sometimes these profiles are completely inactive, there are no links to paysites on their wall and they do not reply to messages. Since these profiles do not try to lure me into spending money or downloading malware, they must be doing something that I am not aware of. I guess they try to get my contact information or friend list, but I have hidden all of that even from my friends. Yet these fake accounts do not unfriend me, but remain my friends until I unfriend them.

What is the deal here? Can a Facebook friend make use of my profile somehow or grab information, e.g. through the Graph API?

They can take information on your page and use it for targeting you for phishing.

They can also use it to generate phishing emails to others based on info on your profile.


SHA256 checksum different than source I downloaded kali Linux 32-bit ISO and verified the sha256 checksum and they weren't the same. Totally different checksums and the file is fully downloaded. Any ideas? I used a reputable VPN and performed DNS leak tests to verify the connection was secure. Additionally, how difficult is it for someone to display fake checksums if a malicious user has access to your operating system or physical hardware and installed software with bad intentions? Thanks!

A different checksum only means that the software on your computer is not the same as the official version of the software. It does not necessarily mean that an attack is taking place.

A transmission error may have corrupted the data in transit.
Your download mirror may have inserted something benign to the software distribution, such as a thank-you or a request for donations.
Your download mirror may have given you the wrong version of the software, for example if they are slow about updating the software on their website.
Someone may have inserted a malicious program into your distribution.

If you've eventually gotten a version of your software that matches the officially published checksum then I wouldn't worry too much.

A few other observations:

Checksum values are not stable- small changes in the software can lead to totally different checksums. The fact that your checksum is radically different doesn't mean anything.

It would be exceedingly difficult for an attacker to display a fake checksum on your machine. They'd need to know what program you're using to calculate checksums, and they'd need to somehow install a malicious version of that program. If they're able to do that, then they've already got administrative access to your machine, making the purpose of further attacks a little unclear. In my mind it'd be more likely for them to hack into the software author's website and change the official checksum listed there.

Many sites use a download link that sends you to a random mirror as a simple way to provide load balancing for their mirrors. The fact that you've gotten three different checksums is not necessarily a red flag in my mind.


Can a forwarding rule be set on Outlook that will not be visible on office365/exchange admin interface? In an incident concerning a user's mailbox - will any rule that forwards emails to a potential attack be visible in the office365/exchange admin interface, or is it possible to set an outlook client-only rules that will forward these emails and will not show unless inspecting the user's outlook client?

Thanks!

Generally there are multiple Ways to forward E-Mails:

Users can create a forwarding rule within Outlook or Outlook Web App
An administrator can create a client rule for forwarding
An administrator can set the ForwardingSMTPAddress parameter on a mailbox
Users can set the ForwardingSMTPAddress parameter on a mailbox
An administrator can set the ForwardingAddress parameter on a mailbox

You can check which Mailboxes have external forwarding enabled via Powershell, as this Post suggests.

Get-Mailbox -ResultSize Unlimited -Filter {(RecipientTypeDetails -ne "DiscoveryMailbox") -and ((ForwardingSmtpAddress -ne $null) -or (ForwardingAddress -ne $null))}

If you want to disable external forwarding of Mails in General, this Microsoft Guide will help you.


How to securely send cookies from one site to another via userscript? I am part way through creating a 3rd party service for an online game. Currently to pull the game data from outside the game I use my own auth cookies, however, I want to make this available for other players to use to see their personal stats and what not.

I can send the cookies from the game via a userscript or plugin. However, I want to ensure I'm handling their information securely. The cookies are stored in an AES encrypted table.

When sending from a userscript to a webserver via a XMLHTTP request, how can you ensure the security of the data during transit? Does SSL work when sending cross-domain?

If I understand correctly, you want to to have service A hand a cookie to the user's browser which is then submitted to service B, and you want that cookie to be secure throughout.

As far as network transit goes, if both service A and service B are enforcing SSL, then yes, it will be encrypted "in transit".  But you (service A) may not have any control over whether service B uses SSL or not.

In any case, the actual browser in the middle will have access to that data, after it is decrypted from the service A connection and before it is encrypted for the service B connection.  You can't keep it secret from the "other players" if they're operating the browser that is the middleman between service A and service B.


How to avoid response manipulation in NodeJS Application? I have a NodeJS application on the server. The attacker from the client system already knows how the success response looks like for a request. Next time he sends a request with wrong credentials, here even if the request responses with failure status, he manipulates the response to success state and sends to the client (Angular 4). Thus now he can access rest of the process.

Node server already has HTTPS certification.

I do not understand what kind of attack this is? How can one solve such attack? IS there any way in NodeJS to protect from this kind of attacks?

Example:

Normal req and res flow:

A(client) ---> B(server) [A to B request]

B(server) ---> A(client) [B to A response]

Attacked req and res flow:

A(client) ---> B(server) [A to B request]

B(server) ---> C(attacker) --> A(client) [B to C, response is modified from failure to success status by c and sent to A]

This is a standard man-in-the-middle attack. You protect against it by using HTTPS. That adds encryption (confidentiality), tampering protection (integrity), and authentication. You'll need a TLS server cert installed in Node.


Doesn't the Heart Bleed vulnerability imply that we need to change passwords for *all* systems? I understand the part about a server with the vulnerability.

But from what I gather, the vulnerability has also existed in browsers that use the vulnerable OpenSSL implementations.

So, if I first visit a site that doesn't have a vulnerable OpenSSL implementation, log in then, and then afterwards (or perhaps through some obscure AD networks) gets routed to a malware server (that wouldn't normally be able to attack my computer), wouldn't this server be able to send an incorrect heart beat response back and thus get that 64KB from my browser sent to it?

So in essence, won't the Heart Bleed vulnerability in my browser mean that I could've potentially have leaked all data from my browser to a site?

The only major browser I know of that uses OpenSSL is Opera, and the versions I've checked appear to use an older version that isn't vulnerable to the Heartbleed attack.  Firefox, Chrome, and related browsers use NSS for SSL.  IE and derivatives (including most embedded HTML renderers on Windows) use Microsoft's SSPI.  Safari on MacOSX and iOS uses Apple's SSL implementation.  Dillo and Lynx are the closest thing I know of to major browsers that use OpenSSL, and those have a marketshare best measured in parts per million.

Vulnerable clients tend to be special-purpose tools such as "wget" and "curl" (command-line tools for making HTTP requests), or non-browser programs such as email clients.


Why doesn't a simple HTTP request to display a remote web page violate the same-origin policy? On a W3Schools page, I found that HTTP requests work like this:

A client (a browser) sends an HTTP request to the web
A web server receives the request, and runs an application to process it
The server returns an HTTP response (output) to the browser
The client (the browser) receives the response.

On the same page I found that an XMLHttpRequest works like this:

A browser creates an XMLHttpRequest object and sends it to the server
The server processes the request, creates a response and sends data back to the browser
The browser processes the returned data using JavaScript and updates the page content.

The above two processes appear pretty much the same to me. However, the latter one violates the same-origin policy (SOP) if the server runs on a remote domain. This question on Stack Overflow about the URL in the open() method says that

As we can only send requests to our own web server, I assume that we don't have to rewrite the website's name in the URL.

Applying the same logic to the first case (HTTP requests) would mean that I couldn't open a web page if it is not on my own computer. Luckily, this is not the case.
So, why doesn't an HTTP request to display a remote web page violate the SOP? What is the key point/difference here?
I assume it's about the fact that the second process (XMLHttpRequest) is initiated from a script, while the first one is triggered by the user. However, isn't the HTTP request sent from a script when I click a hyperlink on a web page? And how can a web server distinguish between requests coming from a script and coming from a user?

And how can a web server distinguish between requests coming from a script and coming from a user?

It doesn't. The same origin policy is enforced by the browser, not the server.
The purpose of the Same Origin Policy (SOP) isn't to protect the server itself. Instead it's to protect confidential information which the server wishes to share with the user, but not to share with other parties. This information may be protected by checking the user's cookie, authentication header, or IP address when they send a request, but those checks can be bypassed by an attacker getting the legitimate user to open the attacker's website with a script to request the information.
This is when the SOP provides protection. The request may still be sent, but the browser can refuse to allow the script to see the information in the response.
If there is a need to protect the server against potentially harmful requests that it could be tricked into carrying out based on its trust in the user, the SOP is not enough. At that point the server needs other techniques to defend against CSRF.


My server was hacked and I am asked to pay to recover my files Today I got a message when I logged on the server:

  Hi, please view: http://pastie.org/private/tlixxvclirxmut6djqyacq for further in                                                                                formation in regards to your files!

Text from link:

  Greetings,

  Your server has been hacked and your files have been deleted.
  Before they were deleted, we backed them up to a server we control.
  You must send a total of 3 BTC to the address: 1M71Lt6RtrdwB43UFWZCBt8FQ7dMqjqNsd
  Failure to do so will result in your files being deleted after 5 days.
  We may also leak your files.

  You can e-mail onewayout@sigaint.org for support. We will not give any
  files before a payment has been made.

  Goodbye!

Can I restore my files? And How can I protect myself against this in the future?

Depending on how the files have been deleted (and your file system) there might be forensic tools that evaluate the journal and retrieve as much information still alive behind the scenes of the filesystem.

For example, if you are using ext3 or 4, extundelete may help when the attackers were sloppy with deletion and didn't overwrite the files.

There are some steps to be taken to prevent this; some of them are:

always keep your system up to date and apply all security fixes
disable all unnecessary access methods (for example ssh password auth)
have a firewall in place that only allows specific ports and protocols to be used
have a backup in place to just wipe the system and start fresh without loosing the data

As has already be mentioned, this is a crime (blackmail, and in many jurisdictions the break-in is actually a crime as well), so you should inform law enforcement.

Also, do not pay them - there is no guarantee they actually will give you the files after that; they most probably won't - or ask for more money.

Side note here:

If user data has been compromised, this might result in legal issues for yourself/the company. The best way to go about this is to be open with law enforcement about everything.


What can the effects of reflected XSS on the login page be? Im a beginner in WASA. What are the probable ill effects of having a reflected XSS vulnerability on the login page? Lets say reflected XSS is identified in the username parameter on the login page.

Injecting code in a page can lead to a lot many things. Few of those are:

Lead to Phishing attacks
Redirection
A keylogger can be created
XSRF
Get data from JS variables and non-HTTPonly cookies


How to uniquely identify / tag client devices to whitelist VPN access? I'm just wondering if there is any way to uniquely identify or tag client devices like laptops and towers in order to whitelist them for vpn access.

(Note: This is a thought-experiment at the moment, but I hope I can implement this at some point). Please also note that I don't have much experience with VPNs.

Here's what I try to do.

I have two networks, my LAN and my DMZ. I want to setup two different VPNs, one for the DMZ to which every client device with valid logon credentials can connect (Laptops, Smartphones, Tablets, etc.) and the other one for the internal LAN where I want to restrict access to certain clients only (e.g. company laptops and towers with encrypted HDDs).

The problem is, IP whitelisting is not an option (I think) since the laptops could connect from home/airport/etc.

I thought about identifying them with ssl client certificates but I only have worked with client certs in browsers so far and those can be exported by the user and moved to another machine.

Hopefully you guys can help we with this.
(And sorry, I know this topic has come up a few times but I couldn't find a solution).

EDIT: A colleague mentioned that cisco anyconnect has some kind of client identification feature. I'll look into that. Still, other options and help on this is appreciated!

I'm sorry that we don't know more details about your infrastructure, but basically i would recommend you stay tuned with certificates. Maybe this Video about Client Certificats helps a little.

Another way would be to use Radius Auth or something else (e.g. MSAD)


Store/retrieve users passwords on server (using password managers ?) I am working on a project in wich a school's server will need to use students' passwords periodically to connect to another website for them.

I am aware that storing users' passwords in a server database is a horrible idea. Besides I can't hash them because my application needs to use the original passwords.

I wonder if I could encrypt and decrypt those passwords in the database the way password managers do. Without a chance that I (or server administrators) can read them of course.

Also, do you know of any online password manager that provides an API I could safely use on my server with PHP ? Or a password manager software that I could install on the server and use with PHP ?

Maybe you can use a kind of Vault for storing secrets. There is an Open Source project named Vault at https://vaultproject.io/. It provides a lot of options and access control. Take a look.

As others already said, this is bad practice. Authentication is made to link virtual account with physical person. That's actually breaking this.


Smart Lightbulb Using Common IRC port found in NMAP - anything to worry about? UPDATE:

Looking at the product again, I don't think this even has built in Wi-Fi (it uses bluetooth for the connection).

I don't know what I am looking for here in Wireshark, but I added the host 192.168.40.59 and ran it for about 15 seconds and there was a constant packet that was captured, maybe a ping?

I was going through my connected client list trying to add some alias names to my devices to help keep track of what is connected to my network.

I noticed one device that I didn't have a name for, and had trouble trying to track down what it was.

Checked the MAC address to try and find the vendor and got some basic details, enough to recall what this was.

I have a "Smart Wifi Lightbulb" which comes with an app to change its colors etc.

When I ran NMAP on the IP, it said that service=IRC was running on port 6668. I know that there are only a limited number of ports so there are bound to be devices that share ports that might not be what they are actually for.

As a test, I pulled up an IRC client and put in the IP and the PORT and it connected. It stays open for about 30 seconds and then disconnects.

Anything I should be worried about here or further things I should check into?

Product: https://www.amazon.com/gp/product/B07CL2RMR7/

MAC: 68:57:2d:12:bf:d2
Vendor: HANGZHOU AIXIANGJI TECHNOLOGY CO., LTD
Main Products: Smart LED Light Bulb, Smart Plug, Smart Switch, Smart Module

Mac-mini:~ $ sudo nmap -sS 192.168.40.59
Password:
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-21 10:01 MST
Nmap scan report for 192.168.40.59
Host is up (0.076s latency).
Not shown: 999 closed ports
PORT     STATE SERVICE
6668/tcp open  irc

Nmap done: 1 IP address (1 host up) scanned in 1.12 seconds][1]][1]

Nothing serious to worry about from the data provided. It might be how it talks to a control station or receives commands. I'd run a packet capture on it to investigate further. I'd also want to run some IRC commands.

It does appear that it's unencrypted. But the risks on an unencrypted line of commands to a light bulb might be very low.

Is it "face-palm-worthy"? Oh yes. Is it a major security issue? Not from the data you provided, but I'd still want to see that packet capture to know more.

There is a possibility that IRC functionality means that there is a Linux server in the bulb, which means that an attacker might be able to log in, install things, and keep connection to the network in your home. But these things would have to be confirmed.

This is a reason why it is recommended that you place IoT devices on their own network. It segments off weird stuff like this away from your user computer devices.


How can I find if my website code has been implemented somewhere else? The idea is to find, through some search engine or tool, a HTML tag structure, or HTML fingerprint, which reveals similarly coded pages to a particular one.
A traditional search engine like Google or Bing will only look out for actual content, but won't give results for HTML itself.
I am aware some services, such as shodan.io, allow to perform a search on the network protocol level, without parsing the content. But this is the only particular example I know, it is a paying service and I do not know if it would allow this type of requests.

You could place unique values in the HTML Meta "Keywords" tag, which some search engines will index.  (According to this article, Yahoo and Ask index it.)  If you put a truly unique string into your meta keywords, then you can search for it to find anyone who's copied your site as long as they left the keywords alone.
<head>
<title>My Cool Site</title>
<meta name="keywords" content="SuperUniqueValueStringHere, qlkzweamn" />
</head>


how to arpspoof when the AP prevent clients from seeing each others? I am trying to perform man-in-the-middle attack on my home network.I can fool the AP into thinking that I am the client by this command

arpspoof -i wlan0 -t 192.168.1.1 192.168.1.10

however when I try to make the client think that I am the AP

arpspoof -i wlan0 -t 192.168.1.10 192.168.1.1

The client keep sending the packets to AP.
I know this because when I open wireshark I can see the packets going to the clients only.I cannot see any packets coming from the client.
I went through the router settings but there's nothing seem to be related to the problem.

Except for very specific cases (TDLS) all traffic between clients will go through the access point. So arp spoofing will never make a client send data directly to you.


Can script steal sensitive data in home directory on Linux and is SELinux optimal way/tool to prevent it The premise: on a Linux workstation I regularly download and use various software, let's say Perl or Nodejs modules. When I use them they run on the machine with me as the owner and can do whatever I can in my home directory, so they can access and steal (send over the network) my keys etc.

That thought has been gnawing me for years, now I finally found time to learn SELinux to deal with the problem. But as I was learning SELinux, it occurred to me, that someone might have already created some modules for applications which use those sensitive data, let's say a SELinux policy module for gnupg to restrict access to the gpg keys only for that app. But it seems not to be the case. So that is why I started to doubt the whole idea. I searched the web for "linux process home directory steal files" and similar queries and results were generally about physical theft. It's very unlikely, that I'm the only one who thought about this.

So my first question is whether the premise is true?

If it is, then what are optimal options to deal with this? Currently I'm going to try to customize the targeted SELinux policy to allow access to those sensitive files only to a limited set of processes and possibly limit network access on the application basis.

I would need to customize the targeted policy, since it seems to allow the unconfined_t domain to access both user_home_t and gpg_secret_t, since gpg_secret_t is part of the user_home_type attribute and the policy allows full access to it:

$sesearch -t gpg_secret_t -A
…
allow unconfined_t user_home_type:file { read write … }

Currently I ended up without SELinux in this case.

Instead I set up a separate user account, in which home directory I store the primary key and switch to that account if I need to sign something or decrypt (one can generate a subkey to use under his general account). Despite SELinux unconfined processes being run with root privileges still can access the key storage, I generally don't run untrusted code as root, so this should be a good mitigation.

Also I completely forbade network access to that account, using netfilter meta skuid expression.

Third, regularly review audit reports for failed authorizations, logins etc. through aureport.

Some SELinux protection wouldn't be redundant at all, but since I don't know currently the syntax of SELinux policies etc., I have to depend 100% on the distro provider's policy.

With all that, I can summarise, that on a personal computer it should be more than enough:

to use separate Linux accounts for access to sensitive data
to restrict network access to a required minimum
to review audit reports


Is the tomb's keyfile necessary when creating a password tomb with tomb-pass? Pass tomb's documentation states

Usage:
pass tomb [-n] [-t time] [-f] [-p subfolder] gpg-id...
    Create and initialise a new password tomb
    Use gpg-id for encryption of both tomb and passwords

If so, then why is a keyfile created for the tomb? Would someone be able to open the tomb if they had the tomb and this keyfile?

Per their site:

  Tomb generates encrypted storage folders to be opened and closed using their associated keyfiles, which are also protected with a password chosen by the user.

because pass tomb is

Asking for a gpg identity and not a password

&&
Created to keep your password tree encrypted when you are not using it (source)

they must be using the gpg public key to encrypt the tomb key.

If that's the case then no, having only the tomb key and the tomb aren't enough to access the tomb (unless they've broken gpg). If someone had the tomb, the tomb key, and the gpg private key they'd have not only the tomb, but the password files as well (since the same gpg identity is used to encrypt them).

You could always test by generating a new gpg keypair, creating a pass tomb using that identity and deleting the private key to be sure (don't trust me, I'm just some person on the internet).


scrypt strength with "weak" salt I'm working on a project where following constrains apply:

There's no remote database or any other means of storing extra data like random salt
When user logins in, only username and password are known and no extra information can be accessed until successful login

We decided to use scrypt and scrypt needs salt. Ideal solution would be to generate random salt but in this case we just can't store that value anywhere.

The system has been designed in a way that username is not stored at any point so if the system is compromised, there's no way of knowing which hash belongs to which username (in case usernames are compromised from other sources).

So the question is that would it be sufficient to use, for example, username+password as the salt?

Reusing the password as part of the salt is, on a general basis, not recommended. The password is secret, and information may leak that way, depending on the internal details of the hash function. I suggest you refrain from it.

The username is, by itself, a not-too-good salt, but if you only have that, then use it. The one and only property of salts is uniqueness. When using the username as salt, you run the risk of salt collisions when:

The same username is used in two distinct systems (e.g. if each system instance has an "admin" user with that exact username, it becomes worthwhile for attackers to compute rainbow tables using "admin" as salt).
A user changes his password (old and new password then use the same salt, and an attacker may attack both in parallel).

If your usernames are unique worldwide (e.g. email addresses) then the first problem is avoided. A variant is to use as salt the username with, as suffix, a '@' sign followed by the server name. For password changes, you can diminish the intensity of the issue by the simple expedient of not requiring regular password changes from your users (these don't improve security anyway).


New credit card security standards regarding PA-DSS Compliance The new credit card standards including PA-DSS can be quite confusing for software companies.

My question is this:  If your software company designs a POS software system (like we do) which utilizes a locally installed 3rd party credit card processor (which is PA-DSS compliant) to encrypt, transmit and process the credit cards, does our POS system have to pass PA-DSS certification then?

The end users enters the data into our custom designed UI / Payment screen in our application. We do not ever store this information at any point in time in a database, text file etc of any kind.  The information is taken from the user interface and loaded into variables in RAM and then passed to the 3rd party software system via their locally installed API. The 3rd party processor then encrypts, submits and processes the credit card information and they are PA-DSS compliant.

So, do we need to be since we are not storing, transmitting or processing the credit card data.   We are transmitting the credit card information only from RAM to an API call.

Additional Information Below Added to Question - 2011

I have been told that it is not possible for a software system to be pci dss compliant. I have been told that PCI DSS compliance includes the total merchant environment including the network infrastructure, virus scanning, internet access limitations of servers holding cardholder data and more. It is my  understanding that a software system, as its own part of certification or in adhering to the standards can only be pa dss compliant.  At least, this is my current personal understanding anyway.

The issue with the pa dss requirements for software developers and software companies is that there is no appropriate definition of the word "transmitted".

The standards say:

"PCI DSS applies wherever account data is stored, processed or transmitted"

Well, based on that,  we are not storing any card holder information at all, we are not processing any card holder information and we are not transmitting any information across a network or the Internet.

The problem is that "Transmitted" can literally be taken to mean anything and it needs defined appropriately. Moving data from one byte to another could be transmitted, moving it from one application domain to another, moving data across a local network  or moving across the internet itself.

In reading the standards, I am under the impression that the people who wrote these standards for pa dss compliance are very unfamiliar with software and that their actual intent was to have the term "transmitted" mean to move data across a network or the internet, which of course we are not doing.

I do not believe they meant "transmitted" to mean, don't move data from one memory address location to another or do not pass data to a pa-dss compliant dll library.

I would hope that because we are not storing, processing or transmitting data over a netowrk or the internet that we would not be expected to pass a $20,000 certification just so that we can call a PA DSS secure dll library to process our cards.

So, do we need to be since we are not
  storing, transmitting or processing
  the credit card data. We are
  transmitting the credit card
  information only from RAM to an API
  call.

Your second statement is contradicting the first, and more importantly, holds the answer to your question.

PCI DSS v2 states the following,

  PCI DSS applies wherever account data
  is stored, processed or transmitted.
  Account Data consists of Cardholder
  Data plus Sensitive Authentication
  Data, as follows:

  Cardholder Data includes:

  Primary Account Number (PAN)
  Cardholder Name
  Expiration Date
  Service Code

  Sensitive Authentication Data includes:

  Full magnetic stripe data or equivalent on a chip
  CAV2/CVC2/CVV2/CID
  PINs/PIN blocks

and I would presume that transmission of the credit card number (which constitutes handling of card holder data) to the third party application would render your POS software to be compliant as well. The question is whether your software should be PCI DSS or PA-DSS compliant, and that is addressed in the section on the "Relationship between PCI DSS and PA DSS":

  note the following regarding PA-DSS
  applicability:

  PA-DSS does apply to payment applications that are typically sold
  and installed “off the shelf” without
  much customization by software
  vendors.
  PA-DSS does not apply to payment applications developed by merchants
  and service providers if used only
  in-house (not sold, distributed, or
  licensed to a third party), since this
  in-house developed payment application
  would be covered as part of the
  merchant’s or service provider’s
  normal PCI DSS compliance.


"Breaching Privacy Laws" - What could this mean? I was one of the developers of a web form that we built for a client (USA based) some 2 years back. Today, we received an email from them stating that one of their customers raised a concern with them about our web form not being secure and breaching privacy laws.

Now I understand this sounds very ambiguous and hence we have replied back to them asking for more clarity on the issue. While we await their response, I thought of posting this here so that I can at least be ready to respond to their queries.

I think the secure part of the concern is related to not using SSL. But I'm not quite sure about the breaching privacy laws part. In your experience, what could this mean?

PS: The web form in question collects personal information like

Name
Email Address
Postal Address
Phone Number

And some business related information like

Transaction Number
Claim Number

There is no sensitive information collected such as CC Number, SSN, Bank Account details etc. The form is validated both client side as well as server side.

As you said, you require personal information, transferred over a public internet connection. Anyone may get to know that this specific user had an interaction with the website, plus some of his personal data.

IANAL, but depending on the jurisdiction of the client's customer, this may well break some privacy law. Especially here in Europe we have quite a strict view about that.