我的第一份工作是在IT安全部门实习。我的任务是自动化对不同用户帐户的网络和应用程序访问，因为每个用户都转移到不同的部门/角色。也就是说，我可以使用一些基本的工具，比如查询分析器，以及一些数据库，但其他的就不多了。该公司通常会把所有东西都锁起来，所以总是有重置和授予的权限。

在这份工作中，所有的兼职人员都被要求使用一个小的VB胖客户端应用程序来跟踪工作时间，在一周结束时，一个按钮可以显示登录的用户一周工作了多少小时，以及他们这一周将获得多少报酬。

出于纯粹的无聊，有一天我偶然发现了小时间跟踪应用程序驻留在网络上的目录，并注意到在该目录中除了EXE之外只有一个其他文件，一个settings.ini文件。

果不其然，打开文件后，连接字符串在明亮的闪光纯文本;用户、密码、数据库名、服务器等等。

在这一点上，我认为这不是真正的信息，但在启动查询分析器，并进入ini设置后，我进入了主生产数据库，其中有任何人都需要给自己加薪的每一块数据。对引导的完全读写权限。

最后，我向老板展示了一份关于谁赚多少钱的问题，他平静地让我把它转发给人力资源总监。

让我告诉你，在我的生活中，我从来没有收到过这么快的，亲自回复任何其他邮件的邮件。

第二天我开始工作，时间跟踪应用程序有一个更新，唉，没有更多的settings.ini文件。

作为对所有读者的提醒，无论是否知情:我刚刚从一个专业那里买了一本800页的2008年版权的关于这个主题的书——在序言中，作者做了一个“嘿，等一下……”，在序言中详细指出，不止一个拥有丰富证书和现场经验的安全专业人士，嗯哼，被赋予了意义，……因为他们看到了一些看起来相对新手的入侵。

如果把它当作看似无害的，那么由于未经授权的活动，就会引发正式诉讼。作为一个专业人士，他们中的一些人被毁了。

我注意到的最后一次入侵涉及一家主要的银行服务，该服务已经存在了很长时间，以至于市民很少听到他们的品牌名称。整个商店的所有数据都是未加密的——但是，对于不知情的人来说，奇怪的是，这家银行实体已经成为了一个“清算所”(我不知道统计数据，但它超过了一半)，为不止一个零售品牌的信贷提供商处理信用卡交易。

入侵者只是在空投处放置了一个(装置)。(这是电信公司从世界各地进入的线路)没有花哨或复杂的交通监控工具，只有基本的。我建议每个人都监控今年2月以来的所有信用活动:所获得的是与当前活跃和有效信用账户上的有效名称相匹配的有效cc#。

空前的。

像往常一样，它是一个没有安全专业知识的人从管理权威的位置上运行一个商店。工程术语是“失效模式分析”……

我的任务是发现一个用于报告的ODBC DSN，其中密码与用户匹配，并且用户属于数据库服务器管理组。

因此，任何具有此ODBC DSN的PC都可以使用任何ODBC兼容工具通过报表用户读取/更改所有数据(甚至更糟)。不需要授权，而且身份验证非常弱。

我在一家公立医院工作，这个软件几乎安装在该州每家政府医院的每一台电脑上，数据库服务器包含各种敏感的医疗数据(完整的患者详细信息、实验室测试结果等)。

最糟糕的是，我们悄无声息地报告了安全漏洞，然后正式报告，但在我继续在那里工作的2年里，它仍然没有修复，那已经是5年前的事了。

我不知道这是不是最糟糕的，因为我见过一些非常糟糕的，但是:

几年前，我工作的地方引进了一个叫做FOCUS的系统。不知道它还在不在。它非常适合做报告，我们开发并教了大约一千两个非It人员如何生成他们自己的报告。非常方便。他们可以做基本的报告，一些人可以做中等难度的工作，IT可以帮助处理较难的工作。

所有用于报告的数据都被定期复制到FOCUS自己格式的影子数据库中。对于更敏感的数据，我们设置安全选项，加密数据。一切都很好。

So, one day my boss calls me in, and we've lost the password to one of the sensitive databases. It's going to be hard to reproduce the data in this case, so he asks me to see if I can break the security. I had no experience as a hacker, so it took me about 5 or 6 hours to hand him the password. I started by creating some test files, and encrypting them with different passwords. I found that changing one character in the password would change two bytes in the encrypted file, specifically, the high nybble of one byte, and the low nybble of another byte. Hmmmm, says I. Sure enough, they stored the password somewhere in the first 80 bytes of the encrypted, but obfuscated the password by splitting the bytes into nybbles, and storing them in predictable places.

不久之后，我们就编写了一个REXX脚本，该脚本在VM/CMS系统下运行，可以告诉我们任何加密数据库的密码。

那是很久以前的事了——在90年代初，我相信他们已经解决了这个问题。嗯，非常确定。

这里可能有一点轶事故事(但因为这是我发现的最糟糕的安全漏洞)…

有一家公司向许多公司/组织(不幸的是包括我们)出售定制CMS(用于网站)。他们使用了相当多的(主要是“LGPL”)他们自己没有制作的组件。很多客户(包括政府)。

正确处理了访问网站不同部分(以及CMS管理系统)的身份验证。 他们在CMS中使用了FCKEditor实例(允许非html保存的用户编辑网页)。 他们还使用FCKEditor的“上传连接器”脚本，允许用户添加文档，图像等。到现场。这个脚本的url是硬编码在一个公开可见的javascript包含中。 他们无法对带有上传脚本的url进行身份验证。

结果:在他们建立的每个网站上，用户都可以(不需要输入任何凭据)修改/删除/更改/上传网站上的每一个文档/文件和/或图像。

我们一发现这个漏洞就立即报告了，所以它可能不会导致直接损害(但很容易)。

一位同学曾经不小心把密码发到了推特上……那是个很严重的安全漏洞。